Limit ReDOS by checking the length before running the regexp. #25
Conversation
Go doesn't support look-ahead assertions so I did this out of the regexp. Signed-off-by: Dan Lorenc <dlorenc@chainguard.dev>
|
This attempts to address CVE-2023-46402 and #24 |
|
LGTM |
I forked git-urls to patch the vulnerability. I submitted a patch upstream, but haven't heard back from the maintainer yet: whilp/git-urls#25 This switches go packages that use this to my fork. Signed-off-by: Dan Lorenc <dlorenc@chainguard.dev>
I forked git-urls to patch the vulnerability. I submitted a patch upstream, but haven't heard back from the maintainer yet: whilp/git-urls#25 This switches go packages that use this to my fork. Signed-off-by: Dan Lorenc <dlorenc@chainguard.dev>
I forked git-urls to patch the vulnerability. I submitted a patch upstream, but haven't heard back from the maintainer yet: whilp/git-urls#25 This switches go packages that use this to my fork. Signed-off-by: Dan Lorenc <dlorenc@chainguard.dev>
|
Tagging previous commiter for attention. @whilp @alokmenghrajani @isaaguilar |
| "strings" | ||
| ) | ||
|
|
||
| // Max length of the scpUrl to prevent reDOS attacks |
There was a problem hiding this comment.
You should link to https://nvd.nist.gov/vuln/detail/CVE-2023-46402 and https://gist.github.com/6en6ar/7c2424c93e7fbf2b6fc44e7fb9acb95d in this comment so people reading the code in the future have additional context.
I'm also suspicious that Go's regexp library would be vulnerable to a ReDOS in the first place. The underlying code implements re2 and the package comment says: The regexp implementation provided by this package is guaranteed to run in time linear in the size of the input. (This is a property not guaranteed by most open source implementations of regular expressions.) . Something seems off with this CVE.
alokmenghrajani
left a comment
alokmenghrajani
left a comment
There was a problem hiding this comment.
lgtm but I'm not the owner of this repo.
|
I implemented something similar (see #27) except I made my max len 8000, and it is still very performant. |
5 participants
Go doesn't support look-ahead assertions so I did this out of the regexp.