There’s a Nasty Security Hole in the Apache Webserver

Here a security hole, there a security hole, everywhere a security hole. One of the latest is an obnoxious one labeled CVE-2022-30522. This is a Denial of Service (DoS) attack in the Apache HTTP Server‘s mod_sed module.

Is that ringing faint bells? If so, that’s because we’ve been here before. In March 2022, CVE-2022-23943, an Apache memory corruption vulnerability in mod_sed, was uncovered. This one was an out-of-bounds Write vulnerability that enabled attackers to overwrite heap memory. When you say, “overwrite heap memory,” you know it’s bad news. This impacted the Apache HTTP Server 2.4 version 2.4.52 and earlier versions.

New Problems

It was quickly fixed. But, Brian Moussalli, the JFrog Security Research team’s Security Research Tech Lead, worried that while the Apache code “fix resolved the issue, it created a new unwanted behavior.” Moussalli was right.

It turned out that the patch opened a new mod_sed vulnerability. The good news is it only impacts Apache HTTPD 2.4.5. It’s invoked when a mod_sed filter is used for request or response editing.

Before going deeper into the bug, let’s do a quick refresher course on what mod_sed does. Essentially mod_sed enables 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’ bodies, and as an output filter, it enables you to modify your server’s responses. In short, mod_sed can be very useful.

But, in this case, the latest vulnerability mishandles memory allocations while handling stream buffers. What happens is when the buffers reach a certain size, they are multiplied to avoid performing many calls to memory allocation functions. Sounds good, but when an attack forces too much data into them, the buffers exceed Apache’s memory limit. The result? The process aborts, and — pop! — you get a DoS.

Although Apache doesn’t think this bug is that big a deal.  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 balancing its impact on the one hand and the relative rarity of the mod_sed install base on the other.

Update Now

Me? Anything that has the potential to be a real pain in the rump and is also an easy fix gets patched ASAP. Just update to Apache HTTPD 2.4.54 or above. Then you’ll never need to worry about it.

If, for some reason, you can’t patch it, you can also stop external attacks exploiting it by limiting the POST method’s body size so it can never be triggered. To do that, enter a LimitRequestBody configuration statement in the Apache HTTPD configuration file (/etc/httpd/conf/httpd. conf) to 2GBs or less.

For example:

LimitRequestBody 107374182

This would stop any body-size data above 1 GB from being accepted. This isn’t perfect, though. JFrog states this “mitigation only provides protection 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 2GB is sent to the client.”

So again, the best thing to do is to patch your web server to 2.4.54 or above.