Re: CVE-2020-13946 Apache Cassandra RMI Rebind Vulnerability

2020-09-01 Thread manish khandelwal
Hi Sam Is there any alternative to avoid this vulnerability? Like upgrade to specific JVM version. Regards Manish On Tue, Sep 1, 2020 at 8:03 PM Sam Tunnicliffe wrote: > CVE-2020-13946 Apache Cassandra RMI Rebind Vulnerability > > Versions Affected: > All versions prior to: 2.1.22, 2.2.18,

Re: Could a READ REPAIR really be triggered even if there avg 80 ms between calls

2020-09-01 Thread Jeff Jirsa
Yes, it's possible. A typical JVM GC pause for most configs is on the order of 50-200ms. If you have a host do a small collection/pause, then the read at #4 is basically racing the write at #1 (or, if you have an unhealthy cluster that's regularly dropping writes due to much larger problems, then

CVE-2020-13946 Apache Cassandra RMI Rebind Vulnerability

2020-09-01 Thread Sam Tunnicliffe
CVE-2020-13946 Apache Cassandra RMI Rebind Vulnerability Versions Affected: All versions prior to: 2.1.22, 2.2.18, 3.0.22, 3.11.8 and 4.0-beta2 Description: It is possible for a local attacker without access to the Apache Cassandra process or configuration files to manipulate the RMI registry

Re: Could a READ REPAIR really be triggered even if there avg 80 ms between calls

2020-09-01 Thread Erick Ramirez
Did you mean LOCAL_QUORUM? Because QUORUM will require 4 out of 6 replicas, not 2 out of 3. :) But it sounds like you are using QUORUM because you said it syncs to all nodes in DC2. To answer your question, RR *can* be triggered if you're reading before the replicas are *eventually* consistent.

Could a READ REPAIR really be triggered even if there avg 80 ms between calls

2020-09-01 Thread Tobias Eriksson
Hi We are seeing READ REPAIRs happening, and my understanding is this Setup 2 DCs with lots of Nodes, Replication Factor = 3 1. Data written (on INSERT/UPDATE) 2. Data replicated by Cassandra, but will not finish before (4) below 3. Wait 80 ms on average 4. Data read again with