CVE-2016-2141 Authentication bypass in JGroups

Red Hat Product Security has been made aware of a critical issue in the way JGroups handles authentication. Successful exploitation of this flaw could allow a remote attacker to execute arbitrary code on a Java Virtual Machine running JGroups. It could also lead to integrity problems with JGroups communications, and confidentiality of the data transmitted.

It is strongly recommended to do clustering on a dedicated virtual local area network (VLAN). However, if a VLAN is not available, upgrade to a version of EAP which has a fix for CVE-2016-2141, and encrypt the communication (see How to secure systems using JGroups below). Messages sent to the cluster which are not encrypted will be discarded, preventing malicious attacks.

Red Hat Product Fixes

How to secure systems using JGroups

Security is used to prevent (1) non-authorized nodes being able to join a cluster and (2) non-members being able to communicate with cluster members.
1) is handled by AUTH or SASL which allows only authenticated nodes to join a cluster.
2) is handled by the encryption protocol (SYM_ENCRYPT or ASYM_ENCRYPT) which encrypts messages between cluster members such that a non-member cannot understand them.

Encryption methods

Symmetric encryption

For symmetric encryption a shared keystore is required:
1) Create a keystore:

$ java -cp modules/system/layers/base/org/jgroups/main/jgroups-<version>.jar org.jgroups.demos.KeyStoreGenerator --alg AES --size 128 --storeName defaultStore.keystore --storepass changeit --alias mykey

2) Configure the jgroups subsystem:

• SYM_ENCRYPT should be configured immediately before NAKACK.
• Note that the other protocols shown here for context will differ slightly depending on the JGroups version.

                    <stack name="udp">
                        <transport type="UDP" socket-binding="jgroups-udp"/>
                        <protocol type="PING"/>
                        <protocol type="MERGE3"/>
                        <protocol type="FD_SOCK" socket-binding="jgroups-udp-fd"/>
                        <protocol type="FD_ALL"/>
                        <protocol type="VERIFY_SUSPECT"/>
                        <protocol type="SYM_ENCRYPT">
                          <property name="provider">SunJCE</property>
                          <property name="sym_algorithm">AES</property>
                          <property name="encrypt_entire_message">true</property>
                          <property name="keystore_name">/home/jshepher/Documents/CVE-2016-2141/defaultStore.keystore</property>
                          <property name="store_password">changeit</property>
                          <property name="alias">mykey</property>
                        </protocol>
                        <protocol type="pbcast.NAKACK2"/>
                        <protocol type="UNICAST3"/>
                        <protocol type="pbcast.STABLE"/>
                        <protocol type="pbcast.GMS"/>
                        <protocol type="UFC"/>
                        <protocol type="MFC"/>
                        <protocol type="FRAG2"/>
                    </stack>

Asymmetric encryption

For Asymmetric encryption (A shared keystore is not required):
1) Configure the jgroups subsystem:

• ASYM_ENCRYPT should be configured immediately before NAKACK, and AUTH should be immediately before GMS.
• Note that the other protocols shown here for context will differ slightly depending on the JGroups version.

                    <stack name="udp">
                        <transport type="UDP" socket-binding="jgroups-udp"/>
                        <protocol type="PING"/>
                        <protocol type="MERGE3"/>
                        <protocol type="FD_SOCK" socket-binding="jgroups-udp-fd"/>
                        <protocol type="FD_ALL"/>
                        <protocol type="VERIFY_SUSPECT"/>
                        <protocol type="ASYM_ENCRYPT">
                            <property name="encrypt_entire_message">true</property>
                            <property name="sym_keylength">128</property>
                            <property name="sym_algorithm">AES/ECB/PKCS5Padding</property>
                            <property name="asym_keylength">512</property>
                            <property name="asym_algorithm">RSA</property>
                        </protocol>
                        <protocol type="pbcast.NAKACK2"/>
                        <protocol type="UNICAST3"/>
                        <protocol type="pbcast.STABLE"/>
                        <protocol type="AUTH">
                          <property name="auth_class">org.jgroups.auth.MD5Token</property>
                          <property name="auth_value">mytoken</property><!-- CHANGE THIS PASSWORD! -->
                          <property name="token_hash">MD5</property>
                        </protocol>
                        <protocol type="pbcast.GMS"/>
                        <protocol type="UFC"/>
                        <protocol type="MFC"/>
                        <protocol type="FRAG2"/>
                    </stack>

Note that while AUTH is optional with SYM_ENCRYPT, it is required by ASYM_ENCRYPT. There's a sanity check that will prevent a member to start if ASYM_ENCRYPT is present but AUTH is absent.

Encryption details

Encryption is based on a shared secret key that all members of a cluster have. The key is either acquired from a shared keystore (symmetric encryption) or a new joiner fetches it from the coordinator via public/private key exchange (asymmetric encryption).

A sent message is encrypted with the shared secret key by the sender and decrypted with the same secret key by the receiver(s).

By default, the entire message (including the headers) is encrypted, but it is also possible to only encrypt the payload (this is configurable). If the headers are not encrypted, it is possible to use replay attacks, because the sequence numbers (seqnos) of a message are seen.

The cost of encrypting the entire message includes serializing the entire message (including headers, flags, destination address etc) and encrypting it into the buffer of a new message (to the same destination). If message signing is enabled, the cost of computing a hashcode and encrypting it is added to the above cost.

Attributes present in both symmetric and asymmetric encryption include sign_msgs and encrypt_entire_message.

For more information, read the upstream JGroups documentation

Further Details for JBoss Portal Platform 6.2

JPP 6.2 provides GateIn, which includes its own, distinct JGroups configuration. These settings should be configured following the above guidance as well.
./gatein/gatein.ear/portal.war/WEB-INF/classes/jgroups/gatein-udp.xml
./gatein/gatein.ear/portal.war/WEB-INF/classes/jgroups/gatein-udp-idm.xml
./gatein/gatein.ear/portal.war/WEB-INF/classes/jgroups/gatein-tcp.xml
./gatein/gatein.ear/portal.war/WEB-INF/classes/jgroups/gatein-tcp-idm.xml