GHSA-jwjp-4649-v8jp SIPSorcery vulnerable to Denial of Service via out-of-bounds read in SCTP SACK chunk parsing
Summary`SctpSackChunk.ParseChunk` reads the `numGapAckBlocks` and `numDuplicateTSNs` fields (each up to 65535) directly from an attacker-controlled SCTP SACK chunk and loops that many times reading 4 bytes per iteration, with no validation of the counts against the chunk length or the receive buffer. A single crafted SACK chunk from a negotiated WebRTC peer forces reads past the end of the 262144-byte receive buffer, raising `IndexOutOfRangeException`, which is not caught by the recoverable handler and terminates the dedicated SCTP receive thread — permanently killing the SCTP association and all data channels.Root Cause`src/SIPSorcery/net/SCTP/Chunks/SctpSackChunk.cs`:`ushort numGapAckBlocks = NetConvert.ParseUInt16(buffer, startPosn + 8);` (:141)`ushort numDuplicateTSNs = NetConvert.ParseUInt16(buffer, startPosn + 10);` (:142)gap-ack loop (:146) and duplicate-TSN loop (:154) index the buffer via `NetConvert.ParseUInt16/32` (`buffer[posn]`, no bounds check — `sys/Net/NetConvert.cs:30,41`).
`SctpPacket.ParseChunks` (SctpPacket.cs:195-203) only validates `chunkLength >= 4` and `posn+chunkLength <= length`; the counts inside the value are never checked. `RTCSctpTransport.DoReceive` calls `SctpPacket.Parse(recvBuffer, 0, bytesRead)` on a reused `recvBuffer = new byte[262144]`.Impact`IndexOutOfRangeException` is a `SystemException`, not `ApplicationException`, so the recoverable `catch (ApplicationException) { … continue; }` at RTCSctpTransport.cs:345 is skipped and control falls to the generic `catch (Exception) { … break; }` at :356. The `break` exits the receive loop, `DoReceive` returns, and the dedicated `_receiveThread = new Thread(DoReceive)` (:173, started once) exits with no restart → the SCTP association and every data channel are permanently dead (denial of service).Proof of ConceptA negotiated WebRTC peer (post-DTLS) sends a checksum-valid SCTP packet: 12-byte common header + a SACK chunk (type 3) with `chunkLength=16`, `numGapAckBlocks=0xFFFF`, `numDuplicateTSNs=0xFFFF`. CRC32C is attacker-computable. The gap-ack loop reaches `buffer[262144]` on a 262144-byte array (valid indices 0..262143) → `IndexOutOfRangeException`.Attack ChainEntry: post-DTLS negotiated peer sends a checksum-valid SCTP packet with a SACK chunk (`chunkLength=16`, `numGapAckBlocks=0xFFFF`). Guard: `VerifyChecksum` (CRC32C). Bypass: CRC32C is computable by the sender.Processing: `DoReceive` (RTCSctpTransport.cs:286) reads into reused `recvBuffer` (262144 bytes, :280) → `SctpPacket.Parse(recvBuffer, 0, bytesRead)` (:302) → `ParseChunks` → SACK dispatch (`SctpChunk.Parse` :340-341) → `SctpSackChunk.ParseChunk`. Guard: `ParseChunks` checks only `chunkLength>=4` and `posn+chunkLength<=length` (SctpPacket.cs:195-203). Bypass: `chunkLength=16` is well-formed; the counts are never validated.Sink: gap-ack loop (SctpSackChunk.cs:146) calls `NetConvert.ParseUInt16(buffer, reportPosn)` with `reportPosn` starting at `startPosn(16)+FIXED_PARAMETERS(12)=28`, climbing `+4` each iteration. Guard: none on the count. Bypass: `NetConvert.ParseUInt16` (NetConvert.cs:30) indexes `buffer[posn]` unchecked.Impact: at iteration 65529, `reportPosn = 28 + 65529*4 = 262144` → `buffer[262144]` → `IndexOutOfRangeException` → generic `catch` at RTCSctpTransport.cs:356 → `break` → receive thread exits, no restart → association permanently dead.Bypass EvidenceUnchecked counts at SctpSackChunk.cs:141-142; loops at :146,:154.`NetConvert.ParseUInt16` unchecked indexing (NetConvert.cs:30).`ParseChunks` validates only `chunkLength` (SctpPacket.cs:195-203).OOB math: `28 + 65535*4 = 262168 > 262144`; buffer is 262144 (`DEFAULT_ADVERTISED_RECEIVE_WINDOW`, SctpAssociation.cs:62). `numGapAckBlocks` alone suffices — the dup-TSN loop is not needed.`DoReceive` catch split: recoverable `catch(ApplicationException)` at :345 (`continue`) vs generic `catch(Exception)` at :356 (`break`); `_receiveThread` started once at :176.Affected Versions`nuget:SIPSorcery <= 10.0.13` (verified present on release tag v10.0.13 and HEAD da944543).DedupNOT a duplicate of GHSA-qmvg-569h-hqrh — that fix (`fe5a1fa`) touched only `SctpPacket.cs` (the chunk-cursor zero-length infinite loop, CWE-835). This is a distinct out-of-bounds read (CWE-125) in `SctpSackChunk` count loops, untouched by that fix.Suggested FixValidate `startPosn + FIXED_PARAMETERS_LENGTH + numGapAckBlocks*4 + numDuplicateTSNs*4 <= posn + chunkLen` before the loops, and/or make `NetConvert.Parse*` bounds-checked, and/or treat `IndexOutOfRangeException`/`ArgumentException` as recoverable in `DoReceive`.Reported by **zx (Jace)** — GitHub: @manus-use
CVSS v3.1 score: 7.5