Diving into CVE-2022-23943 – a new Apache memory corruption vulnerability

A few days ago it was reported that the new Apache version 2.4.53 contains fixes for several bugs which exposed the users of the well known HTTP server to attacks: CVE-2022-22719 relates to a bug in themod_luamodules which may lead to Denial of Service after reading from a random memory Area, CVE-2022-22720 exposes the server to HTTP Smuggling attacks, CVE-2022-22721 exposes the server to a buffer overflow when handling large XML input, and CVE-2022-23943 is a vulnerability in themod_sedmodule, which when triggered can lead to DoS and possibly RCE. This post will focus on the latter.

mod_sedis an Apache module that provides the same functionality asGNU’s stream editor tool, sed, allowing the manipulation of streams. It can be used as an input filter in order to modify HTTP POST requests’ bodies, or alternatively as an output filter that modifies the server’s responses before they’re sent to the client.

我n this blog post we provide an overview of the Apache CVE-2022-23943 vulnerability and guidance on how to remediate the issue, as well as a mitigation option we’ve discovered as part of our research on this vulnerability.

This research also fuels our development ofcontextual analysisscanners, which automatically detect vulnerable configurations and applied mitigations to determine whether a CVE is exploitable in a specific application.

What is CVE-2022-23943?

CVE-2022-23943 is a Denial of Service vulnerability in themod_sedmodule of the Apache HTTP server. The vulnerability affects all Apache 2.4 versions up to 2.4.52 (inclusive), given themod_sedfilter is used for request or response editing.

This Apache vulnerability is caused due to mishandling of buffers, potentially allowing an Out-of-Bounds Write when requests or responses which contain large amounts of data are edited by the module.

Who is affected by CVE-2022-23943?

CVE-2022-23943 affects all 2.4.x versions of the Apache HTTP server up to and including version 2.4.52, when running with a non-default configuration where themod_sedfilter module is used for editing either requests or responses.

When configuringmod_sed, it is possible to add two types of filters –

1. AddInputFilter– This filter will process datareceived from the client, before forwarding it to the Apache server
2. AddOutputFilter– This filter will process data about to be sent from the Apache server, before forwarding it to the client

A vulnerable instance of Apache will have a configuration file with a Sed input or output filter on one of itsRouteorDirectorydirectives.

The following example illustrates a vulnerable configuration, where all requests to html files will be processed bymod_sed, which in turn will replace each character in the request’s body with the letter Z –

(the actual replacement logic does not affect the exploitability of this vulnerability)

Due to the fact that data from the client is usually untrusted (unlike data that already exists from the server), any server that adds an input filter (AddInputFilter) is much more likely to be affected by this issue.

---

Book a demo of Xray security tool!

Watch Xray in Action

---

Technical summary of CVE-2022-23943

Like the original GNU stream editor,mod_sedenablesusing regular expression patternsfor input and output stream modifications.

Since thefixing commitrevolves around changinginttypes (4 byte signed) toapr_size_ttypes (4 or 8 byte unsigned), triggering this issue involves sending very large packets, either sized at 2GB (to cause an integer signedness issue) or 4GB (to cause an integer overflow issue).

The vulnerability is triggered when theappendmem_to_linebuffunction, which is found insed1.c, invokes thememcpyfunction in order to write to the evaluated stream buffer.

There are actually two scenarios in which we were able to trigger the vulnerability. In the first one 4GB of data was sent to the server, which resulted in a crash when the functionsed_eval_bufferwas still processing the stream. The function’s call toappendmem_to_linebufresulted in an out-of-bounds write, due to a miscalculation of the buffer’s size:

我n the second scenario, the vulnerability was triggered using 2GB of data that was sent to the server. Since Apache supports request body sizes of up to 2GB, in this case the vulnerability was triggered when trying to finalize the stream buffer’s processing. This instance can be found in the call toappendmem_to_linebufwhich is invoked bysed_finalize_evalcallingappend_to_linebufin order to guarantee a null terminator is added to the end of the buffer:

What is the impact of CVE-2022-23943?

The vulnerability can be easily exploited by sending large amounts of data in the request’s body, if themod_sedfilter module is required to process said data, causing a Denial of Service and a short downtime for one of the HTTP server’s processes. If an attack were to be carried out by making multiple requests to the server over a long period of time, a complete Denial of Service can occur, causing all the server’s processes to shut down repeatedly.

How can you remediate CVE-2022-23943?

To remediate this Apache vulnerability, we recommend upgrading Apache to the latest version, which is currently 2.4.53. If it is not possible to upgrade, we highly recommend applying thepatchwhich fixes this vulnerability in themod_sedfilter module.

What mitigation options are available for CVE-2022-23943?

我n case upgrading Apache to the latest version or applying the patch aren’t possible, it is required to limit the POST method’s body size so that the vulnerability can’t be triggered. In order to do so, you’ll need to use theLimitRequestBodydirective in Apache’s configuration file.

The directive can be used to set a limit to the request size starting from 0 and up to 2GB of data.

For example to limit POST to 1GB of data, the following line can be added tohttpd . conf:

LimitRequestBody 1073741824

This mitigation only provides protection against attacks by malicious client requests, and not in the case wheremod_sedis used to modify large files (>2GB) that already exist on the vulnerable server.

Find vulnerable versions with JFrog Xray

我n addition to exposing newsecurity vulnerabilitiesand threats, JFrog provides developers and security teams easy access to the latest relevant information for their software with automated security scanning byJFrog Xray SCA tool.

JFrog Xray performs automatedContextual Analysisof CVEs, accelerating time to resolution of vulnerabilities that are actually exploitable in production. Stay tuned for future enhancements, including detection of CVEs’ applicability based on software configurations.

Stay up-to-date with JFrog Security Research

Follow the latest discoveries and technical updates from the JFrog Security Research team in oursecurity research blog postsand on Twitter at@JFrogSecurity.