SIPGO: DoS via unvalidated WebSocket frame length

Summary

The WebSocket transport allocates a buffer from the frame payload length before validating its size, which can lead to an unauthenticated DoS.

Details

WSConnection.Read allocates a buffer from the declared WebSocket frame length before reading the payload (https://github.com/emiago/sipgo/blob/v1.4.0/sip/transport_ws.go#L400):

data := make([]byte, header.Length)   // header.Length is client-controlled, up to 2^63-1 (int64)

• NextFrame() reads only the frame header and never checks the length: wsutil.NewReader is created with no MaxFrameSize (0 = unlimited). ParseMaxMessageLength applies only downstream, not here.
• A value above the max slice size (e.g. 2^63-1) panics make. sipgo does not recover from this panic, so it crashes the whole server process.

PoC

Tested on emiago/sipgo v1.4.0 (latest).

After a normal WebSocket handshake, send one masked text frame consisting of the header only (no payload), declaring a huge length. The allocation runs as soon as the header is read.

0x81                                            FIN + text opcode
0xFF                                            MASK bit + length marker 127 (8-byte length follows)
0x7F FF FF FF FF FF FF FF                        declared length = 2^63-1  ->  make panics (crash)
<4-byte masking key>
(no payload)

This crashes the server process:

panic: runtime error: makeslice: len out of range

goroutine 23 [running]:
github.com/emiago/sipgo/sip.(*WSConnection).Read(...)
        /path/to/pkg/mod/github.com/emiago/[email protected]/sip/transport_ws.go:400 +0x2df
github.com/emiago/sipgo/sip.(*TransportWS).readConnection(...)
        /path/to/pkg/mod/github.com/emiago/[email protected]/sip/transport_ws.go:194 +0x266
created by github.com/emiago/sipgo/sip.(*TransportWS).initConnection in goroutine 21
        /path/to/pkg/mod/github.com/emiago/[email protected]/sip/transport_ws.go:167 +0x268

Suggested Fix

Set MaxFrameSize on the wsutil.NewReader.

Impact

Unauthenticated DoS. Any service using sipgo with a WS/WSS transport can be crashed by a single frame (panic), or forced to run out of memory.