[
https://issues.apache.org/jira/browse/CASSANDRA-21229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18066589#comment-18066589
]
C. Scott Andreas commented on CASSANDRA-21229:
----------------------------------------------
[~chenyl2024] Please report security issues privately in accordance with the
Apache management process. This is indicated in the header of this Jira
instance ("Report potential security issues privately").
Details on this process are here:
[https://apache.org/security/#reporting-a-vulnerability]
> Authenticated DoS via ALTER ROLE (Password Modification)
> --------------------------------------------------------
>
> Key: CASSANDRA-21229
> URL: https://issues.apache.org/jira/browse/CASSANDRA-21229
> Project: Apache Cassandra
> Issue Type: Bug
> Components: Feature/Authorization, Feature/Rate Limiting
> Reporter: Cyl
> Priority: Normal
> Labels: dos, performance, security
>
> h2. Vulnerability Description
> After auditing the system, I found a vulnerability very similar to the one
> fixed in CASSANDRA-17812.
> h3. Vulnerability Details: Authenticated DoS via `ALTER ROLE`
> *Location:* {{CassandraRoleManager.java}} and {{AlterRoleStatement.java}}
> *Description:*
> Although the patch fixed the CPU exhaustion caused by bcrypt computation
> during new connection authentication ({{AUTH_RESPONSE}}), the exact same
> bcrypt hashing operation still exists in the logic for modifying user
> passwords.
> When a user executes the {{ALTER ROLE}} statement to modify a password, the
> system calls {{CassandraRoleManager.alterRole}}, which in turn calls
> {{optionsToAssignments}}, and ultimately calls {{BCrypt.hashpw}} to hash the
> new password.
> {code:java}
> // src/java/org/apache/cassandra/auth/CassandraRoleManager.java
> private String optionsToAssignments(Map<Option, Object> options)
> {
> return options.entrySet()
> .stream()
> .map(entry ->
> {
> switch (entry.getKey())
> {
> // ...
> case PASSWORD:
> // The expensive hashpw operation is
> called here
> return String.format("salted_hash =
> '%s'", escape(hashpw((String) entry.getValue())));
> // ...
> }
> })
> // ...
> }
> private static String hashpw(String password)
> {
> return BCrypt.hashpw(password, PasswordSaltSupplier.get());
> }
> {code}
> *Problem Analysis:*
> # *Execution Thread Pool:* {{ALTER ROLE}} is a CQL query and is handled via
> {{QueryMessage}}. According to the logic in {{Dispatcher.java}},
> {{QueryMessage}} is executed by default in the {{requestExecutor}} (the
> standard request thread pool) instead of the dedicated {{authExecutor}}
> introduced in the patch.
> # *Permissions:* When using {{PasswordAuthenticator}}, regular users have the
> permission to modify their own passwords by default ({{alterableOptions}}
> contains {{Option.PASSWORD}}).
> # *Attack Vector:* An authenticated malicious user (or a compromised
> low-privileged account) can send a large number of {{ALTER ROLE my_user WITH
> PASSWORD '...'}} requests concurrently.
> # *Consequences:* Each request will trigger the expensive {{BCrypt.hashpw}}
> operation on the shared {{requestExecutor}} thread pool. This will rapidly
> exhaust CPU resources and cause head-of-line blocking in the thread pool,
> making normal client requests (reads/writes) timeout or fail because they
> cannot get processing resources.
> *Comparison:*
> * *Original Vulnerability (CASSANDRA-17812):* Unauthenticated/authenticating
> connections trigger {{BCrypt.checkpw}} via {{AUTH_RESPONSE}}, blocking the
> {{requestExecutor}}.
> * *Newly Discovered Vulnerability:* Authenticated users trigger
> {{BCrypt.hashpw}} via {{ALTER ROLE}}, which similarly blocks the
> {{requestExecutor}}.
> h3. Recommended Fixes
> I suggest applying similar isolation or rate-limiting measures to the {{ALTER
> ROLE}} (and {{CREATE ROLE}}) operations that involve password hashing:
> # *Isolated Execution:* Offload the execution of {{AlterRoleStatement}} (or
> at least the password hashing part) to the {{authExecutor}} or another
> independent thread pool to prevent blocking the main request processing
> thread pool.
> # *Rate Limiting:* Implement strict rate limiting for the {{ALTER ROLE}}
> statement, especially for operations involving password modifications.
> h3. Audit Summary
> While the system has patched the bcrypt DoS risk during the login phase, the
> same risk during the password modification phase remains unpatched. Since
> {{ALTER ROLE}} runs on the core request path and involves the same expensive
> computation, it constitutes a valid denial-of-service attack surface.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
