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
