A recent critical vulnerability — CVE-2024-1635 — has been identified in Undertow, a prominent web server widely used in Java enterprise stacks. This flaw specifically impacts servers configured to use the wildfly-http-client protocol, a scenario common in enterprise deployments leveraging WildFly application servers. In essence, the vulnerability can be triggered by a malicious user who simply opens and immediately closes connections to the server’s HTTP port, resulting in a memory and file descriptor leak that can exhaust server resources and force a denial of service.

Vulnerability Basics

When your Undertow server is set up to support *HTTP upgrade* to the wildfly-http-client’s remoting protocol (think: Remoting over HTTP), a specific class (WriteTimeoutStreamSinkConduit) is involved in managing write timeouts.

If a remote client rapidly opens and closes a connection (for example, an attacker using a simple script), a flaw in how Undertow cleans up objects can cause it to orphan timeout tasks and leave connections unreleased. Over time (and not much time, if the attack is sustained), this will eat up system memory and file handles, eventually crashing your server or making it unresponsive.

The Flow of the Leak (Step-by-Step)

1. HTTP Client Connects: A client attempts a connection to the server's HTTP port and requests an upgrade to the remoting protocol.

2. WriteTimeoutStreamSinkConduit Allocation: As part of the HTTP upgrade process, Undertow creates a WriteTimeoutStreamSinkConduit object to monitor outgoing data.

3. Premature Disconnect: The client closes the connection *during* the upgrade process—before the full protocol handshake and before Undertow’s remoting infrastructure is notified.

4. Missed Notification: The outer HTTP layer is not properly informed that the remoting connection beneath it has already been closed. The WriteTimeoutStreamSinkConduit isn’t cleaned up.

5. Timeout Task Leaks: Each WriteTimeoutStreamSinkConduit schedules a timeout Runnable on the XNIO worker thread — effectively referencing the whole connection hierarchy.

6. Reference Retention: Because the scheduled tasks never get canceled, the entire object graph (conduit, connections, resources) stays in memory, never eligible for garbage collection.

7. Exhaustion: Thousands of repeated open/close sequences by an attacker (or even misbehaving clients) will rapidly exhaust both memory and open file descriptors.

Technical Snippet — The Leaky Code (Simplified)

Here’s a highly simplified example of the problematic pattern (source reference):

// Undertow code related to HTTP upgrade
public void handleUpgrade(HttpServerExchange exchange) {
    // ...omitted for brevity...
    SinkConduit conduit = new WriteTimeoutStreamSinkConduit(
        originalConduit, // wraps the original connection
        xnioWorker,      // will schedule the timeout on worker
        timeoutConfig
    );

    // At this stage, if client disconnects here...
    // The following resource is left dangling
    xnioWorker.schedule(timeoutTask, timeout, TimeUnit.MILLISECONDS);
    // NO clean up if RemotingConnection closes out from under us!
}

The core of the problem is the lack of deregistration—nothing cleans up the timeoutTask on disconnect, causing the XNIO thread to hold a strong reference to everything upstream.

Exploit Details — How an Attacker Would Abuse This

Any tool that rapidly opens and instantly closes sockets (e.g., using netcat, curl in a loop, or custom scripts) can trigger the leak.

Example Bash Loop (Proof-of-Concept)

while true; do
  { echo -e "GET / HTTP/1.1\r\nConnection: Upgrade\r\nUpgrade: remoting\r\n\r\n"; sleep .01; } | nc SERVER 808
done

This sends an HTTP upgrade request and immediately tears it down.

- If this runs from even a small botnet or on a local network, the target server’s memory and file descriptors will start climbing, sometimes spectacularly fast.

There is no authentication or privilege needed. This can be triggered by any anonymous Internet user if your endpoint is exposed!

File Descriptor Leak: Orphaned connections never close at the OS level.

- Denial of Service: Within minutes or even seconds under heavy attack, server is forced to reboot or becomes unresponsive.

Note: This affects not just Undertow itself, but also products using Undertow for HTTP+remoting connections, including many versions of WildFly.

Mitigation

- Update Immediately: The Undertow project and distributions using it (like WildFly) have released patched versions. Upgrade your instance as soon as possible.

Monitor file handle and memory usage for early signs of attack.

- Verify Your Deployment: Check if you are using wildfly-http-client protocol upgrades in your environment. If not needed, disable the feature.

References & Further Reading

- CVE-2024-1635 NVD Entry
- Undertow Security Advisory
- WildFly Security Announcement
- Upstream Undertow Patch PR

Conclusion

CVE-2024-1635 is a great example of how intricate and subtle resource leaks can have devastating effects, especially in network server software. If you run Java application servers using Undertow or WildFly’s HTTP remoting features, check your versions, patch immediately, and consider adding network-layer defenses. Prevention, in this case, is far easier than dealing with a crashed production system!

Timeline

Published on: 02/19/2024 22:15:48 UTC
Last modified on: 03/22/2024 19:15:08 UTC