Описание
Atom-table exhaustion via reply-to queue name decoding
Origin
This vulnerability was identified by Team RabbitMQ and/or other teams at Broadcom, not via a responsible disclosure from an external researcher.
Source references
deps/rabbit/src/rabbit_pid_codec.erl:40 · Resource exhaustion (atom table DoS)
Impact
Any authenticated AMQP client can crash the entire Erlang VM (all vhosts, all connections) with ~1M cheap requests.
Description
rabbit_pid_codec:decompose_from_binary/1 parses a caller-supplied ETF-encoded binary and calls binary_to_atom(Node, utf8) on the node-name field. It is reached from rabbit_volatile_queue:pid_from_name/2, which is invoked for any queue name / routing key beginning amq.rabbitmq.reply-to.. The CandidateNodes membership check happens after the atom is created, and the surrounding try/catch cannot reclaim atoms (they are never GC'd). binary_to_existing_atom is not used.
Exploit scenario
Attacker crafts PidBin = <<131,88,119,Len,RandomNodeName:Len/binary,0:32,0:32,0:32>>, base64-encodes it, and either (a) sends basic.publish to the default exchange with routing key amq.rabbitmq.reply-to.<B64>.x (requires only write on the empty exchange name), or (b) sends queue.declare with that queue name (no permission check at all — rabbit_channel.erl:2353-2358 ignores _User). Each unique RandomNodeName allocates one permanent atom; ~1M requests fill the default 1,048,576-entry atom table and the VM aborts with system_limit.
Preconditions
- Authenticated AMQP 0-9-1 connection to any vhost
- No per-connection rate limit low enough to make ~1M operations infeasible
CVSS
CVSS v4.0: CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N (7.1, High). Fixed in 4.2.7, 4.3.1.
Пакеты
rabbitmq
>= 4.2.0, < 4.2.7
4.2.7
rabbitmq
>= 4.3.0, < 4.3.1
4.3.1