Regarding the ReDOS exploit strings & the un-reproducibility

_Issue originally created by user s0md3v on date 2019-04-28 08:47:31. Link to original issue: https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1372._

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:

(?i:(?:(?:(?:^[\"'`\\\\]*?[^\"'`]+[\"'`])+|(?:^[\"'`\\\\]*?[\d\"'`]+)+)\s*?(?:n(?:and|ot)|
(?:x?x)?or|between|\|\||like|and|div|&&)\s*?[\w\"'`][+&!@(),.-]|\@(?:[\w-]+\s(?:between|like|
x?or|and|div)\s*?[^\w\s]|\w+\s+(?:between|like|x?or|and|div)\s*?[\"'`\d]+)|[\"'`]\s*?(?:b
etween|like|x?or|and|div)\s*?[\"'`]?\d|[^\w\s:]\s*?\d\W+[^\w\s]\s*?[\"'`].|[^\w\s]\w+\s*?[|-]\s*
?[\"'`]\s*?\w|\Winformation_schema|\\\\x(?:23|27|3d)|table_name\W|^.?[\"'`]$))

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:

(?:^[\"'`\\\\]*?[^\"'`]+[\"'`])+|(?:^[\"'`\\\\]*?[\d\"'`]+)+)\s*?(?:n(?:and|ot)

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:

The researcher added: “It should be noted that I haven’t released the full exploit strings yet because the vulnerabilities still exist and can be abused. The exploits mentioned in my blog are just for the vulnerable parts of the regular expressions and won’t have any effect on an implementation of ModSecurity.”

I hope it makes sense now.

[CRS-migration-bot]

User dune73 commented on date 2019-04-29 08:11:53:

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?

[CRS-migration-bot]

User github-actions[bot] commented on date 2019-11-18 00:05:25:

This issue has been open 120 days with no activity. Remove the stale label or comment, or this will be closed in 14 days