[jira] [Resolved] (CASSANDRA-6533) Denial of Service with get_slice operations

["Aleksey Yeschenko (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CASSANDRA-6533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aleksey Yeschenko resolved CASSANDRA-6533.
------------------------------------------

    Resolution: Duplicate

> Denial of Service with get_slice operations
> -------------------------------------------
>
>                 Key: CASSANDRA-6533
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6533
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Laura Adney
>         Attachments: predAssertError (1).py, predicate_patch.txt, stacktraces.txt
>
>
> We’ve come across a bug impacting Cassandra 1.2 and 2.0 with the potential to cause a denial of service condition in nodes handling get_slice requests.
> It appears that Cassandra does not check the length of a column name that is part of a range predicate for a *_slice query before it serialises the slice query to pass to the replicas. Names with a length greater than 0xFFFF cause an assertion error to occur in ByteBufferUtil.writeWithShortLength and a write a weird hint to the hinted handoff store. 
> This further causes subsequent reads on the node to fail until Cassandra is restarted.
> 2.0.x does not appear to be affected by the Denial of Service condition, though probably warrants further investigation.
> The column name could be user controllable in certain applications and schemas, allowing a malicious user to stop all reads until the impacted nodes are restarted.  Attached is a small python script (using pycassa) that will reproduce the issue on a fresh Cassandra cluster with more than one node with the following schema:
> CREATE KEYSPACE bar with placement_strategy = 'org.apache.cassandra.locator.SimpleStrategy' and strategy_options = {replication_factor:2};
> use bar;
> CREATE COLUMN FAMILY Test1;
> It was tested against Cassandra 1.2.10, 1.2.12 and 2.0.3 on both OS X and Ubuntu (hasn't been tested against DSE). Included a rough patch that includes additional check in validatePredicate, however it hasn’t been formally tested other than a recompile and check to see if it prevents the assert error.
> predAssertError.py -> reproduce the bug on a fresh cluster (more than one node)
> stacktraces.txt (1.2.10 and 2.0.3 stack traces)
> predicate_patch.txt (diff of patch to fix issue)
> zd8209



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)