[ 
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

Reply via email to