GHSA-pfvm-w89x-94jw

## Summary `TurnServer.ReceiveUdpAsync` places its generic `catch (Exception)` OUTSIDE the `while` receive loop, and `Start()` launches the loop fire-and-forget with no supervision or restart. A single pre-authentication UDP datagram whose STUN header first byte is in `0x80–0xFF` causes `STUNHeader.ParseSTUNHeader` to throw `ApplicationException`, which unwinds past the loop and terminates it. The TURN UDP relay is then dead for ALL clients until the process is restarted. ## Root Cause `src/SIPSorcery/net/TURN/TurnServer.cs`: - `ReceiveUdpAsync` (:555-577): the inner `try` (:562-567) wraps only `_udpSocket.ReceiveAsync()`; `HandleUdpDatagram(result.Buffer, result.RemoteEndPoint)` (:569) is inside the `while` body but OUTSIDE that inner try. The generic `catch (Exception ex)` (:573) is lexically OUTSIDE the `while`. - `Start()` does `_ = ReceiveUdpAsync();` (:381) — fire-and-forget, no restart. - `HandleUdpDatagram` (:579) calls `STUNMessage.ParseSTUNMessage(data, data.Length)` (:600) for any non-ChannelData datagram; `ParseSTUNMessage` (STUNMessage.cs:94) has no try/catch. ## Impact `ApplicationException` propagates out of the `while`, is caught at :573, logged, and the method returns. `_running` remains true but nothing re-invokes `ReceiveUdpAsync` → TURN UDP relay permanently unavailable for all clients (whole-server DoS). Pre-authentication: STUN parsing precedes any TURN allocation/credential check. ## Proof of Concept Send one UDP datagram to the TURN port (default 3478) with first byte `0x80` (e.g. `80 00 00 00`). `0x80 & 0xC0 = 0x80 ≠ 0x40` → not ChannelData → `ParseSTUNMessage` → `ParseSTUNHeader` executes `if ((Array[startIndex] & 0xC0) != 0) throw new ApplicationException(...)` (STUNHeader.cs:169-172); `0x80 & 0xC0 = 0x80 ≠ 0` → throws. ## Attack Chain 1. Entry: one UDP datagram to the TURN port, first byte `0x80–0xFF`. Guard: ChannelData branch requires `(data[0] & 0xC0) == 0x40` (:583). Bypass: `0x80 & 0xC0 = 0x80 ≠ 0x40` → falls through to `ParseSTU