Hi all, I'll try to clarify a bit on ModSecurity vs CRS, since I think it may be a bit confusing.
On Mon, May 20, 2019 at 11:03:46PM +0200, Moritz Mühlenhoff wrote: > On Sat, May 11, 2019 at 06:45:13AM +0200, Christian Folini wrote: > > Hi Christian, > > Thanks for chiming in, much appreciated! But I need some further > clarification. > > > The Core Rule Set project explained the situation in > > https://coreruleset.org/20190425/regular-expression-dos-weaknesses-in-crs/ > > > > The CVEs were issues against the Regular Expression itself, not CRS running > > on ModSecurity. > > CVEs are not assigned for regular expressions by itself. And the CVE > description > explicitly refers to ModSecurity, so if those reports are not correct, the > CVE IDs should be rejected as MITRE. Moritz, the descriptions explicitly refer to CRS: "An issue was discovered in OWASP ModSecurity Core Rule Set (CRS)" > > Debian Stable comes wtih ModSecurity 2. > > Debian Testing comes with ModSecurity 3. > > Debian stable actually has 3.0.0, but it doesn't matter here. There's 2 (or 3) separate "concepts" in this discussion: - ModSecurity. The WAF, usually a web server module (more on this later) - ModSecurity CRS. A collection of rules for the WAF. Debian stable has: - ModSecurity 2 (2.9.1) as an Apache2 module. - ModSecurity CRS 3.0.0. Which is "just" a collection of rules (as in the Regular Expressions). Buster will have (hopefully): - ModSecurity 2 (2.9.3) as an Apache2 module. - ModSecurity CRS 3.1.0. AND - libmodsecurity3 (3.0.3) as a library that can/will be used by future developments like an nginx, or apache, module no yet in Debian. > So if there's no circumstance where this triggers in modsecurity-crs, the > four CVE ID > should be rejected. Otherwise this will only cause confusion. Do you know who > requested > these? Rejects can be requested via https://cveform.mitre.org -> Select a > request type > -> Request an update to an existing CVE Entry. The thing is, this issue does not only depend on the regexps (in CRS) but in how the WAF using CRS deals with them. ModSecurity 2 (the apache module in stable and buster) has limits on regexps to avoid this kind of issues). ModSecurity 3 (the library), as Christian explained, has protection for most of this issues (4 out of 5), but... no package is actually using ModSecurity 3 yet. So the impact of this on Debian is close to none... > > CVE-2019-11387 > > ModSecurity 3 and thus NGINX 3 and thus Debian Unstable is affected at > > Paranoia Level 2 and above. The default setting is Paranoia Level 1. > > -> > > https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1359#issuecomment-487344654 > > I don't understand. What does Nginx 3 have to do with it? There's not even > such a version in unstable, the latest is 1.14.2? Christian was referring to ModSecurity's nginx module still under development and NOT in Debian. I hope this mail was useful. Regards, Alberto -- Alberto Gonzalez Iniesta | Formación, consultoría y soporte técnico mailto/sip: a...@inittab.org | en GNU/Linux y software libre Encrypted mail preferred | http://inittab.com Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D 4BF2 009B 3375 6B9A AA55
