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

On 13/03/17 11:01, Questions/problems related to using JGroups 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"

Correct

> But as per your reply, "the message would be dropped".

Yes, in master (4.x), the 3.6 branch and selected branches to which 
JGRP-2021 was backported to (IIRC, 3.2 and possibly 3.4).

Older branches or branches without backport would still be affected

> 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

That code was not correct: encrypt_entire_message has been removed from 
EncryptHeader as a malicious node could simply change the value to false.

> and skip AUTH to be able
> to send messages to the cluster and install a new view including itself ?

Right.

> 2. https://issues.jboss.org/projects/JGRP/issues/JGRP-2157 link is not
> working.

It is 2155 and 2174.

> So, you mean that MitM is a possibility in Asymmetric encryption?

Yes, for the key exchange. [1] will fix this.

> you say this because someone in the middle could just see
> the AUTH token and use it to authenticate itself?

No, I'm referring to the key exchange part of ASYM_ENCRYPT (SYM_ENCRYPT 
is not affected).
Note that once [1]is in place, AUTH may be omitted if ASYM_ENCRYPT + 
KEY_EXCHANGE is used.

> All in all what would be your recommendation for production systems with respect to AUTH
> tokens and Encryption?

I've got customers in production with SYM_ENCRYPT and AUTH+MD5Token.

> 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/.
> <https://www.cvedetails.com/cve/CVE-2016-2141/>
> Could you help me with the link?

Start with 
https://blogs.oracle.com/security/entry/security_alert_cve_2015_4852 and 
https://www.owasp.org/index.php/Deserialization_of_untrusted_data

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

> Thanks
> Anuj
>
>
>
> 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,
> <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]
> <mailto:[email protected]>
>> https://lists.sourceforge.net/lists/listinfo/javagroups-users
>
> --
> Bela Ban, JGroups lead (http://www.jgroups.org <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]
> <mailto:[email protected]>
> https://lists.sourceforge.net/lists/listinfo/javagroups-users
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> 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
>

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


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