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

Version Type Errata Status JBoss Enterprise Application Platform 7.0 RPM Channel RHSA-2016-1332 JBoss Enterprise Application Platform 7.0 Zip File (Customer Portal) RHSA-2016-1333 JBoss Enterprise Application Platform 6.4 RPM Channel RHSA-2016-1330 JBoss Enterprise Application Platform 6.4 Zip File (Customer Portal) RHSA-2016-1331 JBoss Enterprise Application Platform 5.2 RPM Channel RHSA-2016-1328 JBoss Enterprise Application Platform 5.2 Zip File (Customer Portal) RHSA-2016-1329 JBoss Data Grid 6.6 Zip File (Customer Portal) RHSA-2016-1334 JBoss BRMS 5.3.1 Zip File (Customer Portal) RHSA-2016-1345 JBoss BRMS 6.3 Zip File (Customer Portal) RHSA-2016-1345 JBoss BPMS 6.3 Zip File (Customer Portal) RHSA-2016-1347 JBoss Data Virtualization 6.2 Zip File (Customer Portal) RHSA-2016-1346 JBoss SOA Platform 5.3.1 Zip File (Customer Portal) In QA Fuse Service Works 6.0.0 Zip File (Customer Portal) In QA JBoss Portal Platform 6.2 (further details for JPP) Zip File (Customer Portal) RHSA-2016-1374

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