ModSecurity maintainers contest denial-of-service vulnerability claims

Core Rule Set developers say high-impact bug was introduced via undocumented changes to open source WAF

UPDATED The maintainers of the open source ModSecurity web application firewall (WAF) module have rejected claims that the technology is vulnerable to a denial-of-service (DoS) exploit that could halt servers running the software.

In a security advisory issued today (September 14), developers from the OWASP Core Rule Set (CRS) said ModSecurity v3 is exposed to DoS exploits due to the global matching of regular expressions (regex).

The vulnerability, CRS developers said, was introduced via undocumented changes to the underlying ModSecurity engine.

“The combination of a non-anchored regular expression and the ModSecurity ‘capture’ action can be exploited via a specially crafted payload,” the researchers said in their official advisory for CVE-2020-15598.

“While ModSecurity v2.x used to quit the execution of a regular expression after the first match, ModSecurity v3.0.x silently changed the behavior to global matching.”

According to the researchers, this results in a DoS for existing non-anchored regexes containing the ‘capture’ action.

Denial of denial-of-service

ModSecurity is a popular WAF that’s designed to help stop attacks or unwanted behavior against applications by monitoring all HTTP traffic in real time. The open source project is maintained by Trustwave SpiderLabs.

The tool works through the implementation of WAF rules. Web admins can create their own custom rules or deploy existing libraries, such as the free-to-install OWASP Core Rule Set.

Responding to The Daily Swig’s request for comment on the CRS developers’ purported discovery, a Trustwave spokesperson said that while changes were made to the ModSecurity engine, they did not introduce a security vulnerability:

There was a change in regular expression matching in ModSecurity 3.x (libModSecurity) that provided additional functionality for our users. We do not consider this a vulnerability for a couple of reasons.

First, there is no default configuration issue here. An attacker would need to know that a rule using a potentially problematic regular expression was in place.

Second, the attacker would need to know the basic nature of the regular expression itself in order to exploit any resource issues and while those resources issues may cause a slowdown for resources, we have not been able to replicate.

It’s well known that regular expression usage can be taxing on system resources regardless of the use case. It is up to the administrator to make the decision on when it is appropriate to trade resources for potential security benefit.

Back and forth

Christian Folini, co-lead of the OWASP Core Rule Set development team, called Trustwave’s response into question.

“As ModSecurity is only the engine, you need rules to expose the vulnerability,” Folini told The Daily Swig.

“To blame the problem on the rules does not make much sense in this architecture. It’s like stating that the server would have been secure if nobody has hooked it on the internet.”

He added: “Now, can you guess what rules are installed on the server? Most people have CRS installed when they run ModSecurity. And CRS has dozens of rules that are affected by this silent change of behavior.”

According to Folini, the CRS team has insisted that the ModSecurity maintainers fast-track a release that includes mitigations to the alleged vulnerability.

However, with SpiderLabs maintaining that the changes have not introduced a security flaw, the CRS team said it would roll out its own mitigations.

“We’ll provide users with the minimal patch for 3.0.4, so they can fix this themselves,” Folini said. “We'll also provide workarounds for users running CRS and being stuck on the old and insecure ModSecurity 3.0.4.”

Trustwave has released more information on the disputed CVE in a blog post.

“We continue to tune the regular expression functionality in ModSecurity based on the use cases our user base most commonly employ,” the spokesperson said.

“We expect the next release will cover both methods of regular expression matching (global and single matching) to provide users the ultimate in flexibility in rule development.”

This article has been updated with a link to the Trustwave blog.