The OWASP ModSecurity Core Rule Set team has reported a Denial of Service vulnerability in ModSecurity version 3.x that allows an attacker to send a crafted payload that exploits a flaw in how regular expressions are matched within the software. A CVE (CVE-2020-15598) was assigned to this vulnerability and it has been rated with a CVSSv3 score of 7.5 (high). Customers using HAProxy Enterprise are completely unaffected by this CVE because the load balancer touts a customized and hardened version of ModSecurity 3.x as one of the modes offered within its triple-mode Web Application Firewall (WAF).
The CRS team did a great job explaining this vulnerability in their blog post, so if you are interested in the technical aspects of it we suggested that you check out their blog post. We validated the HAProxy Enterprise WAF using the CRS team’s test rule:
We launched an attack by creating a 5MB specially crafted payload and sending it through HAProxy Enterprise with ModSecurity mode enabled:
As shown in the output of the curl command, the request was completed within one second. Upon examining the ModSecurity debug log, only a single TX variable is filled in. In other vulnerable software that we tested, this payload would hang the process for over 60 minutes.
The CRS team notes that in a vulnerable installation, ModSecurity 3.x will execute the regular expression function for each digit within a given numeric value, filling an individual TX variable per digit, leading to a denial-of-service condition for long numbers. Instead, HAProxy Enterprise acts as expected and immediately stops processing upon the first match.
HAProxy Enterprise is not susceptible to this regular expression DoS attack due to special hardening measures that were added. The first is support for a customized implementation of Re2, the regular expression library. There are a number of benefits to using Re2, which was designed with an explicit goal of being able to handle regular expressions from untrusted users without risk. Re2 also has the ability to limit the memory usage of a pattern matching operation and allows maximum memory limits to be defined. For those regex patterns that are not supported by Re2, we fallback to PCRE. HAProxy Enterprise also supports PCRE match limits through the configuration directives SecPcreMatchLimit and SecPcreMatchLimitRecursion as well as compile-time options that bring back some of the functionality from ModSecurity 2.x. We found that in many cases this functionality has proven to be better than what was done within ModSecurity 3.x.
The HAProxy Enterprise ModSecurity implementation also sets the TX variable TX:MSC_PCRE_LIMITS_EXCEEDED and generates a log message if any of these match limits are exceeded, allowing you to tune your configuration as needed. This is not the first time that ModSecurity 3.x was found to be vulnerable to regular expression DoS attacks: a similar issue was reported in CVE-2019-11387.
Several other hardening features also exist to prevent various forms of DoS attacks, including argument limits, malformed argument detection, and timeouts that can be set on a per rule and per request basis. HAProxy is known as the world’s fastest and most widely used software load balancer and it has a lengthy history of being battle-tested over almost 20 years. We take pride in bringing the same level of performance and reliability that you would expect from HAProxy to our enterprise suite.
If you’re an HAProxy Enterprise customer today and are harnessing the ModSecurity mode within our Web Application Firewall, you can rest assured that you are protected and do not need to make any changes or upgrades at this time. If you have any questions please contact our support team directly. If you aren’t a customer of HAProxy Enterprise today and you’d like to learn more, reach out and we’d be glad to get you started with a free trial.
