GHSA-pg59-5vwg-4jxq: High severity go/github.com/emiago/sipgo vulnerability
Summary
The stream parser allocates the SIP body buffer from the Content-Length header before validating its size, which can lead to an unauthenticated DoS.
Details
ParserStream.parseSingle allocates the body buffer from the declared Content-Length with no size check (https://github.com/emiago/sipgo/blob/v1.4.0/sip/parserstream.go#L195):
go body := make([]byte, contentLength) // contentLength is client-controlled, up to 2^32-1 (uint32)
The ParseMaxMessageLength (65535) check is in the caller ParseNext (https://github.com/emiago/sipgo/blob/v1.4.0/sip/parserstream.go#L132), and only runs after parseSingle has already allocated the buffer.
PoC
Tested on emiago/sipgo v1.4.0 (latest).
Send a single message with a large Content-Length and no body to a SIP server:
INVITE sip:victim@example.com SIP/2.0 Via: SIP/2.0/TCP attacker.example;branch=z9hG4bK1 From: <sip:attacker@attacker.example>;tag=1 To: <sip:victim@example.com> Call-ID: 1@attacker.example CSeq: 1 INVITE Content-Length: 4000000000 // <- a large Content-Length
Suggested Fix
Validate contentLength against ParseMaxMessageLength before the allocation.
Impact
Unauthenticated DoS. Any service using sipgo with a stream transport (TCP/TLS/WS/WSS) can be forced to run out of memory.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
go/github.com/emiago/sipgoto a version that resolves this vulnerability.Fixed in 1.4.1 - Compensating control
In sipgo's stream parser, validate the client-controlled contentLength against ParseMaxMessageLength before allocating the SIP body buffer in ParserStream.parseSingle.
Event History
Frequently Asked Questions
What systems are exposed to this denial of service?
SIP servers that use the affected stream parser to process SIP messages received over a network are exposed. An unauthenticated remote client can send a crafted SIP message with an oversized Content-Length value.
Does the configured maximum message length prevent the allocation?
No. The parser allocates the body buffer using the client-controlled Content-Length before the ParseMaxMessageLength check in the caller runs, so the 65535 maximum does not prevent the oversized allocation.
What does an attacker need to send?
The attacker needs only to send a single SIP message containing a very large Content-Length header; a message body is not required. The declared value can be up to 2^32-1 because it is parsed as a uint32.
What can be done if updating is not immediately possible?
The suggested mitigation is to validate Content-Length against ParseMaxMessageLength before allocating the body buffer. Network-level restrictions that prevent untrusted clients from reaching the SIP service can also reduce exposure, but no product-specific workaround is provided.