DTLS “ClientHello” Race Condition: A New Threat to WebRTC Security
Enable Security recently released a report detailing a newly discovered vulnerability in WebRTC, the open-standard technology enabling real-time communication between browsers. The vulnerability, termed the DTLS “ClientHello” Race Condition, exposes WebRTC implementations to potential Denial of Service (DoS) attacks, which could result in service disruptions and an impaired user experience.
The research, led by Alfred Farrugia and Sandro Gauci, revealed a weakness in the Datagram Transport Layer Security (DTLS) handshake within WebRTC, specifically in how WebRTC implementations handle ClientHello packets. According to Enable Security, “an adversary can send a malicious DTLS ClientHello message from any IP address to the expected port, potentially causing a ‘network race condition’ if the malicious message is processed before the legitimate one.” This race condition allows attackers to disrupt WebRTC sessions by injecting unauthorized ClientHello messages that are processed ahead of legitimate ones, affecting services reliant on WebRTC.
This vulnerability is particularly concerning as WebRTC applications typically rely on the ICE (Interactive Connectivity Establishment) protocol for media consent verification. However, ICE does not inherently verify the origin of DTLS packets over UDP. “The communication takes place over UDP, which does not inherently verify the authenticity of the packet’s source unless additional checks are implemented at the application layer,” noted Enable Security. This allows malicious packets to exploit a gap between the consent verification and DTLS handshake phases, resulting in potential DoS scenarios.
Enable Security’s tests spanned both open-source and proprietary WebRTC implementations. Open-source projects like Asterisk, FreeSWITCH, and RTPEngine were found vulnerable to the DoS issue, while testing also uncovered vulnerabilities in specific scenarios on Skype’s platform, especially during calls made to the PSTN (Public Switched Telephone Network). According to the report, “calls failed to establish correctly, with neither DTLS Alert messages nor any visual indications of an error appearing in the user interface.” This highlights the difficulty in detecting the issue during active calls, leaving users unaware of disruptions.
The consequences of such a vulnerability are significant: delayed connections, unestablished media streams, and even system-wide service interruptions. For instance, in Asterisk, a malicious ClientHello message sent from an unexpected IP terminated calls immediately, sending “a SIP BYE message from the Asterisk server, with the Reason header set to ‘Q.850;cause=0’.”
Enable Security suggests that developers address this vulnerability by enforcing stricter source verification for DTLS ClientHello packets. “To mitigate this vulnerability, developers must implement stricter checks on the source of DTLS ClientHello packets, ensuring they match the verified ICE candidate,” the report recommends. Such measures could prevent unauthorized packets from interfering with legitimate WebRTC connections.
The Enable Security team advocates for industry-wide collaboration to incorporate these changes into future updates of WebRTC’s standards, including RFC 8826 and RFC 8827. By doing so, WebRTC can bolster its defenses against sophisticated DoS tactics, ensuring a more reliable and secure communication experience.
