CVE-2023-34462: Netty SniHandler DoS Vulnerability

CVE-2023-34462 Overview

CVE-2023-34462 is a resource exhaustion vulnerability in Netty, an asynchronous event-driven network application framework widely used for building high-performance protocol servers and clients. The vulnerability exists in the SniHandler class, which can allocate up to 16MB of heap memory for each channel during the TLS handshake process. When the handler or channel lacks an idle timeout, attackers can exploit this to cause memory exhaustion on TCP servers using the SniHandler.

The SniHandler class is designed to wait for the TLS handshake to configure an SslHandler according to the server name indicated by the ClientHello record. For this purpose, it allocates a ByteBuf using the value defined in the ClientHello record. Under normal circumstances, the packet size should be smaller than the handshake packet, but the code lacks proper validation checks, allowing attackers to craft malicious packets that trigger excessive memory allocation in the SslClientHelloHandler.

Critical Impact

Attackers can exhaust server memory by establishing multiple connections and triggering 16MB heap allocations per channel, leading to denial of service conditions on affected Netty-based applications.

Affected Products

• Netty versions prior to 4.1.94.Final
• Applications using Netty's SniHandler for TLS/SNI handling
• TCP servers implementing SNI-based SSL context selection

Discovery Timeline

• 2023-06-22 - CVE-2023-34462 published to NVD
• 2024-11-21 - Last updated in NVD database

Technical Details for CVE-2023-34462

Vulnerability Analysis

The vulnerability stems from improper resource allocation within Netty's SNI (Server Name Indication) handling mechanism. The SniHandler and its parent class AbstractSniHandler are responsible for parsing TLS ClientHello messages to extract the server name and configure the appropriate SSL context. During this process, the handler allocates a ByteBuf based on length values provided in the ClientHello record without adequate validation.

The root issue is that an attacker can craft a malicious ClientHello packet specifying an excessively large length value, causing the handler to allocate up to 16MB of heap memory per connection. When combined with the absence of idle timeouts on connections, this allows attackers to establish numerous connections and exhaust server memory resources.

Root Cause

The vulnerability is classified under CWE-400 (Uncontrolled Resource Consumption) and CWE-770 (Allocation of Resources Without Limits or Throttling). The AbstractSniHandler class did not impose a maximum length restriction on the client hello message buffer allocation. The code path trusts the length field from the incoming ClientHello record without bounds checking, allowing attackers to specify arbitrary allocation sizes up to 16MB.

Attack Vector

The attack is network-based and requires low privileges to execute. An attacker can exploit this vulnerability by:

1. Establishing a TCP connection to a Netty server using SniHandler
2. Sending a crafted TLS ClientHello packet with a manipulated length field
3. Triggering allocation of up to 16MB of heap memory on the server
4. Repeating the process across multiple connections to exhaust available memory

This vulnerability is particularly dangerous for servers without connection idle timeouts, as malicious connections can persist indefinitely while holding allocated memory.

// Security patch in AbstractSniHandler.java
// Source: https://github.com/netty/netty/commit/535da17e45201ae4278c0479e6162bb4127d4c32

     private String hostname;
 
     /**
-     * @param handshakeTimeoutMillis the handshake timeout in milliseconds
+     * @param handshakeTimeoutMillis    the handshake timeout in milliseconds
      */
     protected AbstractSniHandler(long handshakeTimeoutMillis) {
+        this(0, handshakeTimeoutMillis);
+    }
+
+    /**
+     * @paramm maxClientHelloLength     the maximum length of the client hello message.
+     * @param handshakeTimeoutMillis    the handshake timeout in milliseconds
+     */
+    protected AbstractSniHandler(int maxClientHelloLength, long handshakeTimeoutMillis) {
+        super(maxClientHelloLength);
         this.handshakeTimeoutMillis = checkPositiveOrZero(handshakeTimeoutMillis, "handshakeTimeoutMillis");
     }
 
     public AbstractSniHandler() {
-        this(0L);
+        this(0, 0L);
     }
 
     @Override

The patch introduces a new maxClientHelloLength parameter that allows developers to limit the maximum size of the client hello message buffer, preventing excessive memory allocation.

Detection Methods for CVE-2023-34462

Indicators of Compromise

• Unusual memory consumption patterns on Netty-based servers
• High number of TLS connections in handshake state without completing
• Heap memory exhaustion alerts or OutOfMemoryError exceptions in application logs
• Spike in TCP connections targeting TLS-enabled endpoints

Detection Strategies

• Monitor JVM heap usage for sudden spikes correlated with incoming TLS connections
• Implement alerting for abnormal connection rates to SNI-enabled endpoints
• Track the ratio of completed TLS handshakes versus initiated connections
• Review application logs for SniHandler or SslClientHelloHandler related exceptions

Monitoring Recommendations

• Deploy application performance monitoring (APM) to track memory allocation patterns
• Configure connection rate limiting at the network layer for TLS endpoints
• Set up alerts for memory usage thresholds on servers running Netty applications
• Monitor connection idle times and flag connections lingering in handshake state

How to Mitigate CVE-2023-34462

Immediate Actions Required

• Upgrade Netty to version 4.1.94.Final or later immediately
• Implement connection idle timeouts on all SniHandler configurations
• Apply network-level rate limiting for TLS connection establishment
• Review and harden firewall rules for publicly exposed Netty services

Patch Information

The vulnerability has been fixed in Netty version 4.1.94.Final. The patch introduces a maxClientHelloLength parameter in the SniHandler and AbstractSniHandler constructors, allowing developers to limit the buffer allocation size during TLS handshake processing.

For detailed patch information, refer to the GitHub Security Advisory and the commit fix.

Additional advisories have been published by NetApp and Debian for downstream products.

Workarounds

• Configure handshake timeouts on SniHandler instances to limit connection duration
• Implement connection idle timeout handlers to close stale connections
• Use resource quotas and memory limits for Netty worker threads
• Deploy connection rate limiting at load balancer or firewall level

// Configuration example - Use SniHandler with timeout protection
SniHandler sniHandler = new SniHandler(
    mapping,
    16384,  // maxClientHelloLength - limit buffer allocation
    10000L  // handshakeTimeoutMillis - 10 second timeout
);

// Add idle state handler for additional protection
pipeline.addLast(new IdleStateHandler(30, 0, 0, TimeUnit.SECONDS));
pipeline.addLast(sniHandler);