CVE-2024-23744: Arm Mbed TLS DOS Vulnerability

CVE-2024-23744 Overview

CVE-2024-23744 is a denial-of-service vulnerability in Arm Mbed TLS 3.5.1. The flaw manifests during TLS 1.3 handshake processing. A remote client can send a ClientHello message without any extensions, which triggers a persistent handshake denial condition on the server. The issue is tracked under [CWE-400: Uncontrolled Resource Consumption].

Mbed TLS is widely deployed in embedded systems, IoT firmware, and constrained devices that rely on small-footprint TLS stacks. Successful exploitation degrades availability of any service terminating TLS 1.3 through the affected library.

Critical Impact

A single malformed TLS 1.3 ClientHello without extensions causes persistent handshake failures, preventing legitimate clients from establishing secure connections.

Affected Products

• Arm Mbed TLS 3.5.1
• Embedded products and firmware bundling Mbed TLS 3.5.1
• IoT devices and services exposing TLS 1.3 endpoints backed by Mbed TLS 3.5.1

Discovery Timeline

• 2024-01-21 - CVE-2024-23744 published to NVD
• 2025-06-04 - Last updated in NVD database

Technical Details for CVE-2024-23744

Vulnerability Analysis

The vulnerability resides in the TLS 1.3 handshake state machine of Mbed TLS 3.5.1. TLS 1.3 mandates that a ClientHello carry extensions such as supported_versions to negotiate the protocol version. When a client sends a ClientHello containing zero extensions, the server enters an error state it does not recover from. The handshake processing logic fails to reset internal state correctly, producing persistent denial of subsequent legitimate handshakes.

The issue is classified as uncontrolled resource consumption affecting availability only. Confidentiality and integrity are not impacted, but the affected TLS endpoint stops servicing new sessions until restart or remediation.

Root Cause

The root cause is improper input validation and state handling in the TLS 1.3 ClientHello parser. The parser does not gracefully reject an extension-less ClientHello as a fatal-per-connection error. Instead, the failure propagates into a global or session-persistent state, blocking future handshakes. Refer to the Mbed TLS GitHub Issue 8694 for upstream discussion.

Attack Vector

The attack vector is network-based and requires no authentication or user interaction. An unauthenticated remote attacker connects to any TLS 1.3 listener using the vulnerable library and sends a syntactically valid ClientHello with the extensions list omitted. The trigger is a single message and does not require protocol completion. The vulnerability mechanism is described in prose only; no verified public proof-of-concept code is referenced in the advisory.

Detection Methods for CVE-2024-23744

Indicators of Compromise

• Repeated TLS 1.3 handshake failures on services backed by Mbed TLS, particularly MBEDTLS_ERR_SSL_* errors logged immediately after a ClientHello.
• Inbound TLS connections originating from a single source IP that contain a ClientHello with an empty extensions block.
• Sudden drop in successful TLS session establishments on embedded or IoT endpoints while the process remains running.

Detection Strategies

• Inspect network telemetry for TLS 1.3 ClientHello records where the extensions length field equals zero, which violates RFC 8446.
• Correlate handshake failure spikes with service-level availability drops on TLS terminators using Mbed TLS.
• Deploy IDS or NDR signatures that flag malformed ClientHello messages lacking supported_versions.

Monitoring Recommendations

• Stream Mbed TLS application logs and TLS handshake metrics into the Singularity Data Lake using OCSF normalization for centralized correlation.
• Alert when TLS handshake success rates fall below baseline thresholds on devices running embedded TLS stacks.
• Track process health and connection counts on IoT gateways to detect persistent handshake denial conditions early.

How to Mitigate CVE-2024-23744

Immediate Actions Required

• Inventory all services and firmware bundling Mbed TLS 3.5.1 and prioritize internet-exposed TLS 1.3 endpoints.
• Upgrade to a fixed Mbed TLS release tracked in Mbed TLS GitHub Issue 8694.
• Restart affected services to clear any persistent denial state already triggered by exploitation attempts.

Patch Information

The vulnerability was reported and tracked upstream by the Mbed TLS maintainers. Apply the fix referenced in Mbed TLS GitHub Issue 8694 by upgrading to a patched release beyond 3.5.1. Embedded vendors shipping Mbed TLS should rebuild firmware against the fixed version and distribute updates to deployed devices.

Workarounds

• Restrict network access to TLS 1.3 listeners using firewall rules or allowlists where patching is delayed.
• Place a reverse proxy or TLS-terminating load balancer using a non-vulnerable stack in front of Mbed TLS endpoints.
• Disable TLS 1.3 on affected services and force TLS 1.2 only if operationally acceptable until the patch is applied.

# Example: restrict TLS endpoint exposure with iptables until patched
iptables -A INPUT -p tcp --dport 443 -s <trusted-cidr> -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j DROP