-
Notifications
You must be signed in to change notification settings - Fork 728
Vulnerable regexp in rule 942260, 942490 (was: 942330) #1359
Comments
Hi @s0md3v Thank you so much for reporting this! I'm testing it on my nginx + modsec3 and I confirm that it takes a lot of time to process a request like:
I'm creating a rule that drop a request if it contains repeating multiple characters. Based on your experience, what do you think about something like thanks! |
Hi @theMiddleBlue , I would like to patch all the 5 issues I have reported. I have opened a PR for the most critical one already.
There are two problems, Intersecting alternate patternsBoth alternate patterns start with In the second alternate pattern, the tokens Nested repetition operatorsThe structure of the this sub-pattern is I will open a pull request to resolve this and the other issues shortly. |
Oh didn't see the PR sorry! That's really great! I'm testing your changes right now |
are your planning to fix all 5 issues in a single PR? |
Do you want me to include all the fixes in one PR? Yeah sure, we can do that. |
Maybe to have it in a single PR can help us to talk about it (and test your changes quickly). But this is only my opinion, let's see what others say ;) |
I thought it would be better to keep them separate so we can talk about different ways to tackle them and regression testing without getting things mixed up. |
ok, no problem for me! |
This issue is referenced as CVE-2019-11387 by NIST. This issues is directly exploitable in CRS / ModSecurity with Paranoia Level 2 on ModSecurity 3 on NGINX (Tested against ModSecurity 3.0.3 on Nginx 1.3.12). The issue is not directly exploitable on ModSecurity 2 thanks to PCRE match limit settings, that are very low by default. The rule affected is Reproduction:
[EDIT: Updated comment from unconfirmed to confirmed.] |
Reproduction with pcre2test based on known payload and the regex from 942490.
|
Rule Regex:
Sources before regexp::assemble:
|
Should address the remaining problem with SpiderLabs#1359.
@hlef the ddos possibility in rule 942490 has been fixed for dev/3.2 branch, yes. |
Alright, and 942260 is not fixed yet. Thanks! |
942260 is almost fixed. PR is ready: #1417 |
Should address the remaining problem with SpiderLabs#1359.
Should address the remaining problem with SpiderLabs#1359.
* Add variant regexp assemble script to handle possessive qualifiers This is an interim solution and these changes will eventually be added back to regexp-assemble.pl * Use possessive qualifiers to tight this up and solve ReDoS problem Should address the remaining problem with #1359.
The vulnerable regular expression is located in
/crs/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf
on line 913. [Link]The vulnerability is caused by nested repetition operators and can be exploited with the following string
The text was updated successfully, but these errors were encountered: