Bounds check the DCEP OPEN label and protocol lengths

[sipsorcery]

Fixes the DCEP OPEN parser bounds check reported in #1778.

Changes

DataChannelOpenMessage.Parse now checks the label and protocol lengths against the space actually left in the buffer before using them:

int variableLength = labelLength + protocolLength;
if (variableLength > buffer.Length - posn - DCEP_OPEN_FIXED_PARAMETERS_LENGTH)
{
    throw new ApplicationException("The buffer was not big enough for the label and protocol lengths in the DCEP open message.");
}

The lengths are summed as an int so a pair that only overflows when combined is caught, and neither value can wrap.

Malformed messages now surface as ApplicationException, consistent with the rest of the parser, so they are handled by the recoverable-error path in RTCSctpTransport.DoReceive rather than the defence-in-depth catch below it.

Also corrected two places where posn was ignored:

• the minimum length check compared buffer.Length against the fixed parameters length rather than the bytes remaining from posn
• the label and protocol were read from a hardcoded offset of 12 instead of posn + 12

Every current caller passes posn = 0, so this was latent rather than live, but it did not match the signature or WriteTo, which does honour posn.

Tests

New DataChannelOpenMessageUnitTest covering:

• round trip of a well formed message
• label length of 0xFFFF on a 12 byte buffer, the case from DCEP OPEN parser does not bounds check labelLength/protocolLength against the buffer #1778
• protocol length of 0xFFFF
• label and protocol lengths that each fit but overflow when summed
• a buffer shorter than the fixed parameters
• parsing at a non-zero posn, and a posn leaving too few bytes

All 7 pass, along with the 127 existing SCTP, WebRTC and data channel unit tests on net8.0.

Note on classification

#1778 arrived as a private security report. It is a genuine parser defect but not a vulnerability: reaching this code requires completing the DTLS handshake as the peer authenticated against the signalled fingerprint, and the only consequence is that the sender's own data channel does not open. Encoding.UTF8.GetString validates its arguments and throws before reading, so nothing is read past the buffer. The reasoning is recorded in the issue.

🤖 Generated with Claude Code