Vulnerable regexp in rule 932140 #1354
Comments
|
Unlike what you reported on #1359 I'm not able to reproduce the issue. Any help on defining a ReDoS HTTP request that matches 932140? |
|
Hi @s0md3v ,there is a limit for following those bad regex matches in modsecurity, have you tested this in modsecurity? what is your current modsecurity setup and what is the extent of the impact you noticed? |
|
Hi @spartantri , I don't have modsecurity setup on my machine and I don't really need one because the vulnerability exists in the regular expression. I simply extracted all the regular expressions from the configuration files, ran a quick grep to find the find the potentially vulnerable ones, tried to exploit them one by one by using regex101.com and then verified the impact using Also, I wasn't aware about the limits but I have a few questions about this implementation
I believe the regular expressions should be fixed but it's up to your team to make the final decision. |
|
Unless the configuration is made purposely changed to extremely high limits this is not a high DoS vulnerability as the title suggest as the limits are like adding an {#} to the regex in place of a recursive match. When limits are reached, depending on your particular setup and the rule logic the transaction most probably will be blocked. I agree there are some regex that need some love to make them more efficient and this fixes should definitively be implemented to prevent a possible vulnerability when an administrator sets crazy values on their setup. Maybe we can add this to CONTRIBUTING as guidelines to keep this in mind and prevent this from happening in the future, and also tune and benchmark the CRS for performance. |
|
Thanks for making this clear but what's the default behavior? |
|
This issue is being referenced as CVE-2019-11388 by NIST. I confirm that this issue is not present with ModSecurity. I have tried to reproduce the behaviour with the following call: against the following setups:
None of them shows the behaviour claimed in the issue. @s0md3v: Please explain. |
|
I did not craft exploits for the whole strings because they could have been abused. I wrote exploits for the vulnerable sub-patterns. |
|
@dune73 Some engines (like the one of regex101 which is different than modsec) get catastrophic backtracking errors with |
|
I tested it with Python. |
|
From pcre: |
|
Thanks for your feedback @s0md3v. I see the problem in the regex and I can confirm what @fgsch got with Also: Where would the subpattern and the pattern lead to different behaviours of the ModSec engine? I do not understand this completely yet. |
|
We should correct the regexp regardless since the parameter can only appear once. |
|
Addressed in #1472 |
The vulnerable regular expression is located in
/crs/rules/REQUEST-932-APPLICATION-ATTACK-RCE.confon line 404. [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: