[
https://issues.apache.org/jira/browse/CASSANDRA-21229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18066505#comment-18066505
]
Stefan Miklosovic commented on CASSANDRA-21229:
-----------------------------------------------
Is not this resolved by CASSANDRA-21202? Closing as duplicate.
> 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]
