Client read_onstatus allows CPU amplification via unbounded AMF object keys

[cursor]

Severity

Medium

Location

src/message/command.rs

Attacker

A malicious or compromised RTMP server (or MITM on misconfigured RTMPS) that the embedder connects to for connect / publish / play.

Controlled input

An onStatus AMF0 command whose info object contains thousands of key/value pairs (cheap boolean values), delivered as a complete RTMP message up to DEFAULT_MAX_MSG_LENGTH (4 MiB).

Attack path

1. Victim application calls Client::connect(), Client::publish(), or Client::play() against an attacker-controlled rtmp:// / rtmps:// endpoint.
2. During the AMF handshake, wait_for_command("onStatus") receives the malicious response and calls command::read_onstatus().
3. read_onstatus() iterates every object key with no MAX_OBJECT_KEYS cap (unlike read_connect() and amf0::skip_value() nested-object parsing).
4. Each non-level key triggers amf0::skip_value(), burning CPU proportional to key count (~40k+ keys fit in a single max-size message).

Impact

CPU exhaustion / event-loop monopolization on the embedder thread handling the client handshake. A server can force expensive parsing before the client reaches publish/play, enabling denial of service against applications that connect to untrusted RTMP endpoints.

Remediation

Apply amf0::MAX_OBJECT_KEYS (256) to the read_onstatus() object-key loop, consistent with other AMF command decoders.

[AlexanderWagnerDev]

Fixed by #105 (merged, building on #104): command::read_onstatus() now caps the AMF0 info-object key loop at amf0::MAX_OBJECT_KEYS, consistent with read_connect() and other command decoders.

---

Generated by Claude Code