CVE-2019-11387 CVE-2019-11388 CVE-2019-11389 CVE-2019-11390 CVE-2019-11391

Debian Bug report logs - #928053
CVE-2019-11387 CVE-2019-11388 CVE-2019-11389 CVE-2019-11390 CVE-2019-11391

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Moritz Muehlenhoff <jmm@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: CVE-2019-11387 CVE-2019-11388 CVE-2019-11389 CVE-2019-11390 CVE-2019-11391

Date: Fri, 26 Apr 2019 23:12:34 +0200

Package: modsecurity-crs
Severity: grave
Tags: security

These are still being assessed upstream ATM:

CVE-2019-11391
https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1357

CVE-2019-11390
https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1358

CVE-2019-11389
https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1356
						
CVE-2019-11388
https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1354
								
CVE-2019-11387
https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1359

Cheers,
        Moritz

										

Message #12 received at 928053@bugs.debian.org (full text, mbox, reply):

From: Christian Folini <christian.folini@netnea.com>

To: 928053@bugs.debian.org, agi@inittab.org

Subject: Severity of bug #928053 is too high

Date: Sat, 11 May 2019 06:45:13 +0200

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

Message #17 received at 928053@bugs.debian.org (full text, mbox, reply):

From: Alberto Gonzalez Iniesta <agi@inittab.org>

To: control@bugs.debian.org, 928053@bugs.debian.org

Cc: Ervin Hegedüs <airween@gmail.com>

Subject: Adjusting severity

Date: Mon, 13 May 2019 16:51:05 +0200

severity 928053 important
thanks

Hi,

Thanks, Christian and Ervin, for your help. I'm lowering the severity of
this bug since it does not really affect Debian (as explained in
upstream link regarding this issue).

If anyone disagrees with this change, please get in touch with me before
raising it again.

Regards,

Alberto

-- 
Alberto Gonzalez Iniesta    | Formación, consultoría y soporte técnico
mailto/sip: agi@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

Message #24 received at 928053@bugs.debian.org (full text, mbox, reply):

From: Moritz Mühlenhoff <jmm@inutil.org>

To: Christian Folini <christian.folini@netnea.com>

Cc: 928053@bugs.debian.org, agi@inittab.org

Subject: Re: Severity of bug #928053 is too high

Date: Mon, 20 May 2019 23:03:46 +0200

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

Message #29 received at 928053@bugs.debian.org (full text, mbox, reply):

From: Alberto Gonzalez Iniesta <agi@inittab.org>

To: Moritz Mühlenhoff <jmm@inutil.org>, 928053@bugs.debian.org

Cc: Christian Folini <christian.folini@netnea.com>

Subject: Re: Bug#928053: Severity of bug #928053 is too high

Date: Tue, 21 May 2019 10:15:20 +0200

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: agi@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

Message #34 received at 928053@bugs.debian.org (full text, mbox, reply):

From: Christian Folini <christian.folini@netnea.com>

To: Moritz Mühlenhoff <jmm@inutil.org>

Cc: 928053@bugs.debian.org, agi@inittab.org

Subject: Re: Severity of bug #928053 is too high

Date: Tue, 21 May 2019 10:23:22 +0200

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

Message #39 received at 928053@bugs.debian.org (full text, mbox, reply):

From: Christian Folini <christian.folini@netnea.com>

To: Alberto Gonzalez Iniesta <agi@inittab.org>

Cc: Moritz Mühlenhoff <jmm@inutil.org>, 928053@bugs.debian.org

Subject: Re: Bug#928053: Severity of bug #928053 is too high

Date: Tue, 21 May 2019 10:24:51 +0200

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: agi@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

Message #44 received at 928053@bugs.debian.org (full text, mbox, reply):

From: Moritz Mühlenhoff <jmm@inutil.org>

To: Alberto Gonzalez Iniesta <agi@inittab.org>

Cc: Moritz Mühlenhoff <jmm@inutil.org>, 928053@bugs.debian.org, Christian Folini <christian.folini@netnea.com>

Subject: Re: Bug#928053: Severity of bug #928053 is too high

Date: Tue, 21 May 2019 21:57:55 +0200

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

Message #49 received at 928053@bugs.debian.org (full text, mbox, reply):

From: Moritz Mühlenhoff <jmm@inutil.org>

To: Christian Folini <christian.folini@netnea.com>

Cc: Moritz Mühlenhoff <jmm@inutil.org>, 928053@bugs.debian.org, agi@inittab.org

Subject: Re: Severity of bug #928053 is too high

Date: Tue, 21 May 2019 22:39:03 +0200

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

Message #54 received at 928053@bugs.debian.org (full text, mbox, reply):

From: Christian Folini <christian.folini@netnea.com>

To: Moritz Mühlenhoff <jmm@inutil.org>

Cc: 928053@bugs.debian.org, agi@inittab.org

Subject: Re: Severity of bug #928053 is too high

Date: Tue, 21 May 2019 23:19:31 +0200

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

Send a report that this bug log contains spam.