Ramachandran Krishnan created RANGER-5693:
---------------------------------------------
Summary: RangerJwtAuthHandler logs full JWT bearer token on
validation failure (CWE-532)
Key: RANGER-5693
URL: https://issues.apache.org/jira/browse/RANGER-5693
Project: Ranger
Issue Type: Task
Components: Ranger, ranger-authn
Affects Versions: 2.8.0
Reporter: Ramachandran Krishnan
Assignee: Ramachandran Krishnan
Fix For: 3.0.0, 2.9.0
h2. Summary
Apache Ranger's JWT authentication handler ({{{}RangerJwtAuthHandler{}}}) logs
the full
serialized JWT bearer token (header.payload.signature) at WARN level when token
validation fails. For some failure modes—especially audience mismatch after a
valid signature and unexpired token—the logged credential remains live and can
be
replayed against another Ranger JWT endpoint that trusts the same signing
material
and accepts the token's audience.
h2. Reporter
Andrew Rukin (Arenadata) — reported via ASF Security Team (private disclosure).
Classification: CWE-532 (Insertion of Sensitive Information into Log File).
h2. Affected component
* Module: {{ranger-authn}}
* Class: {{org.apache.ranger.authz.handler.jwt.RangerJwtAuthHandler}}
* Method: {{authenticate(String jwtAuthHeader)}} — validation-failure WARN path
* Also used via: {{RangerDefaultJwtAuthHandler}} (Admin, PDP, audit paths,
etc.)
h2. Affected versions
Verified on Apache Ranger 2.8.0. Same pattern present on ranger-2.8, ranger-2.9,
and master at time of report.
h2. Problem
On validation failure, the handler logs:
{{jwtToken.serialize()}}
which writes the complete bearer credential to operational logs.
{{validateToken()}} checks claims in order: expiration → signature → audience →
issuer.
A cryptographically valid, unexpired token rejected only for audience mismatch
still
hits the WARN branch and is logged in full.
h2. Impact
An actor with read access to Ranger operational logs (operators, log
aggregation,
log storage) can recover a live JWT from a WARN entry and replay it against
another
Ranger JWT consumer configured for that token's audience, authenticating as the
token subject.
This is not limited to malformed or unsigned tokens; reporter verified with a
valid
RS256-signed JWT and future expiration.
h2. Root cause
{{RangerJwtAuthHandler.authenticate()}} logs the raw serialized token when
{{validateToken()}} returns false (historically around line 128 on master).
h2. Proposed fix
Do not log the raw bearer token. On validation failure, log only non-sensitive
metadata needed for diagnosis, for example:
* subject, audience, issuer
* keyId (JWS header kid)
* jwtId
* tokenHash (SHA-256 of bearer string for log correlation only)
* optional: failure reason (expired / signature / audience / issuer)
Example log line after fix:
{{JWT validation failed (subject=..., audience=..., issuer=..., keyId=...,
jwtId=..., tokenHash=...)}}
Out of scope / already OK
Other JWT-related filters ({{{}RangerSSOAuthenticationFilter{}}},
{{{}RangerJwtAuthFilter{}}},
{{{}JwtAuthNHandler{}}}, {{{}AuditJwtAuthFilter{}}}) log failure reasons
without serializing
the full token. Primary fix is in {{{}RangerJwtAuthHandler{}}}.
h2. Test plan
* Unit test: {{safeJwtLogContext}} includes metadata and does not contain raw
token, header, payload, or signature segments
* Integration/runtime test (reporter harness): valid signed JWT with audience
{{service-a}} sent to handler configured for {{service-b}} → rejected, WARN log
does not contain full serialized JWT; same token accepted by handler for
{{service-a}} (confirms pre-fix replay scenario is closed for logs)
* {{mvn -pl ranger-authn test}}
* Checkstyle/PMD on changed files
* Backport verification on 2.8.x and 2.9.x branches
h2. Backport targets
* master / 3.0
* ranger-2.9
h2. Security / disclosure
* Treat as security issue until ASF coordinated disclosure
* CVE requested by reporter if confirmed
* Credit in advisory: *Andrew Rukin (Arenadata)*
* Do not discuss on public mailing lists until disclosure window
h2. References
* Reporter verification: Apache Ranger 2.8.0 with local JWKS + RS256 test key
* ASF Security forwarded report (Step 3); PMC Step 4 resolution pending
* Production hardening doc (does not cover log confidentiality):
[https://cwiki.apache.org/confluence/display/RANGER/Lock+down+Apache+Ranger+for+production+deployments]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
