IBM Support

Security vulnerabilities in WebSphere Message Broker and IBM Integration Bus that have led to changes in the default configuration

Product Documentation


Abstract

In response to recent PSIRT Advisories, various protocols and ciphers are disabled by default in IBM Integration Bus and WebSphere Message Broker

Content

Please see the table below for the versions of IBM Integration Bus and WebSphere Message Broker where the changes apply from:


SSLv3 RC4 Cipher Suites Diffie-Hellman (DH) SLOTH 3DES Cipher Suites
V10 10.0.0.0 10.0.0.2 10.0.0.2 10.0.0.4 10.0.0.9
V9 9.0.0.4 9.0.0.4 9.0.0.4 9.0.0.6 9.0.0.8
V8 8.0.0.6 8.0.0.7 8.0.0.7 8.0.0.7 8.0.0.9
V7 7.0.0.8 7.0.0.8 7.0.0.8



SSLv3

SSLv3 is disabled by default for all inbound and outbound connections, apart from ODBC database access, because SSLv3 is no longer considered secure due to the POODLE vulnerability. The following IBM security bulletin, published in October 2014, gives further details:  http://www.ibm.com/support/docview.wss?uid=swg21687678 

Where SSLv3 is not explicitly configured as the protocol all default values will be replaced automatically by TLS.

Users are recommended to update any configuration using SSLv3 to use TLS, by following these steps:

1. Update all explicitly configured protocol values for inbound and outbound connections to use TLS instead of SSLv3. The following IBM security bulletin gives further details on the required mitigations:  http://www.ibm.com/support/docview.wss?uid=swg21687678 

2. Update all ODBC configurations which use the Oracle Wire Protocol Driver to use only TLS1 or higher protocols. The following IBM security bulleting gives further details on the required mitigation:  http://www.ibm.com/support/docview.wss?uid=swg21687678 

3. Update all ODBC configurations using the client-based ODBC drivers (DB2 Client and Informix Client) by referring to the documentation for your client libraries about how to avoid a possible exposure to POODLE.

4. Update any Java code to use TLS instead of SSLv3. The following IBM security bulletin gives further details about the usage and recommended mitigations for Java: http://www.ibm.com/support/docview.wss?uid=swg21688165 

5. It is necessary to update both sides of any communication to use TLS:
- For any inbound communication to WebSphere Message Broker, the sending application must be updated.
- For any outbound communication from WebSphere Message Broker, the receiving application must be updated.


It is strongly recommended that these changes are made to avoid the known security vulnerability in SSLv3. However, if it is not possible to use TLS communication, SSLv3 can be re-enabled by using the following commands:

* To re-enable SSLv3 for an entire integration node or broker:

mqsichangeproperties <BrokerName> -o BrokerRegistry -n allowSSLv3 -v true

* To re-enable SSLv3 for a specific execution group:

mqsichangeproperties <BrokerName> -e <ExecutionGroupLabel> -o ComIbmJVMManager -n allowSSLv3 -v true

* To re-enable SSLv3 for the broker wide httplistener:

mqsichangeproperties <BrokerName> -b httplistener -o HTTPListener -n allowSSLv3 -v true


RC4 Cipher Suites

The affected RC4 cipher suites were not enabled by default for inbound and outbound secure connections, apart from ODBC database access.
Users will only be affected by this change if they have explicitly configured an allowed cipher list which includes one of the affected ciphers sites which are now disabled.
The list of affected RC4 ciphers suites which are now disabled by default are as listed in the Java 7 Knowledge Center:  http://www-01.ibm.com/support/knowledgecenter/SSYKE2_7.0.0/com.ibm.java.security.component.70.doc/security-component/jsse2Docs/ciphersuites.html
* SSL_ECDHE_ECDSA_WITH_RC4_128_SHA
* SSL_ECDHE_RSA_WITH_RC4_128_SHA
* SSL_ECDH_ECDSA_WITH_RC4_128_SHA
* SSL_ECDH_RSA_WITH_RC4_128_SHA
* SSL_RSA_WITH_RC4_128_MD

Users are recommended to update any configuration using these ciphers suites to use a different cipher suite.

To disable RC4 ciphers for the ODBC database access follow the mitigation steps in the IBM security bulletin:  http://www-01.ibm.com/support/docview.wss?uid=swg21883122


It is strongly recommended that changes are made to avoid the known security vulnerability in the RC4 ciphers. However, if it is not possible to use alternative ciphers, then the disabled RC4 ciphers can be re-enabled by using the following steps:

