GHSA-JWJP-4649-V8JP

Vulnerability from github – Published: 2026-08-12 19:30 – Updated: 2026-08-12 19:30
VLAI
Summary
SIPSorcery vulnerable to Denial of Service via out-of-bounds read in SCTP SACK chunk parsing
Details

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 Concept

A 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 Chain

  1. Entry: 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.
  2. 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.
  3. 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.
  4. 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 Evidence

  • Unchecked 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).

Dedup

NOT 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 Fix

Validate 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

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 10.0.13"
      },
      "package": {
        "ecosystem": "NuGet",
        "name": "SIPSorcery"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "10.0.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-125",
      "CWE-755"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-12T19:30:43Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n`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 \u2014 permanently killing the SCTP association and all data channels.\n\n## Root Cause\n`src/SIPSorcery/net/SCTP/Chunks/SctpSackChunk.cs`:\n- `ushort numGapAckBlocks = NetConvert.ParseUInt16(buffer, startPosn + 8);` (:141)\n- `ushort numDuplicateTSNs = NetConvert.ParseUInt16(buffer, startPosn + 10);` (:142)\n- gap-ack loop (:146) and duplicate-TSN loop (:154) index the buffer via `NetConvert.ParseUInt16/32` (`buffer[posn]`, no bounds check \u2014 `sys/Net/NetConvert.cs:30,41`).\n`SctpPacket.ParseChunks` (SctpPacket.cs:195-203) only validates `chunkLength \u003e= 4` and `posn+chunkLength \u003c= length`; the counts inside the value are never checked. `RTCSctpTransport.DoReceive` calls `SctpPacket.Parse(recvBuffer, 0, bytesRead)` on a reused `recvBuffer = new byte[262144]`.\n\n## Impact\n`IndexOutOfRangeException` is a `SystemException`, not `ApplicationException`, so the recoverable `catch (ApplicationException) { \u2026 continue; }` at RTCSctpTransport.cs:345 is skipped and control falls to the generic `catch (Exception) { \u2026 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 \u2192 the SCTP association and every data channel are permanently dead (denial of service).\n\n## Proof of Concept\nA 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) \u2192 `IndexOutOfRangeException`.\n\n## Attack Chain\n1. Entry: 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.\n2. Processing: `DoReceive` (RTCSctpTransport.cs:286) reads into reused `recvBuffer` (262144 bytes, :280) \u2192 `SctpPacket.Parse(recvBuffer, 0, bytesRead)` (:302) \u2192 `ParseChunks` \u2192 SACK dispatch (`SctpChunk.Parse` :340-341) \u2192 `SctpSackChunk.ParseChunk`. Guard: `ParseChunks` checks only `chunkLength\u003e=4` and `posn+chunkLength\u003c=length` (SctpPacket.cs:195-203). Bypass: `chunkLength=16` is well-formed; the counts are never validated.\n3. 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.\n4. Impact: at iteration 65529, `reportPosn = 28 + 65529*4 = 262144` \u2192 `buffer[262144]` \u2192 `IndexOutOfRangeException` \u2192 generic `catch` at RTCSctpTransport.cs:356 \u2192 `break` \u2192 receive thread exits, no restart \u2192 association permanently dead.\n\n## Bypass Evidence\n- Unchecked counts at SctpSackChunk.cs:141-142; loops at :146,:154.\n- `NetConvert.ParseUInt16` unchecked indexing (NetConvert.cs:30).\n- `ParseChunks` validates only `chunkLength` (SctpPacket.cs:195-203).\n- OOB math: `28 + 65535*4 = 262168 \u003e 262144`; buffer is 262144 (`DEFAULT_ADVERTISED_RECEIVE_WINDOW`, SctpAssociation.cs:62). `numGapAckBlocks` alone suffices \u2014 the dup-TSN loop is not needed.\n- `DoReceive` catch split: recoverable `catch(ApplicationException)` at :345 (`continue`) vs generic `catch(Exception)` at :356 (`break`); `_receiveThread` started once at :176.\n\n## Affected Versions\n`nuget:SIPSorcery \u003c= 10.0.13` (verified present on release tag v10.0.13 and HEAD da944543).\n\n## Dedup\nNOT a duplicate of GHSA-qmvg-569h-hqrh \u2014 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.\n\n## Suggested Fix\nValidate `startPosn + FIXED_PARAMETERS_LENGTH + numGapAckBlocks*4 + numDuplicateTSNs*4 \u003c= posn + chunkLen` before the loops, and/or make `NetConvert.Parse*` bounds-checked, and/or treat `IndexOutOfRangeException`/`ArgumentException` as recoverable in `DoReceive`.\n\n---\nReported by **zx (Jace)** \u2014 GitHub: @manus-use",
  "id": "GHSA-jwjp-4649-v8jp",
  "modified": "2026-08-12T19:30:43Z",
  "published": "2026-08-12T19:30:43Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sipsorcery-org/sipsorcery/security/advisories/GHSA-jwjp-4649-v8jp"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sipsorcery-org/sipsorcery/commit/a2466550bb2a28821c73fb1961bc33dcc467f8cf"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sipsorcery-org/sipsorcery"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "SIPSorcery vulnerable to Denial of Service via out-of-bounds read in SCTP SACK chunk parsing"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Loading…

Loading…

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.


Loading…