While ModSecurity 2 ended execution of regular expressions at the first match, ModSecurity 3 silently changed this behavior to global matching, without any communication from its editor, Trustwave SpiderLabs.
This results to a possible DOS for non-anchored rules (i.e. which does not use
$), using the
Each match is registered in a transaction variable
TX. For big requests, the number of transaction variable can get important and can make ModSecurity 3 crash.
The exploit in video : the 8 CPU of the nginx server are rapidly saturated.
Trustwave, alerted by CRS, refuse to admit a security flaw, and accuse the way the users write theirs rules, sending back the ball to the CRS team and its rules set.
Then, Trustwave refused to release a minor version 3.0.5 correcting the vulnerability. However, the development tree of the next 3.1 release show that Trustwave is going to come back to the old matching behavior, that had ModSecurity 2.
Concerning the CRS rules set, it’s not less than 58 rules which are vulnerables, either the tierce of the rules set.
The CRS team has reserved a CVE identifier for the vulnerability, which Trustwave refuse to accept. So, the state of the CVE is DISPUTED between the two stack holders and hasn’t been confirmed yet.
The CRS team choosed to act unilaterally, by releasing an unofficial patch for 3.0.4 , made possible by the Apache license which is under ModSecurity.
The patch brought back ModSecurity to its old behavior about the matching of regular expressions.
Find the complete article from Christian Folini, CRS co-leader, about the vulnerability : https://coreruleset.org/20200914/cve-2020-15598/