Loadbalancer.org appliances are not affected by this JSON parsing vulnerability in the ModSecurity WAF engine (CVE-2021-42717).
The vulnerability was discovered by OWASP ModSecurity Core Rule Set developer @AndreaTheMiddle. It affects both versions of the ModSecurity WAF engine (the traditional 'Apache module style' v2 and the newer "libmodsecurity" v3). Both engines are actively used across the globe to power huge numbers of web application firewalls. Trustwave, the current custodians and developers of the ModSecurity project, have published an official blog post covering the vulnerability.
Where does Loadbalancer.org fit in?
All WAF vendors and services using ModSecurity are affected by this vulnerability (unless they have the vulnerable piece of code disabled, by chance). Our load balancer appliances feature a built-in WAF, which can be deployed in front of a web service to provide an extra layer of security, where needed. Our WAF implementation is powered by the ModSecurity v2 WAF engine.
The recent Loadbalancer.org v8.6 product release features an overhauled WAF system which is secure from day one. Part of that overhaul included adding a new default WAF rule set: the Core Rule Set version 3. A significant amount of time and effort was put into making sure that CRS 3 works well and improves the overall WAF experience for our customers. I personally audited most of the CRS 3 source code, which led to me discovering a serious and previously unknown security bug. That problem was then patched, with everyone using the CRS benefiting from the fix. We take both security and contributing back to the community seriously.
Our v8.6 product update would have been hit by this new JSON vulnerability after release, but our due diligence and thoroughness meant that the release wasn’t rushed out containing a serious security flaw. More importantly, our close links and involvement with the free and open-source community meant that we had advanced warning and insight into this issue, giving us time to plan how to integrate the fix.
All of our existing product releases are completely unaffected as the vulnerable code was never compiled into our older WAF build.
The issue
I heard you like nested arrays, so I put a nested array in your nested array…
It's possible to build ‘deep’ structures with JSON, featuring multiple levels of nesting. One example of this is using nested arrays, for example:
{
"bar": [
[
[
1
]
]
]
}
This nesting may be easier to see when compressed on to a single line. The general pattern here is:
{"bar": [[[...[1]...]]] }
ModSecurity is typically compiled and configured to parse JSON requests. This allows it, for example, to sit in front of an API gateway and provide an added layer of security. The issue is that ModSecurity would dutifully parse as many levels of nested JSON as it was provided with. For very large parsing depths (imagine thousands of levels of nesting), ModSecurity’s CPU and memory usage became excessive, and individual requests would take as long as 30 to 60 seconds to process.
Imagine sending a non-stop stream of very deep JSON requests to a ModSecurity-powered WAF, consuming enormous amounts of its CPU time and memory: you've got a denial of service attack on your hands.
The resolution
Although Trustwave announced their plan back in August 2021 to end-of-life their support and development of ModSecurity, fortunately, Trustwave still had at least one ModSecurity developer on the books to be able to patch this new vulnerability.
The fix implements a new limit on the maximum depth of JSON that will be parsed, using the new ModSecurity configuration directive SecRequestBodyJsonDepthLimit. New releases of both the ModSecurity v2 and ModSecurity v3 engines, featuring the fix, are available now on GitHub.
Keeping you safe and secure
It can be all too easy to hit a WAF with a denial of service attack. It's great having hundreds (or even thousands) of rules in place performing pattern matching to detect and block malicious behaviour, but this security comes with a computational cost. Vulnerabilities like the one described arise when deficiencies are found in the code designed to enforce sensible limits on how much time and effort a WAF is willing to spend processing a single transaction. This is where commercial support shines.
With our links to the free and open-source software world, we spend time staying up to date and ahead of the curve so you don't have to. When software vulnerabilities are inevitably found (as is the case with all software), we test new vulnerabilities, release 'fix' updates if needed, and let you know when you need to update. You can rely on our knowledge and experience to keep you and your deployments safe and secure.