GHSA-97vp-pwqj-46qc Sliver Vulnerable to Authenticated OOM via Memory Exhaustion in mTLS/WireGuard Transports

• Go github.com/bishopfox/sliver: <= 1.7.3 (no fix yet)

Summary A Remote OOM (Out-of-Memory) vulnerability exists in the Sliver C2 server's mTLS and WireGuard C2 transport layer. The `socketReadEnvelope` and `socketWGReadEnvelope` functions trust an attacker-controlled 4-byte length prefix to allocate memory, with `ServerMaxMessageSize` allowing single allocations of up to ~2 GiB. A compromised implant or an attacker with valid credentials can exploit this by sending fabricated length prefixes over concurrent yamux streams (up to 128 per connection), forcing the server to attempt allocating ~256 GiB of memory and triggering an OS OOM kill. This crashes the Sliver server, disrupts all active implant sessions, and may degrade or kill other processes sharing the same host. The same pattern also affects all implant-side readers, which have no upper-bound check at all. --- Root Cause Analysis The C2 envelope framing protocol uses a 4-byte little-endian length prefix to delimit protobuf messages on the wire: ``` [raw_signature (74 bytes)] [uint32 length] [protobuf data] ``` In socketReadEnvelope, after reading the length prefix, the server immediately allocates a buffer of the attacker-specified size: ```go // server/c2/mtls.go const ServerMaxMessageSize = (2 * 1024 * 1024 * 1024) - 1 // ~2 GiB dataLength := int(binary.LittleEndian.Uint32(dataLengthBuf)) if dataLength 0`. The same pattern exists in socketWGReadEnvelope for the WireGuard transport. _Note: The same unbounded allocation pattern is also present in implant-side readers, though it poses no immediate risk to the server 1, 2, 3, 4._ --- Proof of Concept PoC Links: mtls_poc.go or Gist Version 1. Establish mTLS connection: Complete a valid TLS 1.3 handshake presenting a valid implant client certificate. 2. Negotiate yamux: Send the `MUX/1` preface to enter multiplexed stream mode. 3. Open concurrent streams: Open multiple yamux streams (up to 128). 4. Send malicious length prefix: On each stream, send a 74-byte raw signature buffer followed by a 4-byte length prefix claiming `0x7FFFFFFF` (2,147,483,647 bytes ≈ 2 GiB). No actual data needs to follow. 5. Result: Each stream triggers a `make([]byte, 0x7FFFFFFF)` allocation. With 128 concurrent streams, the server process attempts to allocate up to ~256 GiB of memory, causing the OS OOM killer to terminate the process. Impact • Server availability: The Sliver server process is killed. Active implant sessions are disrupted until the operator manually restarts the server. • Host degradation: On hosts with swap enabled, the OOM event may cause swap thrashing and degrade other services sharing the same host before the process is killed.