Re: [jgroups-users] Impact of Security Alert JGRP-2021 on Symmetric Encryption

Can Bela or someone else from the community help me here ?
ThanksAnuj

Sent from Yahoo Mail on Android 
 
  On Mon, Mar 13, 2017 at 3:32 PM, Questions/problems related to using JGroups<[email protected]> wrote:   



 Thanks Bela Ban. 

1. There is some confusion in the way I am interpreting JGRP-2021. JGRP-2021 says: 

"if a rogue node creates a minimal stack without encryption or authentication, then it is possible for that member to   
   - Send messages to the cluster
   - Install a new view including itself"

But as per your reply, "the message would be dropped". Both things seem to be contradicting. I need to understand "How security would be breached because of JGRP-2021 in a system where symmetric encryption+encrypt_entire_message=true is being used?". Please elaborate.
Is rogue node required to install ENCRYPT, set encrypt_entire_message=false in EncryptHeader and skip AUTH to be able to send messages to the cluster and install a new view including itself ?

2. https://issues.jboss.org/projects/JGRP/issues/JGRP-2157 link is not working. So, you mean that MitM is a possibility in Asymmetric encryption? you say this because someone in the middle could just see the AUTH token and use it to authenticate itself? All in all what would be your recommendation for production systems with respect to AUTH tokens and Encryption?
3. "but there's a reproducer in the CVE which 
you can run against your system to see if you have this issue."
I am new to CVE portal. I am not able to find the reproducer at https://www.cvedetails.com/cve/CVE-2016-2141/. 
Could you help me with the link?

ThanksAnuj



As per your reply,  "If a message (or mesage batch) arrives at ENCRYPT, and doesn't have 
an EncryptHeader, it will be dropped (or removed from the batch). 
ENCRYPT.handleUpMessage() [632]." but JGRP-2021 says:

 

    On Monday, 13 March 2017 2:04 PM, Questions/problems related to using JGroups <[email protected]> wrote:
 

 

On 12/03/17 20:30, Questions/problems related to using JGroups wrote:
> Hi,
>
> We use Jgroups 3.4.3. We are planning to use symmetric encryption with
> encrypt_entire_message=true. Recently, I came across JGRP-2021 security
> vulnerability. I would appreciate if some Jgroup user could confirm
> following impact analysis so as to confirm my correct interpretation of
> the security vulnerability.
>
>    Security Impact of JGRP-2021 on a System with Symmetric Encryption
> and encrypt_entire_message=true
>
> -----------------------------------------------------------------------------------------------------------------
>    A. Even if I use symmetric encryption with
> encrypt_entire_message=true, A non-member could still send messages to
> existing nodes by not using ENCRYPT and AUTH.

No. If a message (or mesage batch) arrives at ENCRYPT, and doesn't have 
an EncryptHeader, it will be dropped (or removed from the batch). 
ENCRYPT.handleUpMessage() [632].


>    B. Replay attack is NOT possible because entire message is encrypted
> and a hacker cant get the seq no. (duplicates shall automatically be
> discarded)

Correct.


>    C. Because a non-member is able to send message to existing nodes, a
> new view (including non-member) could be installed on existing nodes.
> Thus, a non-member  would start receiving encrypted messages from nodes
> but completed encrypted messages wont be of any use, unless the new node
> possesses the secret key. So, no issues.

The non-member would have to have ENCRYPT installed, or else its message 
without an EncryptHeader would be dropped (see A above). Unless the 
non-member has the secret key, decryption will fail and the message will 
be discarded.

So a non-member would *not* be able to send a VIEW message to individual 
members, therefore it would not be able to join the group.

>    D. As per https://access.redhat.com/articles/2360521, a remote
> attacker could execute arbitrary code on a Java Virtual Machine running
> JGroups. This is possible because security is bypassed.

Java serialization is still used internally in some places in 3.4.3; 
this was changed by JGRP-2021 and the backport to the 3.6 branch. I 
think the quickfix was to remove vulnerable libs such as 
commons-collections from the classpath unless they're absolutely required.

I'm not sure about your env, but there's a reproducer in the CVE which 
you can run against your system to see if you have this issue.

> Also, I think Asymmetric encryption is better than symmetric encryption
> because: In Asymmetric communication, New symmetric key is generated for
> each view change.

If you enable this, yes.

> Thus, a symmetric key which was leaked earlier cant be misused.

Correct

> At the same time, asymmetric encryption can create problems if
> AUTH is weak. Any recommendation on the type of AUTH tokens and
> Encryption type?

No, this depends on your system. Note that I've seen cases where more 
than one AUTH instances were placed onto the same stack.

Also, man-in-the-middle is still possible with the current key exchange 
in ASYM_ENCRYPT. I plan to move the key exchange functionality to a 
separate protocol and provide multiple implementations, see [1] for details.

[1] https://issues.jboss.org/projects/JGRP/issues/JGRP-2157

> Thanks
> Anuj
_______________________________________________
> javagroups-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/javagroups-users

-- 
Bela Ban, JGroups lead (http://www.jgroups.org)


------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
javagroups-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/javagroups-users

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

_______________________________________________
javagroups-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/javagroups-users