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

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