GHSA-qw3h-qqm9-jrw8

Описание

Summary

The JWKS key fetching mechanism in uaa_jwt.erl does not validate the HTTP response status code when downloading signing keys from the OAuth2 provider's JWKS endpoint. Non-200 responses (including 4xx and 5xx errors) are processed identically to successful responses. When the JWKS endpoint returns an error response with a valid-JSON body that lacks a keys field, all previously cached signing keys are destroyed, causing a persistent authentication denial of service.

Vulnerability Details

Files:

• deps/rabbitmq_auth_backend_oauth2/src/uaa_jwt.erl, lines 50-63
• deps/rabbitmq_auth_backend_oauth2/src/uaa_jwks.erl, lines 5-7
• deps/rabbitmq_auth_backend_oauth2/src/rabbit_oauth2_provider.erl, lines 98-107

Bug 1: HTTP status code ignored (uaa_jwt.erl:50-63):

The Erlang httpc module returns {ok, {{HttpVersion, StatusCode, ReasonPhrase}, Headers, Body}}. The pattern {ok, {_, _, JwksBody}} matches ANY successful HTTP transaction regardless of status code — a 500 Internal Server Error is processed exactly like a 200 OK.

Bug 2: No HTTP response validation in JWKS client (uaa_jwks.erl:5-7):

The raw httpc response is returned directly with no status code validation. Additionally, httpc defaults to autoredirect = true, meaning HTTP redirects are silently followed.

Bug 3: Key replacement destroys cached keys (rabbit_oauth2_provider.erl:98-107):

The existing jwks entry (containing all previously-fetched dynamic keys) is deleted via proplists:delete(jwks, ...) and replaced with maps:merge(static_signing_keys, new_keys). If new_keys is empty (from an error response), all dynamic JWKS keys are lost.

Attack Scenario

Precondition

RabbitMQ is configured with OAuth2 authentication using JWKS key discovery (the standard setup for Keycloak, Auth0, Azure AD, etc.).

Attack Chain

1. The JWKS endpoint is temporarily degraded (maintenance, overload, or attacker-initiated DoS on the IdP)
2. The degraded endpoint returns HTTP 500 with JSON body: {"error": "service unavailable"}
3. Attacker sends a JWT to RabbitMQ with an unknown kid header value
4. RabbitMQ's get_jwk/3 function doesn't find the key locally, triggers JWKS refresh (uaa_jwt.erl:120-127)
5. JWKS fetch returns {ok, {{"HTTP/1.1", 500, "Internal Server Error"}, _, "{\"error\":\"service unavailable\"}"}}
6. Pattern {ok, {_, _, JwksBody}} matches — status code 500 is ignored
7. jose:decode(...) returns #{<<"error">> => <<"service unavailable">>}
8. maps:get(<<"keys">>, ..., []) returns [] (no keys field in error response)
9. maps:from_list([]) returns #{} (empty map)
10. replace_signing_keys(#{}, Id) deletes all cached JWKS keys and stores only static keys (usually none)
11. Result: All subsequent JWT authentication fails — legitimate tokens are rejected because their signing keys no longer exist in the cache

Key Insight: Attacker-Triggered Refresh

The JWKS refresh is triggered automatically when a JWT arrives with an unknown kid (uaa_jwt.erl:120). An attacker needs only:

• Craft a JWT with a non-existent kid header
• Send it as the password in an AMQP SASL PLAIN authentication
• The server automatically attempts JWKS refresh

By repeatedly sending JWTs with unknown kid values, the attacker can trigger continuous JWKS refreshes. If ANY of these refreshes occur while the JWKS endpoint is degraded, all cached keys are destroyed.

Impact

• Persistent authentication DoS: Once keys are destroyed, ALL OAuth2/JWT authentication fails for all users until a new successful JWKS refresh occurs
• Amplification: A single attacker can deny access to all legitimate OAuth2 users across the entire RabbitMQ cluster
• Cascade risk: During IdP maintenance windows, a single unauthenticated request with an unknown kid triggers key destruction
• Recovery delay: Keys remain destroyed until another JWT with an unknown kid arrives (triggering another refresh) AND the JWKS endpoint has recovered

Steps to Reproduce

1. Configure RabbitMQ with OAuth2 authentication (JWKS-based key discovery)
2. Verify JWT authentication works normally
3. Simulate JWKS endpoint degradation (return HTTP 500 with body {"error":"down"})
4. Send AMQP connection with SASL PLAIN auth, username=unused, password=eyJhbGciOiJSUzI1NiIsImtpZCI6InVua25vd24ta2V5LWlkIn0.eyJzdWIiOiJ0ZXN0In0.fake (a JWT with unknown kid)
5. Check RabbitMQ logs: "Downloaded 0 signing keys"
6. Attempt legitimate JWT authentication — it fails (signing key not found)

Suggested Fix

Fix 1: Validate HTTP status code in uaa_jwt.erl:

Fix 2: Disable auto-redirect in JWKS fetch (uaa_jwks.erl):

Fix 3: Don't replace keys with empty set (uaa_jwt.erl):

References

• CWE-252: Unchecked Return Value
• CWE-754: Improper Check for Unusual or Exceptional Conditions
• RFC 7517: JSON Web Key (JWK) — JWKS endpoint should return proper HTTP status codes
• Commit tested: a155ee5