Bug#928053: Severity of bug #928053 is too high
On Tue, May 21, 2019 at 10:39:03PM +0200, Moritz Mühlenhoff wrote: > > Yes. Our plan is to bring out a fix and then get in touch and have 4 of the > > 5 > > CVEs rejected. Unfortunately, the fix is far more complicated than we had > > hoped for. But we have a pull request now, so this is getting closer. > > Ack, sounds good. If those get rejected, the Security Tracker will pick > it up from the MITRE feed. Good to know. Thank you. I'll keep posting here as well. Christian > > Cheers, > Moritz
Bug#928053: Severity of bug #928053 is too high
On Tue, May 21, 2019 at 10:23:22AM +0200, Christian Folini wrote: > > And the CVE description > > explicitly refers to ModSecurity, so if those reports are not correct, the > > CVE IDs should be rejected as MITRE. > > Yes. Our plan is to bring out a fix and then get in touch and have 4 of the 5 > CVEs rejected. Unfortunately, the fix is far more complicated than we had > hoped for. But we have a pull request now, so this is getting closer. Ack, sounds good. If those get rejected, the Security Tracker will pick it up from the MITRE feed. Cheers, Moritz
Bug#928053: Severity of bug #928053 is too high
Hi Alberto, On Tue, May 21, 2019 at 10:15:20AM +0200, Alberto Gonzalez Iniesta wrote: > Hi all, > > I'll try to clarify a bit on ModSecurity vs CRS, since I think it may be > a bit confusing. Indeed, it's much clearer now with your explanation. I'll update the CVE entries in the Debian security to reflect the negligible security impact, feel free to also lower the BTS severity. Cheers, Moritz
Bug#928053: Severity of bug #928053 is too high
Thanks for the clarification Alberto. Saw it only after I had sent my message. :) Have a good day! Christian On Tue, May 21, 2019 at 10:15:20AM +0200, Alberto Gonzalez Iniesta wrote: > 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
Bug#928053: Severity of bug #928053 is too high
Hello Moritz, Thank you for your feedback. On Mon, May 20, 2019 at 11:03:46PM +0200, Moritz Mühlenhoff wrote: > Thanks for chiming in, much appreciated! But I need some further > clarification. Sure. > CVEs are not assigned for regular expressions by itself. The CVEs are assigned based on the report of the researcher. The researcher reported a vulnerability in ModSecurity / CRS, yet he made it quite clear he has not even touch ModSecurity, but worked on the Regexes that he extracted from our rules. He assumed a vulnerable regex would directly lead to a vulnerable ModSecurity setup, but that is not necessarily the case. ModSecurity does have some (limited) protection against ReDoS included. Unfortunately, the protection in ModSecurity 3 is worse than in ModSecurity 2. Here is an example where the researcher talks about extracting the regexes without running them in ModSecurity: https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1356 We have also established the fact that 4 of the 5 findings can not be reproduced in ModSecurity and he did not challenge that statement. > And the CVE description > explicitly refers to ModSecurity, so if those reports are not correct, the > CVE IDs should be rejected as MITRE. Yes. Our plan is to bring out a fix and then get in touch and have 4 of the 5 CVEs rejected. Unfortunately, the fix is far more complicated than we had hoped for. But we have a pull request now, so this is getting closer. So this took far too long, but we are a volunteer ran project and the problem is tricky. It takes the time that it takes and we want to get this right, or we introduce new WAF bypasses and that would be worse than the ReDoS in our eyes. > > 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. Are we talking of ModSecurity or the ModSecurity Core Rule Set? https://packages.debian.org/stretch/libapache2-modsecurity clearly says that libapache2-mod-security2 comes in version 2.9.1. > 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. This is the contact we plan to use following our plan. The CVEs were requested by the researcher Somdev Sangwan himself before he got in touch with the project. He points to a known problem with our (historical) regular expressions. It's just that 4 out of 5 of his reports are bogus. On the other hand, this is no proof that there are not additional ReDoS weaknesses in the regular expressions. Some of the patterns are several thousand bytes wide. Go figure. > > > 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? Sorry. I was referring to ModSecurity 3 running on NGINX 1.4.x. The sentence was meant to read "ModSecurity 3 and thus CRS 3 and thus Debian Unstable ..." The default installation is not affected, but the two rules causing the problem are enabled at paranoia level 2, which is not the default. Best, Christian -- We used to think that if we knew one, we knew two, because one and one are two. We are finding that we must learn a great deal more about 'and'. -- Sir Arthur Eddington
Bug#928053: Severity of bug #928053 is too high
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
Bug#928053: Severity of bug #928053 is too high
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. > 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. > CVE-2019-11391 > Not affected. > -> > https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1357#issuecomment-487344464 > > CVE-2019-11390 > Not affected. > -> > https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1358#issuecomment-487344517 > > CVE-2019-11389 > Not affected. > -> > https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1356#issuecomment-487073750 > > CVE-2019-11388 > Not affected. > -> > https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1354#issuecomment-487070518 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. > 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? Cheers, Moritz
Bug#928053: Severity of bug #928053 is too high
The severity of this bug is set too high. It is not "grave" in the context of Debian. Here is why: 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. This means that ModSecurity has protection measures itself that save the WAF from this type of DoS. In the case of ModSecurity 2, it is the manual setting of the PCRE match limits that protect you and the default value is very low. ModSecurity 2 protects you from all of these RegEx weaknesses. ModSecurity 3 protects you from 4 of these 5 RegEx weaknesses. Number 5 is an issue, but only at higher Paranoia Levels which are disabled by default. Debian Stable comes wtih ModSecurity 2. Debian Testing comes with ModSecurity 3. So Debian Stable is not affected. Debian Testing is affected at PL 2 and higher. CVE-2019-11391 Not affected. -> https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1357#issuecomment-487344464 CVE-2019-11390 Not affected. -> https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1358#issuecomment-487344517 CVE-2019-11389 Not affected. -> https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1356#issuecomment-487073750 CVE-2019-11388 Not affected. -> https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1354#issuecomment-487070518 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 The CRS project is actively solving the problems that these issues bring. However, we want to solve them without changing the behavior of the WAF that could introduce other security problems for our users. And that is very tricky. Hope this brings some clarity and you can reduce the severity of the bug until we can deliver a solution. Cheers, Christian Folini, CRS Co-Lead
