GHSA-6gmw-wxch-cvvc

Описание

Summary

GET /api/shovels/vhost/{vhost}/{name} returns the raw stored dynamic-shovel definition, which contains src-uri and dest-uri with cleartext credentials for the shovel's source and destination brokers. The endpoint authorizes non-DELETE reads with the monitoring tag. A read-only monitoring user — who cannot create or manage shovels, and who is denied the equivalent read through the parameters API — can read another operator's external-broker passwords.

Details

The per-shovel management endpoint returns the stored runtime parameter verbatim, with no redaction, behind monitor-level authorization:

• deps/rabbitmq_shovel_management/src/rabbit_shovel_mgmt_shovel.erl: is_authorized/2 (:78-84) routes non-DELETE requests to rabbit_mgmt_util:is_authorized_monitor — the monitoring (or administrator) tag. to_json/2 (:73-76) returns rabbit_mgmt_format:parameter(Shovel) where Shovel is the raw rabbit_runtime_parameters:lookup/3 result from parameter/1 (:147-156).

The definition is stored unobfuscated. obfuscate_uris_in_definition/1 is invoked only when a worker spec is built, never on the storage or read path:

• deps/rabbitmq_shovel/src/rabbit_shovel_dyn_worker_sup_sup.erl:68,70 — the only call sites of obfuscate_uris_in_definition/1.
• deps/rabbitmq_shovel/src/rabbit_shovel_parameters.erl — validate/5 (:48) and notify/5 (:61) do not obfuscate; the term is written verbatim.
• deps/rabbitmq_management_agent/src/rabbit_mgmt_format.erl:214 — parameter(P) -> pset(value, pget(value, P), P), i.e. no redaction.

The privilege boundary this crosses: the standard parameters API returns the same credential-bearing definition only to policymaker/administrator:

• deps/rabbitmq_management/src/rabbit_mgmt_wm_parameter.erl — is_authorized/2 (:84-85) requires rabbit_mgmt_util:is_authorized_policies.

So GET /api/parameters/shovel/{vhost}/{name} denies a monitoring user (401), while GET /api/shovels/vhost/{vhost}/{name} returns the same cleartext credentials to that same user. The collection endpoint /api/shovels is not affected — it serves the credential-stripped shovel status — so this per-shovel endpoint is the gap.

Preconditions

• rabbitmq_shovel and rabbitmq_shovel_management enabled.
• A dynamic shovel whose URIs embed credentials, in a reporting state (running/starting/terminated) so it appears in shovel status. resource_exists/2 gates the GET on get_shovel_node/4 → rabbit_shovel_mgmt_util:status/2; a shovel that never reported status returns 404.
• The attacker has the monitoring tag and login access to the shovel's vhost. The status list is filtered per-vhost by filter_vhost_user/3 (rabbit_shovel_mgmt_util.erl:26-31), so this is a normal per-vhost monitoring account. It is still strictly below policymaker. The boundary here is the tag (monitoring vs policymaker), not vhost scoping.

Proof of concept

Reproduced live on rabbitmq:4-management (Docker).

Full script: poc-shovel-credential-disclosure.sh

Setup: user watcher with tags [monitoring] only (not policymaker/administrator) and vhost / login access with no resource permissions (^$ ^$ ^$). An administrator creates a running dynamic shovel leaky-shovel whose src-uri/dest-uri embed victim:sup3rs3cr3t.

As watcher:

The monitoring user recovers the cleartext password despite being denied by the parameters API.

Impact

Disclosure of credentials to external systems (the shovel's source and destination brokers) to a lower-privileged monitoring role. In a multi-operator or multi-tenant deployment this enables lateral movement to those external brokers using an operator's stored credentials, from an account that was only granted read-only observability.