cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-5145) CQL3 BATCH authorization caching bug
Date Fri, 11 Jan 2013 15:04:12 GMT


Sylvain Lebresne commented on CASSANDRA-5145:

bq. I'd rather do the latter now

I'm good with that, though I would not even bother with a map of sets, but just add {{statement.keyspace()
+ ":" + statement.columnFamily()}} to cfamsSeen.
> CQL3 BATCH authorization caching bug
> ------------------------------------
>                 Key: CASSANDRA-5145
>                 URL:
>             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(),
>                 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
> {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:

View raw message