Stamatis Zampetakis created HIVE-29794:
------------------------------------------
Summary: HiveServer2 auth cookie lets one user impersonate another
Key: HIVE-29794
URL: https://issues.apache.org/jira/browse/HIVE-29794
Project: Hive
Issue Type: Bug
Components: HiveServer2
Affects Versions: 4.2.0
Reporter: Stamatis Zampetakis
After authentication succeeds, HiveServer2 writes the accepted username into a
token that uses delimiters and signs the result. If the username contains those
delimiters, the signed token can contain a second username field. When the
client sends the cookie back, HiveServer2 accepts the second username and opens
the session as that user without asking the authentication provider to verify
it.
This requires HTTP transport with cookie authentication and an identity source
that accepts usernames containing the cookie delimiters. I reproduced it with
HiveServer2's supported CUSTOM authentication mode.
h4. Impact
The client starts with valid credentials for only the first user. After
returning its own cookie, it gets a Hive session as the second user and
inherits that user's Hive permissions.
This is an authorization change, not just an incorrect username in a log. Hive
uses the session user for SQLStd object permissions and roles, query ownership,
audit records, hooks, Web UI ownership, and accounting by user. If the second
user has the SQLStd ADMIN role, the client gets that authority. The maximum
impact is the Hive authority assigned to the second user.
HTTP is not HiveServer2's default transport, and not every identity source
accepts usernames containing these delimiters. Deployments are affected when
both conditions hold.
h4. What I verified
I tested the official Apache Hive 4.2.0 image with HTTP transport, cookie
authentication, CUSTOM authentication, and SQLStd authorization.
The CUSTOM provider accepted credentials for the first user and rejected direct
authentication as the second user. The first session opened as the first user,
and HiveServer2 returned its signed cookie to the client. A new session using
that cookie opened as the second user. The client did not have the second
user's credentials or any value taken from server logs or debugging.
With SQLStd object authorization enabled, Hive denied the first user access to
a protected table. The session opened from the cookie read that table with the
second user's permission.
I also tested the SQLStd ADMIN role. The first user could not activate ADMIN
and could not create a role. The session opened from the cookie activated ADMIN
as the second user, created a role, and dropped it.
h4. Why this happens
HttpAuthUtils builds the cookie token by inserting the username directly
between delimiters. It does not encode the username or record its length:
https://github.com/apache/hive/blob/rel/release-4.2.0/service/src/java/org/apache/hive/service/auth/HttpAuthUtils.java#L84-L90
When the cookie returns, HttpAuthService verifies the signature and then sends
the extracted text to the username parser:
https://github.com/apache/hive/blob/rel/release-4.2.0/service/src/java/org/apache/hive/service/auth/HttpAuthService.java#L120-L150
The parser splits the text into fields and stores them in a map. It does not
reject duplicate fields, so a later username replaces the one that HiveServer2
originally authenticated:
https://github.com/apache/hive/blob/rel/release-4.2.0/service/src/java/org/apache/hive/service/auth/HttpAuthUtils.java#L114-L129
ThriftHttpServlet calls the configured authentication provider only when cookie
validation did not return a username. If the cookie parser returns one, the
servlet stores it as the HiveServer2 session user and continues:
https://github.com/apache/hive/blob/rel/release-4.2.0/service/src/java/org/apache/hive/service/cli/thrift/ThriftHttpServlet.java#L185-L249
h4. Versions
- I reproduced the issue on Apache Hive 4.2.0.
- I found the same token construction and parser in release refs 1.2.2, 2.3.10,
3.1.3, 4.0.1, 4.1.0, and 4.2.0.
- The same code remains in branch-4.2 and master as checked on 2026-07-16.
- HiveServer2 HTTP cookie authentication was introduced with HIVE-9710 in Hive
1.2.0.
- I found no public Apache fix, CVE, or duplicate report for this bug.
h4. Classification
- CWE-287: Improper Authentication
- CWE-20: Improper Input Validation
h4. Suggested fix
* Stop signing a token that can be parsed in two different ways. Encode each
value or record its length before building and signing the token.
* When reading a cookie, reject duplicate fields and malformed tokens. The
signed representation must have one canonical meaning, and parsing it must
recover exactly the username that HiveServer2 authenticated. Existing ambiguous
cookies should be rejected.
If the issue is accepted, I would appreciate attribution as "Andrew Rukin
(Arenadata)" in any public advisory, CVE entry, or release notes related to it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
