[
https://issues.apache.org/jira/browse/CASSANDRA-16990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17419735#comment-17419735
]
Stefan Miklosovic commented on CASSANDRA-16990:
-----------------------------------------------
Updating the version of jbcrypt library to version 0.4 has the following
consequencies. Imagine this scenario:
1) a user is on Cassandra 3.0.x (or whatever Cassandra for that matter as the
library version is same everywhere as of now).
2) she uses JVM option -Dcassandra.auth_bcrypt_gensalt_log2_rounds=31 which is
currently the current maximum per (1)
3) In version 0.3m, it is possible to go into salting with this number of
rounds, so she proceeds with a role creation
{code}
cassandra@cqlsh> CREATE ROLE alice WITH PASSWORD = 'alice';
cassandra@cqlsh> ALTER ROLE alice WITH LOGIN = true;
{code}
Alice comes along and logs just fine,
{code}
cassandra@cqlsh> select * from system_auth.roles where role = 'alice';
role | can_login | is_superuser | member_of | salted_hash
-------+-----------+--------------+-----------+--------------------------------------------------------------
alice | True | False | null |
$2a$31$PN2W5Ypx38Er/rXK8mUs..BEvG8HD2zsSAW4lZC38ZAiq0028cQwq
{code}
Notice how there is "31" in the salted hash - "$2a$31$....", 31 meaning "number
of rounds of salting".
In version 0.4, they have lowered this from 31 to 30 here: (2)
So if we updated this library to version 0.4, firstly, we would have to change
the upper limit for salting rounds as shown in (1) to reject cases when a user
supplies JVM parameter with value 31 or bigger so the direct consequence for a
user upgrading from one version to the very next with the patch, when that
system property is supplied with value of 31, is that it would not start
because it would stop on configuration exception. If a user set this to 30, it
would start.
However, what is even worse is that our Alice would not be able to login
anymore because her password was created with 31 rounds in mind which are
illegal on 0.4 so her logging in would be unsuccessful. We would basically cut
off users for which passwords were created with 31 salting rounds. I tried to
manually change number of salting rounds in salted_hash string to 30 but that
just timeouted / errored out, obviously.
The only remedy for Alice, if we upgraded this to 0.4, would be to regenerate
her password by an administrator, strangely enough, I was not able to
regenerated that either, the reg
I think the best course of action would be if we stayed on 0.3m but we would
change our limit for the number of salting rounds to 30 so that way we would
not generate the passwords for 31 salting rounds anymore if new users were
created from that point on - which (2) tries to address.
_Nevethless, what is very interesting is that if you currently set it to 31, it
will generate password upon the user creation almost instantly. That is because
there is the bug where this overflow happens. because if we fix this or if a
user tries the previous number - 30, it will not overflow, but the change from
10 to 30 causes it to time-out - because it takes so much time to salt it so
many times that the CQL command itself will time out. Same holds for whatever
higher number, like 20, for example. It still hangs on my notebook (fairly
modern one). Even it fails, that user WILL appear in the system_auth.roles
table after like ... 2 minutes. So the query fails on timeout but the user
creation succeeds eventually in the background._
I would get rid of this number-of-salting-rounds completely or I would cap it
at most to 15 or similar because it is meaningless to set it to whatever higher
due to timeouts of queries which triggered the password generation / salting.
(1)
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/auth/CassandraRoleManager.java#L105-L117
(2)
https://github.com/djmdjm/jBCrypt/commit/0c28b698e79b132391be8333107040d774c79995
> Update jbcrypt library to 0.4 from 0.3m to resolve CVE-2015-0886
> ----------------------------------------------------------------
>
> Key: CASSANDRA-16990
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16990
> Project: Cassandra
> Issue Type: Task
> Components: Dependencies
> Reporter: Stefan Miklosovic
> Assignee: Stefan Miklosovic
> Priority: Normal
> Fix For: 3.0.26, 3.11.12, 4.0.2, 4.1
>
>
> We are using jbcrypto of version 0.3m across all versions, this version of
> the library was never changed since 1.1.2.
> In 0.3m they found out this (1) and (2, 3 for better explanation / reference)
> I think we are affected by this, it is possible to set 31 rounds here (4)
> which would hit the same same logic afteward these tickets are talking about.
> 1) [https://nvd.nist.gov/vuln/detail/CVE-2015-0886]
> 2) [http://www.mindrot.org/projects/jBCrypt/news/rel04.html]
> 3) [https://bugzilla.mindrot.org/show_bug.cgi?id=2097]
> 4)
> [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/auth/CassandraRoleManager.java#L105-L117]
> I hence propose to update the library to 0.4 where this is fixed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
