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

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