RockteMQ-AI commented on issue #11182:
URL: https://github.com/apache/rocketmq/issues/11182#issuecomment-5749672585

   Thank you @R0CKing666 for the detailed report. I verified this against the 
current `develop` branch code.
   
   ## Verification
   
   **`StatefulAuthorizationStrategy.buildKey()`** (line ~62) constructs the 
cache key as:
   ```
   channelId + POUND + subjectKey + POUND + resourceKey + POUND + actions + 
POUND + sourceIp
   ```
   **`rpcCode` is not part of the key.**
   
   **`AbstractAuthorizationStrategy.doEvaluate()`** (line ~59) short-circuits 
on:
   ```java
   if (this.authorizationWhiteSet.contains(context.getRpcCode())) {
       return;  // ALLOW, no ACL check
   }
   ```
   
   The `evaluate()` method wraps `doEvaluate()` inside `authCache.get(key, 
mappingFunction)`. On a cache miss for a whitelisted rpcCode, `doEvaluate()` 
returns ALLOW → cache stores `Pair.of(true, null)`. A subsequent request with 
the **same** `(channelId, subject, resource, actions, sourceIp)` but a 
**different** (non-whitelisted) rpcCode hits the cached ALLOW and never reaches 
the ACL provider — confirming the privilege escalation.
   
   ## Classification
   
   | Field | Value |
   |-------|-------|
   | **Type** | Bug — Security / Privilege Escalation |
   | **Severity** | **HIGH** |
   | **Component** | `auth` module — `StatefulAuthorizationStrategy` |
   | **Impact** | Any deployment using 
`authorizationStrategy=StatefulAuthorizationStrategy` with a non-empty 
`authorizationWhitelist` is vulnerable. A non-whitelisted RPC can bypass ACL 
checks entirely by reusing the cached ALLOW from a whitelisted RPC on the same 
channel/subject/resource/actions/sourceIp tuple. |
   
   ## Suggested Fix
   
   Both approaches mentioned in the issue are valid; applying both provides 
defense-in-depth:
   1. **Short-circuit whitelist before cache lookup** — whitelisted requests 
should neither read nor write the cache.
   2. **Include `rpcCode` in the cache key** — ensures cache dimension covers 
every input that affects the authorization decision.
   
   A regression test covering the cross-rpcCode cache collision scenario would 
be essential.
   
   Flagging for maintainer attention: @rocketmq/committers


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to