You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Ariel Weisberg (JIRA)" <ji...@apache.org> on 2018/05/03 16:44:00 UTC

[jira] [Commented] (CASSANDRA-14433) DoS attack through PagingState

    [ https://issues.apache.org/jira/browse/CASSANDRA-14433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16462755#comment-16462755 ] 

Ariel Weisberg commented on CASSANDRA-14433:
--------------------------------------------

I'm not sure this is a bug. Any length prefixed field can be used to cause an OOM. Even if we clamp the size of fields a client can send multiple requests concurrently on multiple connections to cause OOM.

By the time you have completed authentication and authorization you know the client you are talking to is trusted. If it isn't then the important thing isn't to avoid DoS it's to avoid remote execution vulnerabilities and leaking information.

If you really want multi-tenancy with clients you don't trust I think you have to build isolation across tenants to allow for that. And then you still have to deal with the tenants ability to do things like create large expensive to read partitions and then spamming the database with read requests.

In real world terms I think that means using virtualization or process isolation. 



> DoS attack through PagingState
> ------------------------------
>
>                 Key: CASSANDRA-14433
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-14433
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: Yang Yu
>            Priority: Major
>
> According to [this manual page|https://docs.datastax.com/en/developer/java-driver/3.5/manual/paging/], the paging state can be returned to and received from end users. This means end users can inject malicious content into the paging state in order to attack the server.
> One way is to forge a paging state with a very large partition key size. The forged paging state will be passed through the driver and consumed by the server and cause OutOfMemoryError:
> {noformat}
> java.lang.OutOfMemoryError: Java heap space
> at org.apache.cassandra.utils.ByteBufferUtil.read(ByteBufferUtil.java:401) ~[apache-cassandra-3.11.2.jar:3.11.2]
> at org.apache.cassandra.utils.ByteBufferUtil.readWithVIntLength(ByteBufferUtil.java:340) ~[apache-cassandra-3.11.2.jar:3.11.2]
> at org.apache.cassandra.service.pager.PagingState.deserialize(PagingState.java:78) ~[apache-cassandra-3.11.2.jar:3.11.2]
> at org.apache.cassandra.cql3.QueryOptions$Codec.decode(QueryOptions.java:432) ~[apache-cassandra-3.11.2.jar:3.11.2]
> at org.apache.cassandra.cql3.QueryOptions$Codec.decode(QueryOptions.java:366) ~[apache-cassandra-3.11.2.jar:3.11.2]
> at org.apache.cassandra.transport.messages.ExecuteMessage$1.decode(ExecuteMessage.java:46) ~[apache-cassandra-3.11.2.jar:3.11.2]
> at org.apache.cassandra.transport.messages.ExecuteMessage$1.decode(ExecuteMessage.java:42) ~[apache-cassandra-3.11.2.jar:3.11.2]
> at org.apache.cassandra.transport.Message$ProtocolDecoder.decode(Message.java:281) ~[apache-cassandra-3.11.2.jar:3.11.2]
> at org.apache.cassandra.transport.Message$ProtocolDecoder.decode(Message.java:262) ~[apache-cassandra-3.11.2.jar:3.11.2]
> at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:88) [netty-all-4.0.44.Final.jar:4.0.44.Final]
>  {noformat}
> The paging state used to cause the above exception is shown below. The encoded partition key size is 2G.
> {noformat}
> 00180010f077359400736f6d654b65790900026331040000002a0a006a66e551aa30a3ac47e693ab43bd29a90004
> {noformat}
> Essentially, this issue is very similar to the "DoS User Specified Object Allocation" example in [this OWASP page|https://www.owasp.org/index.php/Denial_of_Service]. It is especially serious in a multi-tenant environment, as one malicious tenant can affect all other tenants.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org