[
https://issues.apache.org/jira/browse/CASSANDRA-5145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13551166#comment-13551166
]
Aleksey Yeschenko commented on CASSANDRA-5145:
----------------------------------------------
Thought about that, but if we later allow ':' in ks/cf names, for example, this
would bite us again, since there would be now way to distinguish between (ks:
"ks:1", cf: "demo") and (ks: "ks", cf: "1:demo") and a similar attack would
happen.
Now, this may not be a valid concern, but I'd rather not risk by depending on
cql grammar here.
> CQL3 BATCH authorization caching bug
> ------------------------------------
>
> Key: CASSANDRA-5145
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5145
> Project: Cassandra
> Issue Type: Bug
> Affects Versions: 1.1.8, 1.2.0
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Fix For: 1.1.9, 1.2.1
>
>
> cql3.BatchStatement:
> {noformat}
> public void checkAccess(ClientState state) throws InvalidRequestException
> {
> Set<String> cfamsSeen = new HashSet<String>();
> for (ModificationStatement statement : statements)
> {
> // Avoid unnecessary authorizations.
> if (!(cfamsSeen.contains(statement.columnFamily())))
> {
> state.hasColumnFamilyAccess(statement.keyspace(),
> statement.columnFamily(), Permission.MODIFY);
> cfamsSeen.add(statement.columnFamily());
> }
> }
> }
> {noformat}
> In CQL3 we can use fully-qualified name of the cf and so a batch can contain
> mutations for different keyspaces. And when caching cfamsSeen, we ignore the
> keyspace. This can be exploited to modify any CF in any keyspace so long as
> the malicious user has CREATE+MODIFY permissions on some keyspace (any
> keyspace). All you need is to create a table in your ks with the same name as
> the table you want to modify and perform a batch update.
> Example: an attacker doesn't have permissions, but wants to modify k1.demo
> table. The attacker controls k2 keyspace. The attacker creates k2.demo table
> and then does the following request:
> {noformat}
> cqlsh:k2> begin batch
> ... insert into k2.demo ..
> ... insert into k1.demo ..
> ... apply batch;
> cqlsh:k2>
> {noformat}
> .. and successfully modifies k1.demo table since 'demo' cfname will be cached.
> Thrift's batch_mutate and atomic_batch_mutate are not affected since the only
> allow mutations to a single ks. CQL2 batches are not affected since they
> don't do any caching.
> We should either get rid of caching here or switch cfamsSeen to a Map<String,
> Set<String>>.
> Personally, I'd rather do the latter now, and get rid of caching here
> completely once CASSANDRA-4295 is resolved.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
