Fix vulnerable regexp in rule 942330

[s0md3v]

• Remove duplicate \ from character group
• Resolve intersecting alternate patterns

Fixes #1359 .

[spartantri]

what about the extra couple \ in \\\\x(?:23|27|3d) at the end? are those required?

[s0md3v]

@spartantri That really depends on what you want to match.

[cb]at will match both cat and bat. If we add another b to the character group [cbb], it will still behave the same and that's the reason the duplicate \\ was removed.

On the other hand, \\\\x tries to match the string \\x literally. The person who wrote this rule might know about an attack vector which contains \\x at this point, you better ask that person.

[spartantri]

yes don't worry, I left it as open question so all other guys can look at it, to me \x would be enough but I don't know who wrote this.

[fgsch]

Have you actually reproduced this issue with modsecurity?

[fgsch]

Also the regexp is generated from the file mentioned in the comment.

[s0md3v]

@fgsch The vulnerability exists in the rule, not mod_security. mod_security won't spend more than 1500 milliseconds while matching a string against a rule.

[fgsch]

@s0md3v Yup, I appreciate that. We should try to fix the patterns, but my point is that we should distinguish between "this is actually exploitable" from "this should be fixed but won't be exploitable because there are mitigations in place".

[s0md3v]

@fgsch I am sorry if I am wrong but isn't this rule set being used by other WAFs then mod_security?
If yes, what if they don't have a timeout on matching? Or what if they are letting the request pass if it times out?
This rule set is a third party kind of thing and hence prevention of exploitation of it's vulnerable components shouldn't depend on the program using it as a dependency.

[fgsch]

@s0md3v That's fair, and I agree we should fix it.
I'm not sure if the project officially supports its usage outside modsecurity though.

[s0md3v]

Well I just made an assumption after reading this in the README

The OWASP ModSecurity Core Rule Set (CRS) is a set of generic attack detection rules for use with ModSecurity or compatible web application firewalls.

Anyways, let me know if you have any concern about the patches.

Also, thanks for contributing such great stuff to the open source community, stay hydrated ❤️

[s0md3v]

These changes do not affect the functionality of Mod Security, why these pull requests haven't merged yet?

[fgsch]

@s0md3v as I said earlier:

Also the regexp is generated from the file mentioned in the comment.

Also please be patient. This is a volunteer driven project and people might be (and often is) busy.

[emphazer]

@s0md3v im pretty sure that it will be merged after the next monthly monday meeting. the next is at 6. mai i think. you can be definetly sure that if the tests are positive and the project members agree that we will merge it before the final v3.2 release.
and your name with PR title will appear in the changelog

feel free to join us at the meeting

[airween]

Note, that the double \ is justifiable (in normal case). In version 2 (aka mod_security v2) the rules read by Apache, which strips the strings (I think this routine does it).

That's why it would be better to check the rules through ModSecurity, not with the regex browser.

If the admin merges this request, the affected rule will not work (in v2 - but will right in v3) - hope the regression text will catch it.

[csanders-git]

@airween , i'm a bit lost as to the regression you are discussing, can you give an example?

[airween]

Sure :).

[fgsch]

Tests are failing:

AH00526: Syntax error on line 936 of /etc/apache2/modsecurity.d/owasp-crs/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf:
Error creating rule: Error compiling pattern (offset 414): unmatched parentheses

[s0md3v]

@fgsch I didn't touch line 936

[fgsch]

It is reporting line 936 because that's where the rule ends, but the error is caused by this change.
In fact, it is due to the removal of the \.

[dune73]

Thank you for the PR @s0md3v. Unfortunately, it is not ready for merging (tests failing and regex sources need to be updated), so we are retiring the PR and transfer the information into issue #1479.

There is little pressure, as this is not exploitable via ModSecurity, so we can take the time to get this right.