For users of fix packs 10.0.0.4, 9.0.0.8, 8.0.0.7 or later:

    For each integration node or broker by using the following command:

      mqsichangeproperties <Node/Broker Name> -o BrokerRegistry -n reenableTransportAlgorithms -v "RC4"

    You must restart the integration node or broker to pick up the configuration change.

    To check if there are existing values configured for the reenableCertificateAlgorithms or reenableTransportAlgorithms properties, use the following command:
      mqsireportproperties <Node/Broker Name> -o BrokerRegistry -r

    If there are values already configured then additional algorithms can be specified by comma separating the values. For example:
      mqsichangeproperties <Node/Broker Name> -o BrokerRegistry -n reenableTransportAlgorithms -v "\"MD5withRSA,RC4, DH keySize < 768\""

For users of earlier fixpacks:

    1. Edit the java.security file in the jre\lib\security directory of the IBM Integration Bus installation. For example:
      v10:
      c:\Program Files\IBM\IIB\10.0.0.2\common\jdk\jre\lib\security\java.security 
      /opt/ibm/iib/10.0.0.2/common/jdk/jre/lib/security/java.security (LinuxX64 only)
      /opt/ibm/iib/10.0.0.2/common/jre/lib/security/java.security

      v9:
      c:\Program Files\IBM\MQSI\9.0.0.4\jre17\lib\security\java.security 
      /opt/ibm/mqsi/9.0.0.4/jre17/lib/security/java.security

    2. Search for the string "jdk.tls.disabledAlgorithms" and remove RC4 from the list of disabled algorithms.
    For example:
      Change:
      jdk.tls.disabledAlgorithms=SSLv3, RC4, DH keySize < 768

      To:
      jdk.tls.disabledAlgorithms=SSLv3, DH keySize < 768


Diffie-Hellman (DH)

All DH and DHE cipher suites apart from ECDH and ECDHE ones are effected by this change.
If a client or server used for inbound or outbound connections attempts to use a keysize of less than 768 bits then the connection will terminate.
Users are recommended to update all remote clients or servers to use keysizes greater than 768 bits.

To disable DH and DHE ciphers for ODBC database access follow the mitigations steps in the IBM security bulletin:  http://www-01.ibm.com/support/docview.wss?uid=swg21958955


It is strongly recommended that changes are made to avoid the known security vulnerability in the DH ciphers. However, if it is not possible to use larger keysizes or alternative ciphers, then the keysize restriction can be lifted by using the following steps:

For users of fix packs 10.0.0.4, 9.0.0.8, 8.0.0.7 or later:

    For each integration node or broker by using the following command:

      mqsichangeproperties <Node/Broker Name> -o BrokerRegistry -n reenableTransportAlgorithms -v "DH keySize < 768"

    You must restart the integration node or broker to pick up the configuration change.
    To check if there are existing values configured for the reenableCertificateAlgorithms or reenableTransportAlgorithms properties, use the following command:

      mqsireportproperties <Node/Broker Name> -o BrokerRegistry -r

    If there are values already configured then additional algorithms can be specified by comma separating the values. For example:

      mqsichangeproperties <Node/Broker Name> -o BrokerRegistry -n reenableTransportAlgorithms -v "\"MD5withRSA,RC4, DH keySize < 768\""

For users of earlier fixpacks:

    1. Edit the java.security file in the jre\lib\security directory of the IBM Integration Bus installation. This will re-enable keysizes of less than 768 bits for all integration nodes or brokers using the installation
    For example:

      v10:
      c:\Program Files\IBM\IIB\10.0.0.2\common\jdk\jre\lib\security\java.security 
      /opt/ibm/iib/10.0.0.2/common/jdk/jre/lib/security/java.security (LinuxX64 only)
      /opt/ibm/iib/10.0.0.2/common/jre/lib/security/java.security

      v9:
      c:\Program Files\IBM\MQSI\9.0.0.4\jre17\lib\security\java.security 
      /opt/ibm/mqsi/9.0.0.4/jre17/lib/security/java.security

    2. Search for the string "jdk.tls.disabledAlgorithms" and remove the DH keySize entry from the list of disabled algorithms.
    For example:

      Change:
      jdk.tls.disabledAlgorithms=SSLv3, RC4, DH keySize < 768

      To:
      jdk.tls.disabledAlgorithms=SSLv3, RC4


SLOTH

