Hemanth Umashankar created HIVE-30233:
-----------------------------------------
Summary: Remove spring-ldap-core dependency and use an internal
LDAP filter-escaping helper
Key: HIVE-30233
URL: https://issues.apache.org/jira/browse/HIVE-30233
Project: Hive
Issue Type: Improvement
Reporter: Hemanth Umashankar
h3. Background: how Hive uses LDAP
Many companies keep employee accounts in a central directory such as Active
Directory. When a user logs in to HiveServer2 or the Hive Metastore with LDAP
authentication, Hive asks that directory two things:
# Is this password correct?
# (Optionally) Does this user belong to an allowed group?
Hive does the login check itself, using Java's built-in LDAP support (JNDI). It
does not use Spring LDAP for this:
* HiveServer2:
[LdapSearchFactory.java#L63|https://github.com/apache/hive/blob/81448508cc0e6c13b8efdaf34eeb02a04a43b965/service/src/java/org/apache/hive/service/auth/ldap/LdapSearchFactory.java#L63]
* Metastore:
[LdapSearchFactory.java#L65|https://github.com/apache/hive/blob/81448508cc0e6c13b8efdaf34eeb02a04a43b965/standalone-metastore/metastore-common/src/main/java/org/apache/hadoop/hive/metastore/ldap/LdapSearchFactory.java#L65]
h3. Where spring-ldap-core comes in
For the group check, Hive builds an LDAP search that contains the user's name,
for example {{{}(member=CN=John Smith,OU=Sales,DC=corp,DC=com){}}}.
Some characters have a special meaning inside an LDAP search: {{*}}, {{{}({}}},
{{{}){}}}, {{}} and the NUL character. If a user's name contains one of them,
the search can break or match the wrong entries. It is the same kind of problem
as an apostrophe in a name breaking a database query. So before inserting the
name, Hive "escapes" those characters by replacing each one with a safe code
(for example {}}{*}{{{}} becomes {{\2a{}}}).
HIVE-28540 added spring-ldap-core only to do that escaping, via one function:
{{{}LdapEncoder.filterEncode(){}}}. *That single call is the only use of Spring
LDAP in the whole Hive codebase.* It appears in two copies of the same class:
* HiveServer2:
[service/.../auth/ldap/LdapSearch.java#L186|https://github.com/apache/hive/blob/81448508cc0e6c13b8efdaf34eeb02a04a43b965/service/src/java/org/apache/hive/service/auth/ldap/LdapSearch.java#L186]
* Metastore:
[metastore-common/.../metastore/ldap/LdapSearch.java#L187|https://github.com/apache/hive/blob/81448508cc0e6c13b8efdaf34eeb02a04a43b965/standalone-metastore/metastore-common/src/main/java/org/apache/hadoop/hive/metastore/ldap/LdapSearch.java#L187]
The dependency is declared in:
*
[pom.xml#L250|https://github.com/apache/hive/blob/81448508cc0e6c13b8efdaf34eeb02a04a43b965/pom.xml#L250]
({{{}spring.ldap.version{}}} = 2.4.4)
*
[standalone-metastore/pom.xml#L138|https://github.com/apache/hive/blob/81448508cc0e6c13b8efdaf34eeb02a04a43b965/standalone-metastore/pom.xml#L138]
({{{}spring.ldap.version{}}} = 2.4.4)
*
[service/pom.xml#L242-L244|https://github.com/apache/hive/blob/81448508cc0e6c13b8efdaf34eeb02a04a43b965/service/pom.xml#L242-L244]
*
[standalone-metastore/metastore-common/pom.xml#L321-L323|https://github.com/apache/hive/blob/81448508cc0e6c13b8efdaf34eeb02a04a43b965/standalone-metastore/metastore-common/pom.xml#L321-L323]
h3. The CVE (CVE-2026-41720), in plain terms
The CVE is in a different part of Spring LDAP: the part that {*}logs users
in{*}.
LDAP has an odd rule. If a client connects with a username and an *empty*
password, many directory servers do not reply "wrong password". They treat it
as an anonymous connection and report success. Software that checks logins
therefore has to reject empty passwords itself before asking the directory.
Spring LDAP 2.4.0–2.4.4 did not always do this (in
{{{}DirContextAuthenticationStrategy{}}}). An application that uses Spring LDAP
to log users in could let someone in with a valid username and a blank password.
h3. Is Hive affected?
No, the vulnerable code is not reachable from Hive:
* Hive never uses Spring LDAP to log anyone in. It only uses the text-escaping
function, which has nothing to do with the bug.
* Hive's own login code already rejects blank passwords before contacting the
directory:
** HiveServer2:
[LdapAuthenticationProviderImpl.java#L115-L118|https://github.com/apache/hive/blob/81448508cc0e6c13b8efdaf34eeb02a04a43b965/service/src/java/org/apache/hive/service/auth/LdapAuthenticationProviderImpl.java#L115-L118]
** Metastore:
[MetaStoreLdapAuthenticationProviderImpl.java#L125-L128|https://github.com/apache/hive/blob/81448508cc0e6c13b8efdaf34eeb02a04a43b965/standalone-metastore/metastore-common/src/main/java/org/apache/hadoop/hive/metastore/MetaStoreLdapAuthenticationProviderImpl.java#L125-L128]
h3. Why change anything, then?
Security scanners only see that {{spring-ldap-core-2.4.4.jar}} ships in
{{hive/lib}} and flag it, because they cannot tell which parts are used. Every
product that bundles Hive's libraries inherits the warning.
Upgrading is not practical. 2.4.4 is the last open-source 2.x release, and the
fixed versions (3.3.8+, 4.0.4+) require Spring Framework 6, which means the
javax -> jakarta migration. That is why the version-bump approach in HIVE-29299
/ [apache/hive#6401|https://github.com/apache/hive/pull/6401] did not go ahead.
h3. Proposed fix
Replace that one function with about ten lines of Hive's own code that do
exactly the same escaping, and remove the library:
* Add {{LdapUtils.escapeFilterValue(String)}} to both
{{org.apache.hive.service.auth.ldap.LdapUtils}} and
{{{}org.apache.hadoop.hive.metastore.ldap.LdapUtils{}}}. It replaces {{\ * (
)}} and NUL with {{\5c \2a \28 \29 \00}} (RFC 4515) and returns null for null,
the same as {{{}LdapEncoder.filterEncode(){}}}.
* Call it from both {{LdapSearch}} classes instead of
{{{}LdapEncoder.filterEncode(){}}}.
* Remove {{spring-ldap-core}} and the {{spring.ldap.version}} property from
the four POM files listed above.
There is no behaviour change and no Spring or jakarta impact. Scanners stop
flagging Hive, and Hive has one fewer dependency to maintain.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
