GHSA-p7x2-g5cq-fhmq

Описание

Summary

mediasoup's built-in SCTP stack (introduced in v3.20.0) authenticates SCTP state cookies using only hardcoded magic byte sequences rather than a per-instance HMAC keyed with a secret, violating RFC 9260 Section 5.1.3. An on-path attacker targeting a PlainTransport with SCTP enabled (and no SRTP/DTLS protection) can craft a forged COOKIE-ECHO chunk that passes all validation, establishing an unauthorized SCTP association and gaining the ability to inject DataChannel messages as a trusted peer.

Details

RFC 9260 Section 5.1.3 states: "An endpoint MUST use a one-time-use secret key to protect the State Cookie." The mediasoup implementation ignores this requirement. The state cookie is defined in worker/include/RTC/SCTP/association/StateCookie.hpp with the following structure (44 bytes total):

• Offset 0: Magic1 = "msworker" (hardcoded, 8 bytes)
• Offset 8: localVerificationTag (4 bytes, attacker-controlled)
• Offset 12: remoteVerificationTag (4 bytes, attacker-controlled)
• Offset 16-27: TSN and window fields (attacker-controlled)
• Offset 28: tieTag (8 bytes, attacker-controlled)
• Offset 36: NegotiatedCapabilitiesField containing Magic2 = 0xAD81 (hardcoded)

The validation function StateCookie::IsMediasoupStateCookie() in worker/src/RTC/SCTP/association/StateCookie.cpp only checks:

1. bufferLength == 44
2. bytes[0:8] == "msworker" (Magic1, always the same)
3. ntohs(bytes[38:40]) == 0xAD81 (Magic2, always the same)

No HMAC, no per-session secret, no nonce. All "magic" values are published constants in the public header.

When a COOKIE-ECHO is received in Association::HandleReceivedCookieEchoChunk() (without an existing TCB), the sole security check is:

Because the attacker controls both the SCTP packet header's verification tag field AND the localVerificationTag field inside their crafted cookie, this check is trivially satisfied by setting both to the same attacker-chosen value.

Additionally, Association::ValidateReceivedPacket() explicitly skips verification-tag validation for COOKIE-ECHO packets (line 1153 in Association.cpp), and the SCTP CRC32c checksum function Packet::ValidateCRC32cChecksum() exists but is never called in the packet-reception path, so a forged packet with any checksum is accepted.

This vulnerability affects PlainTransport with SCTP enabled when used without SRTP (SRTP is optional via srtpCryptoSuite parameter). WebRtcTransport is NOT affected because its SCTP runs inside a DTLS session. comedia mode (default: false) increases exposure by accepting packets from any source IP.

PoC

Prerequisites: mediasoup server running with a PlainTransport that has SCTP enabled and no SRTP (srtpCryptoSuite not set). The server's UDP IP:port must be reachable.

The following Python script constructs and validates a forged SCTP state cookie that passes all mediasoup validation checks:

Observed output when run:

To forge the full SCTP packet on the network: wrap the 44-byte cookie in a COOKIE-ECHO chunk (type=0x0A), set the SCTP common header's Verification Tag to LOCAL_VT, compute a valid CRC32c checksum (or any value - the checksum is never verified on receive), and send the UDP packet from the permitted source address (or any source if comedia=true).

Impact

Any mediasoup deployment using PlainTransport with SCTP enabled and no SRTP is affected when an attacker occupies a network position where they can send UDP packets from the transport's configured peer address (or when comedia mode is enabled). The attacker can skip the standard SCTP 4-way handshake entirely and directly send a forged COOKIE-ECHO to establish an association, then inject arbitrary DataChannel messages as if they were the trusted peer. This can cause data integrity violations in server-to-server SCTP channels (e.g., SFU interconnects) or enable denial of service by preempting the legitimate peer's association.