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

This may be a regression of ENCRYPT in 3.6 (that wasn't present in 
3.4.3), as the code in [1] clearly passes up a message that doesn't have 
an EncryptHeader.

[1] 
https://github.com/belaban/JGroups/blob/3.6/src/org/jgroups/protocols/ENCRYPT.java#L554

On 21/03/17 08:37, Questions/problems related to using JGroups wrote:
> If you have (symmetric) ENCRYPT but set encrypt_entire_message to false,
> then a rogue JOIN request can get passed up as the message length is 0
> (the JOIN request's info is in the header).
>
> If you backport {A}SYM_ENCRYPT_TEST from the 3.6 branch to 3.4.3
> (replace {ASYM_}ENCRYPT with ENCRYPT, then you'll see which scenarios
> fail and which ones pass.
>
>
> On 20/03/17 18:52, Questions/problems related to using JGroups wrote:
>> Hi Bela Ban,
>>
>> Thanks for the information. Please find my comments below:
>>
>>> 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).
>>
>> I have checked the code for 3.4.3 and JGRP-2021 has not been backported
>> . If that's the case, What steps can I take to reproduce JGRP-2021 in
>> 3.4.3 so that I am able to send message and install view in a cluster
>> using symmetric encryption?
>>
>>> It is 2155 and 2174.
>>
>> I read JGRP-2155 but it seems unrelated and 2174 is not accessible.
>>
>>
>>
>> Thanks
>> Anuj
>>
>> On Monday, 20 March 2017 2:07 PM, Questions/problems related to using
>> JGroups <[email protected]> wrote:
>>
>>
>>
>>
>> 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
>> <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
>> <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]
>> <mailto:[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]>
>>> <mailto:[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/><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]>
>>> <mailto:[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]
>> <mailto:[email protected]>
>>> https://lists.sourceforge.net/lists/listinfo/javagroups-users
>>>
>>
>> --
>> Bela Ban, JGroups lead (http://www.jgroups.org <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
>>
>> _______________________________________________
>> javagroups-users mailing list
>> [email protected]
>> <mailto:[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
>>
>

-- 
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