CVE-2024-5971 Overview
A denial of service vulnerability was discovered in Undertow, a flexible high-performance web server written in Java. The vulnerability occurs when handling chunked HTTP responses, where the response hangs after the body has been flushed. While the response headers and body are successfully sent to the client, Undertow fails to send the expected 0\r\n termination sequence that signals the end of a chunked transfer encoding response. This causes clients to continue waiting indefinitely for additional data, resulting in uncontrolled resource consumption on the server side.
This vulnerability specifically affects environments running Java 17 with TLSv1.3 enabled, making it a targeted attack vector against modern Java deployments using the latest TLS protocol version.
Critical Impact
This vulnerability enables attackers to exhaust server resources through connection starvation, effectively rendering affected Undertow-based applications unavailable to legitimate users.
Affected Products
- Undertow (Java web server)
- Red Hat JBoss Enterprise Application Platform
- Red Hat Single Sign-On
Discovery Timeline
- July 8, 2024 - CVE-2024-5971 published to NVD
- November 21, 2024 - Last updated in NVD database
Technical Details for CVE-2024-5971
Vulnerability Analysis
This vulnerability falls under CWE-674 (Uncontrolled Recursion) and manifests as a resource exhaustion condition in Undertow's HTTP response handling mechanism. When a server using Undertow attempts to send a chunked HTTP response over a TLSv1.3 connection running on Java 17, the response lifecycle fails to complete properly.
In HTTP/1.1 chunked transfer encoding, the server signals the end of the response body by sending a final chunk with a size of zero (0\r\n\r\n). Undertow's implementation contains a flaw where this termination sequence is not transmitted under specific conditions involving Java 17's TLSv1.3 implementation. The client, expecting this termination, continues to wait for data that will never arrive, holding the connection open indefinitely.
Root Cause
The root cause lies in Undertow's interaction with Java 17's TLSv1.3 implementation during the response finalization phase. When the response body is flushed, the internal state machine responsible for sending the chunked encoding termination sequence fails to execute properly. This appears to be related to how Java 17 handles TLS record boundaries differently than previous Java versions, causing the final termination bytes to be lost or never written to the output stream.
Attack Vector
An attacker can exploit this vulnerability by making multiple requests to a vulnerable Undertow server that responds with chunked transfer encoding. Each request establishes a connection that remains open indefinitely due to the missing termination sequence. By initiating numerous concurrent connections, the attacker can exhaust the server's connection pool, thread resources, and file descriptors, ultimately preventing legitimate users from connecting.
The attack requires only network access to the target server and does not require authentication or any user interaction. The low complexity of exploitation, combined with the significant availability impact, makes this vulnerability particularly dangerous for internet-facing applications.
Detection Methods for CVE-2024-5971
Indicators of Compromise
- Abnormally high number of established HTTP connections in ESTABLISHED state that persist beyond expected timeout periods
- Server thread pool exhaustion with threads blocked waiting on I/O operations
- Increased memory consumption due to connection objects not being released
- Client-side timeout errors when connecting to affected services
- Log entries indicating connection or thread pool exhaustion
Detection Strategies
- Monitor the number of active HTTP connections and alert when thresholds exceed normal operational baselines
- Implement connection timeout monitoring to detect connections that remain open beyond expected response times
- Track Java thread states and alert on unusual numbers of threads blocked in network I/O operations
- Review server access logs for patterns of repeated requests from single sources without corresponding response completions
Monitoring Recommendations
- Configure application performance monitoring (APM) to track connection lifecycle metrics
- Enable JMX monitoring for Undertow connection pools and thread executors
- Set up alerts for connection pool saturation events
- Monitor network socket states using tools like netstat or ss to identify stuck connections
- Implement synthetic monitoring that validates complete HTTP response cycles including proper termination
How to Mitigate CVE-2024-5971
Immediate Actions Required
- Apply the latest security patches from Red Hat for affected products
- If immediate patching is not possible, consider temporarily disabling TLSv1.3 and using TLSv1.2 as a workaround
- Implement connection timeout configurations to forcibly close connections after a defined period
- Enable rate limiting to reduce the impact of potential exploitation attempts
- Review and harden connection pool and thread pool limits to ensure graceful degradation under attack
Patch Information
Red Hat has released multiple security advisories addressing this vulnerability across their product portfolio. Organizations should apply the appropriate patches based on their deployed products:
- Red Hat Security Advisory RHSA-2024:4392
- Red Hat Security Advisory RHSA-2024:4884
- Red Hat Security Advisory RHSA-2024:5143
- Red Hat Security Advisory RHSA-2024:5144
- Red Hat Security Advisory RHSA-2024:5145
- Red Hat Security Advisory RHSA-2024:5147
- Red Hat Security Advisory RHSA-2024:6508
- Red Hat Security Advisory RHSA-2024:6883
NetApp has also issued NetApp Security Advisory NTAP-20240828-0001 for affected NetApp products.
Additional details are available in the Red Hat CVE Details for CVE-2024-5971 and Red Hat Bug Report #2292211.
Workarounds
- Temporarily downgrade TLS configuration to use TLSv1.2 instead of TLSv1.3 until patches can be applied
- Configure aggressive connection timeouts at the load balancer or reverse proxy level
- Implement Web Application Firewall (WAF) rules to detect and block potential DoS patterns
- Consider using a different Java runtime version if Java 17 is not strictly required
- Deploy the application behind a reverse proxy that handles chunked encoding termination independently
# Configuration example - Disable TLSv1.3 in Java 17 as temporary workaround
# Add to JVM startup options:
-Djdk.tls.client.protocols=TLSv1.2
-Djdk.tls.server.protocols=TLSv1.2
# Or configure via security properties file:
# Edit $JAVA_HOME/conf/security/java.security
# Add or modify:
jdk.tls.disabledAlgorithms=TLSv1.3
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
