You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Aleksey Yeschenko (JIRA)" <ji...@apache.org> on 2013/01/11 03:05:11 UTC

[jira] [Created] (CASSANDRA-5145) CQL3 BATCH authorization caching bug

Aleksey Yeschenko created CASSANDRA-5145:
--------------------------------------------

             Summary: 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.2.0, 1.1.8
            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