[
https://issues.apache.org/jira/browse/CASSANDRA-21229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cyl updated CASSANDRA-21229:
----------------------------
Description:
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.
was:
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.
> 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]
