A safety hole here, a safety hole there, a safety hole everywhere. One of the newest is an annoying one labeled CVE-2022-30522. This is a Denial of Service (DoS) attack in the mod_sed module of the Apache HTTP Server.
Is that a faint bell ringing? If so, it’s because we’ve been here before. In March 2022, CVE-2022-23943, an Apache memory corruption vulnerability in mod_sed, was discovered. This was an out-of-bounds Write vulnerability that allowed attackers to overwrite heap memory. When you say, “overwrite heap memory”, you know it’s bad news. This affected Apache HTTP Server 2.4 version 2.4.52 and earlier.
It was quickly resolved. But Brian Moussalli, the Security Research Tech Lead of the JFrog Security Research team, was concerned that although the Apache code “solved the problem, it caused a new unwanted behavior.” Moussalli was right.
It turned out that the patch opened a new mod_sed vulnerability. The good news is that it only affects Apache HTTPD 2.4.5. It is called when a mod_sed filter is used to edit requests or responses.
Before we dig deeper into the bug, let’s do a quick refresher on what mod_sed does. Essentially, mod_sed allows you to use a steam editor, yes, the classic Unix sed, to manipulate input and output streams for server requests. As an input filter it can be used on HTTP POST requests and as an output filter you can change your server’s responses. In short, mod_sed can be very useful.
But in this case, the latest vulnerability mishandles memory allocations when processing stream buffers. What happens is that when the buffers reach a certain size, they are multiplied to avoid making many calls to memory allocation functions. Sounds great, but when an attack forces too much data into it, the buffers exceed Apache’s memory limit. The result? The process aborts, and – pop! – you get a DoS.
Although Apache doesn’t consider this bug that much of a problem. They rank its severity as ‘low’. The National Vulnerability Database (NVD) disagrees. The NVD gives it a Common Vulnerability Scoring System (CVSS) score of 7.5 (high). JFrog puts it in the middle thanks to the balancing of impact on the one hand and the relative rarity of the mod_sed install base on the other.
Me? Anything that has the potential to be a real trunk pain and also an easy fix will be patched ASAP. Just update to Apache HTTPD 2.4.54 or higher. Then you never have to worry about it.
If for some reason you can’t patch it, you can also prevent external attacks from taking advantage of it by limiting the body size of the POST method so that it can never be triggered. To do that, enter a LimitRequestBody configuration statement in the Apache HTTPD configuration file (/etc/httpd/conf/httpd.conf) up to 2 GB or less.
This would prevent data with a body size greater than 1 GB from being accepted. However, this is not perfect. JFrog states that this “limitation only protects against a DoS caused by client requests, but still leaves the server vulnerable to DoS if mod_sed is used to modify web responses and a response larger than 2 GB is sent to the client.”
So again, best to patch your web server to 2.4.54 or higher.
The New Stack is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: JFrog.
Featured image by mohamed Hassan from Pixabay.