Predictable DTLS Cookie in Erlang/OTP ssl

Executive Summary

This vulnerability exists in the Erlang/OTP ssl module's DTLS server implementation. During server startup, the function responsible for initializing the DTLS cookie secret sets it to an empty value instead of a random one. Because the HMAC used for cookie computation with an empty key is predictable, an attacker who observes the plaintext ClientHello message can compute and forge a valid DTLS cookie before the server rotates the secret (within 0 to 15 seconds).

The DTLS cookie is intended to prevent denial-of-service attacks by verifying the source address of clients, but this vulnerability allows an attacker to bypass that verification during the startup window, enabling handshake amplification attacks with spoofed source IP addresses.

Useful 0 Not Useful 0

Impact Analysis

This vulnerability can allow an attacker to bypass source address verification during the DTLS handshake startup window, enabling them to perform handshake amplification attacks using spoofed source IP addresses.

Such attacks can increase the risk of denial-of-service (DoS) conditions by forcing the server to allocate resources and perform expensive cryptographic operations for forged connections, potentially degrading service availability.

However, the vulnerability does not provide authentication bypass or direct access to sensitive data, and it requires the attacker to observe plaintext ClientHello messages during the short startup window.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability involves the DTLS server using a predictable cookie during the startup window (0 to 15 seconds after startup), allowing an attacker to bypass source address verification by forging a valid DTLS cookie.

Detection on your network or system would involve monitoring DTLS handshake traffic, specifically observing ClientHello messages and checking if forged DTLS cookies are accepted during the server startup period.

Since the vulnerability is related to the initialization of the cookie secret in the Erlang/OTP ssl module, you can also check the version of Erlang/OTP and ssl installed on your system to determine if it is vulnerable.

• Check Erlang/OTP and ssl versions to see if they are before the patched versions (OTP before 29.0.3, 28.5.0.3, 27.3.4.14 and ssl before 11.7.3, 11.6.0.3, 11.2.12.10).
• Capture DTLS handshake traffic using tools like tcpdump or Wireshark to analyze ClientHello messages and verify if DTLS cookies are being accepted without proper source address verification during server startup.
• Example command to capture DTLS traffic on UDP port 4433 (adjust port as needed): tcpdump -i <interface> udp port 4433 -w dtls_capture.pcap
• Use Wireshark to inspect the captured packets and look for DTLS ClientHello messages and cookie values during server startup.

Useful 0 Not Useful 0

Mitigation Strategies

The primary mitigation is to update Erlang/OTP and the ssl application to a patched version where the vulnerability is fixed.

• Upgrade Erlang/OTP to version 29.0.3, 28.5.0.3, 27.3.4.14 or later.
• Upgrade the ssl application to version 11.7.3, 11.6.0.3, 11.2.12.10 or later.

The fix involves initializing the previous_cookie_secret with a random value instead of an empty binary at server startup, preventing predictable cookie computation.

Until you can apply the update, consider minimizing the exposure window by restarting the DTLS server frequently or limiting network access during startup to reduce the risk of exploitation.

Useful 0 Not Useful 0

Compliance Impact

This vulnerability allows an attacker to bypass source address verification during the DTLS handshake startup window, enabling handshake amplification with spoofed source addresses. While the DTLS cookie mechanism is intended to mitigate denial-of-service attacks, this flaw weakens that protection temporarily.

Because the vulnerability enables potential denial-of-service amplification attacks and could allow unauthorized network activity, it may impact compliance with security requirements in standards like GDPR and HIPAA that mandate protection of data integrity and availability.

However, the vulnerability does not directly expose sensitive data or authentication credentials, and it does not involve user interaction or privilege escalation.

Organizations relying on Erlang/OTP DTLS servers should consider this vulnerability when assessing their risk posture and compliance with regulations that require robust network security controls to prevent denial-of-service and spoofing attacks.

Useful 0 Not Useful 0