[ 
https://issues.apache.org/jira/browse/KNOX-3417?focusedWorklogId=1035518&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1035518
 ]

ASF GitHub Bot logged work on KNOX-3417:
----------------------------------------

                Author: ASF GitHub Bot
            Created on: 13/Aug/26 08:28
            Start Date: 13/Aug/26 08:28
    Worklog Time Spent: 10m 
      Work Description: hanicz opened a new pull request, #1348:
URL: https://github.com/apache/knox/pull/1348

   …t username without RFC-4515 escaping
   
   [KNOX-3417](https://issues.apache.org/jira/browse/KNOX-3417) - A short 
description of the change
   
   ## What changes were proposed in this pull request?
   
   In search-then-bind LDAP mode, Knox dropped the login username straight into 
an LDAP search filter with no escaping. Typing username `*)(uid=admin` turned 
the intended filter `(&(objectclass=person)(uid=<user>))` into 
`(&(objectclass=person)(uid=*)(uid=admin))`.
   
   The fix (`KnoxLdapRealm.java`):
   - New `escapeLdapSearchFilterValue()` — RFC 4515 escaping (* ( ) \ NUL → \2a 
\28 \29 \5c \00).
   - New `expandTemplate(..., escapeForLdapFilter)` overload (escapes the value 
+ Matcher.quoteReplacement), switched on at the two filter sites.
   - Now `*)(uid=admin` becomes inert literal `uid=\2a\29\28uid=admin `— no 
longer alters the query.
   
   New unit tests
   
   ## How was this patch tested?
   
   Unit tests, manually tested
   
   Log level to `DEBUG`
   New topology:
   ```
   <param>
      <name>main.ldapRealm.userSearchBase</name>
      <value>ou=people,dc=hadoop,dc=apache,dc=org</value>
   </param>
   <param>
       <name>main.ldapRealm.userSearchAttributeName</name>
       <value>uid</value>
   </param>
   <param>
       <name>main.ldapRealm.userObjectClass</name>
       <value>person</value>
   </param>
   ```
   **Before**:
   ```
   curl -sivk -u '*)(uid=admin:admin-password' 
'https://localhost:8443/gateway/injtest/v1/gateway-status'
   
   HTTP/1.1 200 OK
   
   DEBUG knox.gateway (KnoxLdapRealm.java:getUserDn(715)) - Searching from 
ou=people,dc=hadoop,dc=apache,dc=org where (&(objectclass=person)(uid=admin)) 
scope subtree
   ```
   
   **After**:
   ```
   curl -sivk -u '*)(uid=admin:admin-password' 
'https://localhost:8443/gateway/injtest/v1/gateway-status'
   
   HTTP/1.1 401 Unauthorized
   
   DEBUG knox.gateway (KnoxLdapRealm.java:getUserDn(715)) - Searching from 
ou=people,dc=hadoop,dc=apache,dc=org where 
(&(objectclass=person)(uid=\2a\29\28uid=admin)) scope subtree
   ```
   
   
   ## Integration Tests
   N/A
   
   ## UI changes
   N/A
   




Issue Time Tracking
-------------------

            Worklog Id:     (was: 1035518)
    Remaining Estimate: 0h
            Time Spent: 10m

> KnoxLdapRealm builds the LDAP search filter from the client username without 
> RFC-4515 escaping
> ----------------------------------------------------------------------------------------------
>
>                 Key: KNOX-3417
>                 URL: https://issues.apache.org/jira/browse/KNOX-3417
>             Project: Apache Knox
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 2.1.0, 3.0.0
>            Reporter: Tamás Hanicz
>            Assignee: Tamás Hanicz
>            Priority: Blocker
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> Reported by n0mi1k Security
>  KnoxLdapRealm.java:699-703 formats (&(objectclass=%s)(%s=%s)) with 
> expandTemplate(getUserSearchAttributeTemplate(), matchedPrincipal), and :706 
> expands the operator's userSearchFilter the same way; expandTemplate 
> (:752-760) is a plain \{0} substitution with no encoding, principalRegex 
> defaults to (.*) (:138) so matchPrincipal filters nothing, and the value 
> reaches systemLdapCtx.search(searchBase, searchFilter, searchControls) at 
> :716. No filter-escaping helper exists anywhere in the realm. The username 
> arrives pre-authentication, via doGetAuthenticationInfo to getUserDn at :263. 
> It's a filter-injection primitive rather than a demonstrated credential-less 
> bypass.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to