[
https://issues.apache.org/jira/browse/KNOX-3413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18105243#comment-18105243
]
ASF subversion and git services commented on KNOX-3413:
-------------------------------------------------------
Commit d1c9e0135412dab5e005ceb91d3d88fd0acd561d in knox's branch
refs/heads/v2.1.x from hanicz
[ https://gitbox.apache.org/repos/asf?p=knox.git;h=d1c9e0135 ]
Knox security picks into v2.1.x (#1352)
* KNOX-3188 - Token renewal and revocation should be authorized based on the
group membership of the authenticated subject. (#1083)
(cherry picked from commit 72be9fbd53a9b19483f683025155b665011d7243)
* KNOX-3410: KnoxToken enable/disable endpoints perform no caller autho… (#1343)
* KNOX-3410: KnoxToken enable/disable endpoints perform no caller authorization
* KNOX-3410: Address review comments
(cherry picked from commit f2126008ab764003e9831e48d30302886be93496)
* KNOX-3411: KnoxToken getUserTokens returns every user's token metadat… (#1344)
* KNOX-3411: KnoxToken getUserTokens returns every user's token metadata
without a caller authorization check
* KNOX-3411: Add test clean-up
(cherry picked from commit 049dc0cb894f907efa920a1a2c10fb6ed56fb109)
* KNOX-3416: KnoxSSO redirects to untrusted site (#1346)
* KNOX-3416: KnoxSSO redirects to untrusted site
* KNOX-3416: Clarify error message for userInfo
(cherry picked from commit c3dee56346cfb2670a114d478db0ba2b51aa01f7)
* KNOX-3417: KnoxLdapRealm builds the LDAP search filter from the client
username without RFC-4515 escaping (#1348)
(cherry picked from commit 3cb8ef745c44b39377d855d835198de183a4cef3)
* KNOX-3413: KnoxToken passcode verification accepts a valid passcode for a
different token (#1345)
(cherry picked from commit 5342483a2c7ff229d8819d7df479980753640fc1)
* KNOX-3413: Fix unit test
* KNOX-3418: Path traversal → arbitrary file write/overwrite in the Apache Knox
Admin API (#1349)
(cherry picked from commit de71a60cdf34c842abb8a49f770a0e33fe33c7e9)
* KNOX-3418: Fix jdk17 -> jdk11 compilation fails
---------
Co-authored-by: Sandor Molnar <[email protected]>
> KnoxToken passcode verification accepts a valid passcode for a different
> token
> -------------------------------------------------------------------------------
>
> Key: KNOX-3413
> URL: https://issues.apache.org/jira/browse/KNOX-3413
> 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
> Fix For: 3.0.0, 3.1.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Reported by n0mi1k Security
>
> When KnoxToken passcodes are in use, AbstractJWTFilter validates a presented
> (tokenId, passcode) pair, and at AbstractJWTFilter.java:504 the guard is
> `hasSignatureBeenVerified(passcode) || validatePasscode(tokenId, passcode)`;
> validatePasscode (:544-553) is the only check that binds the passcode to the
> token identifier — it compares tokenMAC.hash(tokenId, issueTime, userName,
> passcode) against the passcode stored for that specific tokenId — and on a
> successful check it records the passcode STRING in a shared cache via
> recordSignatureVerification(passcode). Because the cache is keyed on the
> passcode string alone (SignatureVerificationCache.hasSignatureBeenVerified /
> verifiedTokens.getIfPresent at :96, populated by verifiedTokens.put(passcode,
> true) at :105), a client that has once verified its own passcode can then
> present that same passcode paired with a different, victim token identifier:
> hasSignatureBeenVerified(passcode) returns true, the tokenId-binding MAC
> check is skipped entirely, and the authenticated subject is built from the
> victim tokenId via createSubjectFromTokenIdentifier (:361). Token identifiers
> are not secret — they are returned in token-generation responses, are
> enumerable via the getUserTokens endpoint, and equal the public client_id in
> the client-credentials flow — so a low-privilege KnoxToken holder can
> authenticate as any other still-valid token's principal, which is an
> identity-assertion / authentication bypass, the keystone property a perimeter
> gateway is meant to uphold. The attached PoC drives the real
> AbstractJWTFilter.validateToken + real SignatureVerificationCache + real
> TokenMAC: after seeding the cache with (tokenA, PASSCODE_A), the call
> validateToken(tokenB, PASSCODE_A) returns true and
> createSubjectFromTokenIdentifier(tokenB) yields "bob" (tokenB's owner), while
> the same call against an empty cache returns false (the real MAC check
> rejects it).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
