The ModSecurity 3.0.x release line suffers from a Denial of Service vulnerability after triggering a segmentation fault on the webserver when parsing a malformed cookie header.
All users of ModSecurity 3.0.0 - 3.0.3 should update to ModSecurity 3.0.4 as soon as possible.
ModSecurity 2.x is not affected.
The CVSS score for the vulnerability is 7.5 (HIGH). MITRE lists the vulnerability as CVE-2019-19886 (but as of this writing, it is only reserved).
The OWASP ModSecurity Core Rule Set (CRS) project makes heavy use of unit tests. One of the goals is making sure that all our rules behave as intended on the underlying ModSecurity engine. ModSecurity 2.9 on Apache is our reference platform that passes our expanding list of over 2300 tests.
LibModSecurity 3.0.x does not yet pass all the tests, failing 2-3% of the tests either due to problems with the engine itself or the connector module that links the webserver with the rules engine..
CRS developer Ervin Hegedüs (@IamAirWeen) is actively working on fixes for ModSecurity 3 and the connectors to make it pass our test suite. We could then declare ModSec3 stable from a CRS perspective.
Back in February 2019, Ervin pushed a pull request (ModSec PR 2023) to fix a cookie parsing misbehavior in ModSec3. The PR was not immediately incorporated into the main branch and eventually the conversation with the developers died down.
Ervin took up the topic again in October and asked the CRS project for help. CRS developer Andrea Menin (@Menin_theMiddle) examined the problem and started to throw random cookie headers at the code. This allowed him to trigger an out_of_bounds exception. NGINX chokes with a segfault and an “out of range” error in the log. The underlying issue with ModSec3 was thus no longer a different behavior when compared to ModSec2, but a DoS vulnerability affecting NGINX and other webservers and Ervin’s patch was not solving it completely.
Ervin refined his patch in a new pull request (ModSec PR 2201) on November 13, 2019. He also wrote to the ModSec security contact to make sure the underlying issue was now resolved quickly. The CRS project wrote a similar, yet more official notice, and the ModSecurity developers acknowledged the problem immediately.
CRS pressed for a rapid publication of a security release of libModSecurity 3 and urged the ModSecurity developers to inform affected webservers and ModSecurity intergrators. The ModSecurity developers insisted on an extended timeline aiming for a release in January (well within the 90 days period that seems to become a generally accepted grace period for responsible disclosure).
LibModSecurity 3.0.4 was released on January 13, 2020. Yesterday, the developers published a detailed analysis of the problem they had to solve on the SpiderLabs Blog. This post also includes first hand accounts of our developers @IamAirWeen and @Menin_theMiddle describing how they found the problem.
[EDIT: Updated wording around original patch of Ervin after an article in “The Daily Swig” made it look as if he introduced the problem. He did not. He just did not realize how bad the situation was when he wrote his first fix.]
By Christian Folini, Ervin Hegedüs and Andrea Menin
Christian Folini / [@ChrFolini]