GHSA-cw8c-4m83-9c6w

Описание

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/rabbitmq_trust_store/src/rabbit_trust_store.erl:145 · Authentication bypass (TLS)

Impact

TLS client-authentication bypass: an attacker who knows the issuer DN + serial of any whitelisted certificate can connect with a forged self-signed cert.

Description

The trust-store plugin installs a verify_fun that overrides {bad_cert, unknown_ca} / {bad_cert, selfsigned_peer} when the presented cert "matches" a whitelisted one. The match key is extract_issuer_id/1 → public_key:pkix_issuer_id/2 → {IssuerName, SerialNumber} — both fields are taken verbatim from the presented certificate body and contain no public-key, SKI, fingerprint or signature material. is_whitelisted/1 is a pure ets:member lookup; the stored full DER is used only for list/0 display and is never compared against the presented cert. cacerts is [], so the whitelisted cert is never used as a trust anchor for path validation either.

Exploit scenario

Operator whitelists client1.pem (Issuer=CN=ACME CA, Serial=0x2A). Attacker runs openssl req -x509 -subj '/CN=evil' -set_serial 42 ... and crafts the issuer / AKI extension to CN=ACME CA. Connects via AMQPS; OTP ssl emits {bad_cert, selfsigned_peer} → whitelisted/3 finds the ETS hit → {valid, confirmed} → TLS handshake succeeds with the attacker's own keypair. If ssl_cert_login is used, the attacker is authenticated as the cert's subject.

Preconditions

• rabbitmq_trust_store plugin enabled and used as the TLS verify_fun
• Attacker knows or can guess the {Issuer, Serial} of at least one whitelisted cert (non-secret; exposed via CLI/logs/any cert copy)

CVSS

CVSS v4.0: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N (9.1, Critical). Fixed in 3.13.15, 4.0.20, 4.1.11, 4.2.6, 4.3.0.