Regarding the ReDOS exploit strings & the un-reproducibility #1372
Comments
|
CC: @dune73 |
|
@s0md3v if this is really a matter of using the right payload you can send this privately to the core developers. |
|
@fgsch If PCRE limits are in place, ReDOS won't occur but i guess Mod Security v3 doesn't have those limits because of some compatibility issue. |
|
ModSec 3 does not allow a user to configure the limits, but they are there baked into the binary. However, transformations come into play too, so maybe it's the transformations that kill your attack (payload). Honestly, I do not really know why the attacks do not work. The resulting problem with your issues / CVEs is thus, that they do not lead to a DoS. It is obvious, that quite a few of our regular expressions have a ReDoS problem. That is no news, at least not to the project as explained in the blog post at https://coreruleset.org/20190425/regular-expression-dos-weaknesses-in-crs/. We know we need to fix the regular expressions. But we want to do so in a very diligent way. Ideally, the updated regex will match 100% the same patterns as before. And developing that takes time, so we did not merge your welcome submissions just yet. With regards to the CVEs, I just do not see a constellation (with the excaption of CVE-2019-11387), where you / your payloads are able to DoS a system running CRS. ModSec 2 and ModSec 3 do not seem to be affected and we clearly write that our rules work on compatible systems too. Compatible would mean, that the rule execution is the same. If the rule execution is different and DoS happens, then they are no longer compatible and they are beyond our responsibility / authority. Do you understand this argumentation, or is there something flawed in my thinking? |
|
This issue has been open 120 days with no activity. Remove the stale label or comment, or this will be closed in 14 days |
Hi there,
I am submitting this issue as the team is unable to see any impact by using the "exploit strings" i provided.
Look at the following regular expression:
This is indeed a very long regular expression to reverse into a string by hand when you are looking at tons of such regular expressions.
However, the only vulnerable part of the regular expression is the following:
This part will cause the regex engine to backtrack a lot because of the alternate and adjacent sub-patterns and character classes matching the same characters.
I focused only on finding vulnerabilities and not on writing exploits and that way, I was able to find and verify 5 vulnerabilities under and hour.
I assumed you guys would understand what I was trying to convey without making a ready-to-use exploit public, open to abuse.
The strings I mentioned are exploits for the vulnerable parts of the regular expressions, they aren't complete attack vectors as I mentioned in my interview with Portswigger:
I hope it makes sense now.
The text was updated successfully, but these errors were encountered: