RockteMQ-AI commented on issue #11178:
URL: https://github.com/apache/rocketmq/issues/11178#issuecomment-5741317682
**Issue Evaluation**
Category: `bug` | Status: **Confirmed** | Severity: **High**
This is a valid security vulnerability in the Remoting (TCP) authorization
path.
**Root Cause:** In `DefaultAuthorizationContextBuilder#build()`, the
authorization `Subject` is derived directly from the client-supplied
`AccessKey` in request `extFields` without any signature verification:
```java
// line ~178
Subject subject = null;
if (fields.containsKey(SessionCredentials.ACCESS_KEY)) {
subject = User.of(fields.get(SessionCredentials.ACCESS_KEY)); //
unverified
}
```
Since `authorizationEnabled` and `authenticationEnabled` are independent
switches:
- `AuthenticationPipeline.execute()` returns early when
`authenticationEnabled=false`
- `AuthorizationPipeline.execute()` proceeds when `authorizationEnabled=true`
- The unverified `AccessKey` is used as the caller identity for all
authorization decisions
**Impact:** An attacker who knows any user AccessKey can impersonate them
over the Remoting protocol without providing a SecretKey or signature.
**Affected component:** `auth` module, `DefaultAuthorizationContextBuilder`
(Remoting path only; gRPC path is not affected).
**Severity:** High — authentication bypass enabling privilege escalation in
misconfigured deployments.
The suggested fail-closed approach (refuse to start when authorization is
enabled but authentication is disabled) is a sound mitigation.
---
*Automated evaluation by github-manager-bot*
--
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]