As a result of the SLOTH vulnerability the cryptographic hash algorithm MD5 is no longer considered secure and it is disabled by default for all uses apart from ODBC database access. Any certificate that is signed with MD5 and any cipher suite used during TLS handshaking which tries to use MD5withRSA is not accepted. The following IBM security bulletin, published in February 2016, gives further details: http://www-01.ibm.com/support/docview.wss?uid=swg21976779

Users are recommended to update any configuration using MD5 certificates or MD5withRSA ciphers to more secure alternatives.

It is strongly recommended that configuration changes are made to avoid the known security vulnerability with MD5. However, if it is not possible to use alternative certificates or ciphers, MD5 can be re-enabled for an integration node or broker by using the following steps:

For users of fix packs 10.0.0.4, 9.0.0.8, 8.0.0.7 or later:
    For each integration node or broker by using the following command:

      mqsichangeproperties <Node/Broker Name> -o BrokerRegistry -n reenableCertificateAlgorithms -v "MD5"

      mqsichangeproperties <Node/Broker Name> -o BrokerRegistry -n reenableTransportAlgorithms -v "MD5withRSA"
    You must restart the integration node or broker to pick up the configuration change.

    To check if there are existing values configured for the reenableCertificateAlgorithms or reenableTransportAlgorithms properties, use the following command:

      mqsireportproperties <Node/Broker Name> -o BrokerRegistry -r
    If there are values already configured then additional algorithms can be specified by comma separating the values. For example:
      mqsichangeproperties <Node/Broker Name> -o BrokerRegistry -n reenableTransportAlgorithms -v "\"MD5withRSA,RC4, DH keySize < 768\""

For users of earlier fixpacks:

    1. Edit the java.security file in the jre\lib\security directory of the IBM Integration Bus installation. This will re-enable MD5 for all integration nodes or brokers using the installation.
    For example:
      v10:
      c:\Program Files\IBM\IIB\10.0.0.2\common\jdk\jre\lib\security\java.security 
      /opt/ibm/iib/10.0.0.2/common/jdk/jre/lib/security/java.security (LinuxX64 only)
      /opt/ibm/iib/10.0.0.2/common/jre/lib/security/java.security

      v9:
      c:\Program Files\IBM\MQSI\9.0.0.4\jre17\lib\security\java.security 
      /opt/ibm/mqsi/9.0.0.4/jre17/lib/security/java.security

    2. Search for the string "jdk.tls.disabledAlgorithms" and remove the MD5withRSA entry from the list of disabled algorithms.
    For example:
      Change:
      jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA

      To:
      jdk.tls.disabledAlgorithms=SSLv3, RC4

    3. Search for the string " jdk.certpath.disabledAlgorithms" and remove the MD5 entry from the list of disabled algorithms.
    For example:
      Change:
      jdk.certpath.disabledAlgorithms=MD2, MD5, RSA keySize < 1024

      To:
      jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024


3DES Cipher Suites

As a result of the CVE-2016-2183 vulnerability the cryptographic algorithm 3DES_EDE_CBC is no longer considered secure. All uses of the 3DES_EDE_CBC algorithm are disabled through Java. Any cipher suite used during TLS handshaking which tries to use 3DES_EDE_CBC is not accepted.

It is strongly recommended that the 3DES cipher suite remains disabled. However, if it is not possible to use alternative ciphers then 3DES can be re-enabled as follows:

For users of fix packs 10.0.0.4, 9.0.0.8, 8.0.0.7 or later:

    For each integration node or broker use the following command:
      mqsichangeproperties <Node/Broker Name> -o BrokerRegistry -n reenableTransportAlgorithms -v "DESede"
    You must restart the integration node or broker to pick up the configuration change.

    To check if there are existing values configured for the reenableCertificateAlgorithms or reenableTransportAlgorithms properties, use the following command:
      mqsireportproperties <Node/Broker Name> -o BrokerRegistry -r
    If there are values already configured then additional algorithms can be specified by comma separating the values. For example:
      mqsichangeproperties <Node/Broker Name> -o BrokerRegistry -n reenableTransportAlgorithms -v "\"SSLv3, RC4, DESede\""

Cross reference information
Product Component Platform Version Edition
WebSphere Message Broker Security 7.0, 8.0 All Editions

Document information

More support for: IBM Integration Bus

Component: Security

Software version: 7.0, 8.0, 9.0, 10.0

Operating system(s): AIX, HP-UX, Linux, Solaris, Windows, z/OS

Software edition: All Editions

Reference #: 7047062

Modified date: 04 July 2018