GHSA-jwjp-4649-v8jp: Out-of-Bounds Read in SIPSorcery SCTP SACK Chunk Parsing

SIPSorcery is a C# .NET library utilized for building real-time communications such as WebRTC and VoIP applications. The library implements a complete Stream Control Transmission Protocol (SCTP) stack to support WebRTC Data Channels. Within the SCTP implementation, incoming messages are processed sequentially by a dedicated background receive thread.

This architecture exposes an attack surface via the parsing logic of specific SCTP chunk types. An unauthenticated remote attacker can exploit a vulnerability in the parsing of Selective Acknowledgment (SACK) chunks to disrupt communications. The vulnerability belongs to the out-of-bounds read class (CWE-125) and triggers an uncaught exception.

The structural impact of this vulnerability is a persistent denial of service (DoS) for the entire SCTP association. When a malformed packet is received, the processing thread encounters an unhandled exception and terminates without a recovery mechanism. This action drops all active and future WebRTC data channels negotiated on that association.

The root cause of this vulnerability lies in the missing input validation within the SctpSackChunk.ParseChunk method. A SACK chunk is used by an SCTP endpoint to acknowledge non-contiguous packets received. The chunk specifies two count parameters: the number of Gap Ack Blocks (N) and the number of Duplicate TSNs (M).

The parsing routine extracts these counts as 16-bit unsigned integers from the packet stream without verifying whether the actual byte buffer contains the corresponding payload size. Consequently, the parser attempts to read up to 65,535 Gap Ack Blocks and Duplicate TSNs. The physical buffer size allocated in the transport layer is fixed at 262,144 bytes.

If the remote peer specifies count values that exceed the size of the physical packet payload, the parsing loop continues past the actual data boundaries. Depending on the buffer index reached, this leads either to reading stale byte data left by previously processed packets or to attempting an out-of-bounds read that exceeds the physical 262,144-byte buffer allocation. The latter condition immediately triggers a System.IndexOutOfRangeException exception.

Analyzing the vulnerable code path clarifies the flow of execution. When an SCTP packet is read from the network, the transport loop processes chunks sequentially. The parser reads counts and enters a loop to extract individual elements using static helper methods.

// Vulnerable loop in SctpSackChunk.cs
ushort numGapAckBlocks = NetConvert.ParseUInt16(buffer, startPosn + 8);
ushort numDuplicateTSNs = NetConvert.ParseUInt16(buffer, startPosn + 10);
 
int reportPosn = startPosn + FIXED_PARAMETERS_LENGTH;
for (int i=0; i < numGapAckBlocks; i++)
{
    // Reads out-of-bounds if numGapAckBlocks is larger than actual payload
    ushort start = NetConvert.ParseUInt16(buffer, reportPosn);
    ushort end = NetConvert.ParseUInt16(buffer, reportPosn + 2);
    reportPosn += 4;
}

The patch addresses this structural vulnerability by verifying the required length against the declared chunk length before processing the loops. It ensures the chunk is physically long enough to store both the fixed header and the declared counts of blocks and TSNs.

// Patched logic in SctpSackChunk.cs
int requiredLen = SCTP_CHUNK_HEADER_LENGTH + FIXED_PARAMETERS_LENGTH
    + numGapAckBlocks * GAP_REPORT_LENGTH
    + numDuplicateTSNs * DUPLICATE_TSN_LENGTH;
 
if (requiredLen > chunkLen)
{
    throw new ApplicationException("The SCTP SACK chunk was too short for the counts specified.");
}

Additionally, defense-in-depth is implemented within the main transport receive loop. A catch block is registered for IndexOutOfRangeException and ArgumentException to prevent unhandled exceptions from terminating the background receiver thread permanently.

An attacker can exploit this vulnerability by sending a single, crafted SCTP SACK chunk to an established WebRTC connection. No authentication is required within the SCTP protocol layer once the connection has been established. The attacker only needs to know or guess the active communication channel and IP endpoints.

To trigger the denial of service, the attacker sets the numGapAckBlocks field to a high value (such as 65,535) in the chunk header while providing no trailing data. As the parser loops over the declared counts, the index increments beyond the 262,144-byte physical buffer allocation boundary. This forces the runtime to raise an unhandled exception.

If the specified count is smaller (e.g., 100) and does not exceed the absolute buffer limit, the loop reads stale memory instead. This does not crash the system immediately, but instead populates the internal SACK tables with garbage records, leading to state corruption, transport desynchronization, and silent data channel failures.

The security impact of this vulnerability is classified as a high-severity Denial of Service (DoS). Because SIPSorcery's SCTP implementation utilizes a single thread to handle the incoming WebRTC transport, the termination of this thread causes the entire WebRTC connection to freeze. Users on the affected session are disconnected, and no further data can be sent or received.

The secondary impact of silent state corruption presents a complex challenge. By feeding stale buffer memory containing historical packet data into the SACK state machine, an attacker can corrupt the transmission control variables. This can cause the library to drop packets, miscalculate packet round-trip times, or enter an endless retransmission loop.

This vulnerability is tracked under advisory GHSA-jwjp-4649-v8jp. While there are no active reports of wild exploitation, public proof-of-concept tests are available in the open-source repository. The low attack complexity and absence of prerequisite privileges elevate the overall operational risk.

The primary and recommended mitigation is to update the SIPSorcery dependency to a version containing the official patch. This is resolved in SIPSorcery Pull Request #1772 and commit a2466550bb2a28821c73fb1961bc33dcc467f8cf.

If immediate dependency updates are not possible, defensive mitigations must be implemented at the network level. A Web Application Firewall (WAF) or an Intrusion Detection System (IDS) can be configured to filter incoming SCTP packets. Rules should validate that incoming SCTP SACK chunks conform to the expected length requirements based on the declared block counts.

Developers using the library should ensure that their applications implement health-check mechanisms to detect dead transport threads. If WebRTC data channel activity ceases without a corresponding closure event, the application should programmatically tear down and rebuild the affected RTCPeerConnection to recover the service.