WebRTC Race Condition Flaw Impacts Major Communication Platforms

A newly published white paper from Enable Security has exposed a critical flaw in WebRTC implementations, particularly in how DTLS “ClientHello” messages are processed, leaving several platforms vulnerable to denial-of-service (DoS) attacks. The vulnerability stems from improper source verification of DTLS packets, which could allow malicious actors to disrupt real-time communications across various services.

Impacting open-source and proprietary platforms

The research conducted by Enable Security focuses on the Datagram Transport Layer Security (DTLS) protocol, which ensures secure peer-to-peer connections in WebRTC. The vulnerability lies in the gap between ICE (Interactive Connectivity Establishment) media consent verification and the DTLS handshake. Since WebRTC applications often rely on UDP, which does not verify packet sources, an attacker could inject a malicious DTLS “ClientHello” message into the session, causing a race condition. If processed first, this can disrupt the connection and lead to service interruptions.

Key platforms identified as vulnerable include RTPEngine, Asterisk, FreeSWITCH, and even Skype's Public Switched Telephone Network (PSTN) services. These implementations failed to check the origin of the DTLS “ClientHello,” leading to the exploitation of the race condition. A detailed study of both open-source and proprietary platforms showed inconsistent handling of the issue, with some media servers handling attacks differently depending on configuration and port use.

DoS risk from packet verification gap

For example, while Asterisk properly terminated the session upon detecting malicious input, sending a DTLS alert, and closing the connection, RTPEngine left the session in an undefined state without alerting the user. FreeSWITCH was also vulnerable, especially in VoIP calls that bypass ICE consent verification. In the proprietary domain, Skype's PSTN services were found vulnerable, although standard peer-to-peer Skype calls were largely unaffected.

These findings are significant given the widespread use of WebRTC for voice and video communications, making the flaw a potential risk for millions of users worldwide. WebRTC is heavily utilized by services like Google Meet, Zoom, Discord, and others. Although some of these platforms have patched the vulnerability, others remain exposed.

The researchers propose that WebRTC implementors enforce stricter verification of DTLS “ClientHello” sources, particularly by matching them to the ICE candidate details used during the consent verification phase. They also recommend future updates to WebRTC-related RFCs to explicitly mandate these checks to close this gap.

To mitigate this threat, developers are encouraged to:

• Ensure that DTLS “ClientHello” packets are only processed if they come from the same source as the ICE candidate.
• Where ICE is not used, alternative mechanisms to verify packet origins based on signaling data should be implemented.
• Regularly update media servers and WebRTC implementations to the latest versions, as many open-source platforms have begun releasing patches.