IBM PureApplication System Version 2.1.0.2 This readme document provides information on installing PureApplication System Version 2.1.0.2. Version 2.1.0.2 includes fixes for these security vulnerabilities: CVEID: CVE-2015-0138 DESCRIPTION: A vulnerability in various IBM SSL/TLS implementations could allow a remote attacker to downgrade the security of certain SSL/TLS connections. An IBM SSL/TLS client implementation could accept the use of an RSA temporary key in a non-export RSA key exchange ciphersuite. This could allow a remote attacker using man-in-the-middle techniques to facilitate brute-force decryption of TLS/SSL traffic between vulnerable clients and servers. This vulnerability is also known as the FREAK attack. CVEID: CVE-2015-0204 DESCRIPTION: A vulnerability in the OpenSSL ssl3_get_key_exchange function could allow a remote attacker to downgrade the security of certain TLS connections. An OpenSSL client accepts the use of an RSA temporary key in a non-export RSA key exchange ciphersuite. This could allow a remote attacker using man-in-the-middle techniques to facilitate brute-force decryption of TLS/SSL traffic between vulnerable clients and servers. This vulnerability is also known as the FREAK attack. CVEID: CVE-2015-1916 DESCRIPTION: Server applications which use the IBM Java Secure Socket Extension provider to accept SSL/TLS connections are vulnerable to a denial of service attack due to an unspecified vulnerability. CVEID: CVE-2015-1920 DESCRIPTION: WebSphere Application Server could allow a remote attacker to execute arbitrary code by connecting to a management port and executing a specific sequence of instructions. CVEID: CVE-2015-2808 DESCRIPTION: The RC4 algorithm, as used in the TLS protocol and SSL protocol, could allow a remote attacker to obtain sensitive information. An attacker could exploit this vulnerability to remotely expose account credentials without requiring an active man-in-the-middle session. Successful exploitation could allow an attacker to retrieve credit card data or other sensitive information. This vulnerability is commonly referred to as "Bar Mitzvah Attack". CVEID: CVE-2015-4000 DESCRIPTION: The TLS protocol could allow a remote attacker to obtain sensitive information, caused by the failure to properly convey a DHE_EXPORT ciphersuite choice. An attacker could exploit this vulnerability using man-in-the-middle techniques to force a downgrade to 512-bit export-grade cipher. Successful exploitation could allow an attacker to recover the session key as well as modify the contents of the traffic. This vulnerability is commonly referred to as "Logjam". BEFORE YOU BEGIN Ensure that the system is updated to Version 2.1.0.1. PROCEDURE The tasks for installing the interim fix are provided in the Interim Fix Upgrade guide that is provided with the fix: Upgrade_Guide.pdf. *** Security Notice *** ---------------- BEFORE THE UPGRADE -------------------------------- Disabling SSLv3 protocol Before upgrading to IBM PureApplication System Version 2.1.0.2, you must disable SSLv3 due to a vulnerability that has been referred to as the Padding Oracle On Downgraded Legacy Encryption (POODLE) attack. BEFORE YOU BEGIN Ensure that you or your IBM service representative has applied IBM PureApplication System V2.1.0.1 and followed the mitigation procedure for all deployed virtual machines. Additionally, upgrade to caching service Version 2.1.0.2. Note: Caching service Version 2.1.0.0 and earlier instances cannot be upgraded to caching service Version 2.1.0.2. For these instances, you must delete any existing caching service prior to upgrading the foundation pattern types. After the foundation pattern types upgrade, deploy the new caching service instances of service Version 2.1.0.2 as described in the following procedure. ABOUT THIS TASK This task describes mitigation procedures for deployed instances of virtual applications, shared services, and virtual systems, in addition to deployed instances of classic virtual systems. After you apply the JRE upgrade emergency fix, upgrade to IBM PureApplication System V2.1, and apply the mitigation steps, Java management processes that are running on deployed virtual machines are configured to support the SSL_TLSv2 protocol suite. The SSL_TLSv2 protocol suite enables TLSv1.2, TLSv1.1, TLSv1, and SSLv3 in this precedence order. SSLv3 is disabled by JRE default, therefore, SSL_TLSv2 only enables the TLS protocols: TLSv1.2, TLSv1.1, and TLSv1. At runtime during client and server SSL handshake, the best protocol that the client and server have in common is selected. For example, TLSv1.2 is selected if both support TLSv1.2. For more information on JRE default protocol configuration, see Alternative mitigation options: http://www-01.ibm.com/support/docview.wss?uid=swg21688165#issues. -- W2500/W1500 systems -- Download one of the following base operating system images from the IBM Passport Advantage Online website. This image contains the required JRE upgrade of JDK7: SR8 FP10 or later and/or JDK6: SR16 FP3 or later. For more information, see Downloading IBM OS images: http://www-01.ibm.com/support/knowledgecenter/SSCR9A_2.1.0/doc/iwd/pct_downloadosimages.dita. IBM OS Image for Red Hat Linux Systems : 2.1.1.0 (RHEL 6.6 image) IBM OS Image for Red Hat Linux Systems : 3.0.0.0 (RHEL 7 image) Note: SSLv3 is disabled by JRE default policy in the new base operating system images unless you remove the jdk.tls.disabledAlgorithms=SSLv3 property from the JRE java.security file. The following steps are for new pattern deployments leveraging new base operating system images which eliminate the need for the mitigation procedures. • For new virtual application, shared service, and virtual system deployments, use the following procedure to change the default deployment settings in order to add the new operating system images: 1. Click Cloud > Default Deploy Settings. 2. Click Delete in the Acton column to delete the old base operating system image. 3. Click Add to add the new version of base operating system image. • For new classic virtual system deployments, use the new patterns that are built on the new operating system images. Alternatively, use the following procedure to upgrade existing patterns: 1. Extend the original image. For more information, see Extending and capturing virtual images: http://www-01.ibm.com/support/knowledgecenter/SSCR9A_2.1.0/doc/iwd/pct_extend_vi.dita. 2. Upload IBM PureApplication System V2.1 to the PureApplication System catalog. 3. Apply IBM PureApplication System V2.1 to the extended classic virtual system instance. Note: While applying the fix to each instance running on Intel operating systems, clear the check from the "Take a snapshot before service is applied" check box. 4. Capture and receive the new image. For more information, see Extending and capturing virtual images: http://www-01.ibm.com/support/knowledgecenter/SSCR9A_2.1.0/doc/iwd/pct_extend_vi.dita. 5. Clone existing patterns and specify to use the newly captured image. Cloning virtual system patterns: http://www-01.ibm.com/support/knowledgecenter/SSCR9A_2.1.0/doc/iwd/pat_clonesvsys.dita?lang=en. Procedure To disable SSLv3 protocol in virtual application, shared services, and virtual system deployed instances, perform the following steps: Important: You must perform these steps in the following order or the fix will not be successful. 1. For virtual system instances only, use the following steps to apply vsys-part-backup-ifix.zip: a. Upload vsys-part-backup-ifix.zipto the PureApplication System catalog. For more information, see Adding emergency fixes: http://www-01.ibm.com/support/knowledgecenter/SSCR9A_2.1.0/doc/iwd/pct_add_ef.dita. b. Install the emergency fix to the running instance. 2. Optionally, upgrade foundation-ptype to Version 2.1.2.0 and restart each instance or individual virtual machine for the pattern type upgrade to take effect. For more information, see Starting and stopping virtual machines: http://www-01.ibm.com/support/knowledgecenter/SSCR9A_2.1.0/doc/systemconsole/t_addvirtmachine.dita. 3. Run the following command to verify that SSLv3 is disabled and that the deployed virtual machine supports TLSv1.2 protocols: deployer.virtualapplications.get().virtualmachines[].check_compliance() For example, deployer.virtualapplications.get(d-4e04e98d-8c3d-4bec-bab1-ca033419ffc3).virtualmachines[0].check_compliance() 4. Optionally, run the following command to configure the supported JRE protocols: deployer.virtualapplications.get().virtualmachines[].set_compliance_policy() For example, deployer.virtualapplications.get(d-4e04e98d-8c3d-4bec-bab1-ca033419ffc3).virtualmachines[0].set_compliance_policy(SSL_TLSv2) 5. If you configured the supported JRE protocols, restart each virtual machine for the configuration to take effect. Note: Supported protocol suites include SSL_TLSv2, SSL_TLS, TLS, TLSv1, TLSv1.1, TLSv1.2, SSL, and SSLv3. SSLv3 is disabled by JRE default policy in the new base operating system images unless you remove the jdk.tls.disabledAlgorithms=SSLv3 property from the JRE java.security file. 6. Run the following command to verify the supported JRE protocol: deployer.virtualapplications.get().virtualmachines[].get_compliance_policy() For example, deployer.virtualapplications.get(d-4e04e98d-8c3d-4bec-bab1-ca033419ffc3).virtualmachines[0].get_compliance_policy() Note: The get_compliance_policy command returns a null string if you have not issued the set_compliance_policy command. The default protocol configuration is SSL_TLSv2, which enables TLSv1.2, TLSv1.1, TLSv1, and SSLv3. 7. Use the following steps to deploy a new caching service instance using the new version of the caching service plug-in: a. Click Manage > Operations > CachingMaster, Grid Administration > Create grid to go to the new caching service instance. b. Create a session grid with a dedicated user name and password and a proper grid cap for the web application. c. Use a Secure Shell (SSH) connection to connect to the virtual machine where Websphere Application Server is running. d. Run the wsadmin command: /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/bin/wsadmin.sh -lang jython e. Run the following command to configure the web application's session management with the new caching service IP, user, password, and grid name. The following command uses the example of configuring the web application HttpSessionSample.war. AdminApp.edit('HttpSessionSample.war', '[-SessionManagement [[true XC10SessionManagement "' + + ':!:' + + ':!:' + + ':!:' + + '"]]]') f. Locate the web application's splicer.properties file and set reuseSessionId=true. g. Restart WebSphere Application Server for the new configuration to take effect. To disable SSLv3 protocol in classic virtual system deployed instances, use a Secure Shell (SSH) connection to connect to each virtual machine and perform the following steps: Important: You must perform these steps in the following order or the fix will not be successful. 1. Use the following steps to verify that SSLv3 is disabled and that the deployed virtual machine supports TLSv1.2 protocols: a. Run the following command: openssl s_client -connect vm_ip:9999 where vm_ip is the IP address of the deployed virtual machine. b. SSH into each virtual machine and run the following command: /opt/IBM/ibm-java-dir/jre/bin/java -version • Virtual machines running JRE6 (classic virtual system instances) see the version updated to SR16 FP3 • Virtual machines running JRE7 (shared service, virtual applications, and virtual system instances) see the version updated to SR8 FP10 c. Run the following command to verify that SSLv3 is disabled by JRE by default: openssl s_client -connect vm_ip:9999 -ssl3 where vm_ip is the IP address of the deployed virtual machine. An error message returns showing a handshake failure because SSLv3 is not supported. 2. Use the following steps if SSLv3 is not disabled by JRE default: a. Use a SSH connection to connect to the virtual machine and create the following configuration file: /etc/iwd/ssl_protocol.properties b. In the configuration file, specify the supported protocols. For example, DEFAULT_SSL_PROTOCOL=SSL_TLSv2 Note: Supported protocol suites include SSL_TLSv2, SSL_TLS, TLS, TLSv1, TLSv1.1, TLSv1.2, SSL, and SSLv3. SSLv3 is disabled by JRE default policy in the new base operating system images unless you remove the jdk.tls.disabledAlgorithms=SSLv3 property from the JRE java.security file. c. Restart your virtual machine for the configuration to take effect. If you specified any protocol suite containing TLS, then SSLv3 is disabled after the virtual machine restart. 3. Run the following command to check the supported TLS protocols: deployer.settings.compliancepolicy._getCompliancePolicy() Note: A null string returns if you have not issued a _setCompliancePolicy CLI command. The default protocol configuration is SSL_TLSv2 which enables TLSv1.2, TLSv1.1, and TLSv1. 4. Use the following steps if all deployments support TLS protocols: a. Run the following command to disable SSLv3 in the PureApplication management software: deployer.settings.compliancepolicy._setCompliancePolicy('SSL_TLSv2') Note: Running this command also activates a JRE fix to disable SSLv3 by default. In this example the configuration command selects TLSv1.2, TLSv1.1, TLSv1, and SSLv3 protocols, however, SSLv3 will be disabled at runtime by JRE. b. On the primary PureApplication System management node, restart the PureApplication management software for the change to take effect. -- W2700/W1700 systems -- Download one of the following base operating system images from the IBM Passport Advantage Online website. These images contain the required JRE upgrade of JDK6: SR16 FP3 or later. For more information, see http://www-01.ibm.com/support/knowledgecenter/SSCRSX_2.1.0/doc/iwd/pct_downloadosimages.dita IBM OS Image for AIX Systems: 2.1.1.0 (AIX 7.1 image) IBM OS Image for AIX Systems: 1.1.1.0 (AIX 6.1 image) Note: SSLv3 is disabled by JRE default policy in the new base operating system images unless you remove the jdk.tls.disabledAlgorithms=SSLv3 property from the JRE java.security file. The following steps are for new pattern deployments leveraging new base operating system images which eliminate the need for the mitigation procedures. • For new virtual application, shared service, and virtual system deployments, use the following procedure to change the default deployment settings in order to add the new operating system images: 1. Click Cloud > Default Deploy Settings. 2. Click Change to change the base operating system image to the new version of the base operating system. • For new classic virtual system deployments, use the new patterns that are built on the new operating system images. Alternatively, use the following procedure to upgrade existing patterns: 1. Extend the original image. For more information, see Extending and capturing virtual images: http://www-01.ibm.com/support/knowledgecenter/SSCRSX_2.1.0/doc/iwd/pct_extend_vi.dita. 2. Upload IBM PureApplication System V2.1 to the PureApplication System catalog. 3. Apply IBM PureApplication System V2.1 to the extended classic virtual system instance. 4. Capture and receive the new image. For more information, see Extending and capturing virtual images: http://www-01.ibm.com/support/knowledgecenter/SSCRSX_2.1.0/doc/iwd/pct_extend_vi.dita. 5. Clone existing patterns and specify to use the newly captured image. For more information, see Cloning virtual system patterns: http://www-01.ibm.com/support/knowledgecenter/SSCRSX_2.1.0/doc/iwd/pat_clonesvsys.dita?lang=en. Procedure To disable SSLv3 protocol in virtual application, shared services, and virtual system deployed instances, perform the following steps: Important: You must perform these steps in the following order or the fix will not be successful. 1. For virtual system instances only, use the following steps to apply vsys-part-backup-ifix.zip: a. Upload vsys-part-backup-ifix.zipto the PureApplication System catalog. For more information, see Adding emergency fixes: http://www-01.ibm.com/support/knowledgecenter/SSCRSX_2.1.0/doc/iwd/pct_add_ef.dita. b. Install the emergency fix to the running instance. 2. Optionally, upgrade foundation-ptype to Version 2.1.2.0 and restart each instance or individual virtual machine for the pattern type upgrade to take effect. For more information, see Starting and stopping virtual machines: http://www-01.ibm.com/support/knowledgecenter/SSCRSX_2.1.0/doc/systemconsole/t_addvirtmachine.dita. 3. Run the following command to verify that SSLv3 is disabled and that the deployed virtual machine supports TLSv1.2 protocols: deployer.virtualapplications.get().virtualmachines[].check_compliance() For example, deployer.virtualapplications.get(d-4e04e98d-8c3d-4bec-bab1-ca033419ffc3).virtualmachines[0].check_compliance() 4. Optionally, run the following command to configure the supported JRE protocols: deployer.virtualapplications.get().virtualmachines[].set_compliance_policy() For example, deployer.virtualapplications.get(d-4e04e98d-8c3d-4bec-bab1-ca033419ffc3).virtualmachines[0].set_compliance_policy(SSL_TLSv2) 5. If you configured the supported JRE protocols, restart each virtual machine for the configuration to take effect. Note: Supported protocol suites include SSL_TLSv2, SSL_TLS, TLS, TLSv1, TLSv1.1, TLSv1.2, SSL, and SSLv3. SSLv3 is disabled by JRE default policy in the new base operating system images unless you remove the jdk.tls.disabledAlgorithms=SSLv3 property from the JRE java.security file. 6. Run the following command to verify the supported JRE protocol: deployer.virtualapplications.get().virtualmachines[].get_compliance_policy() For example, deployer.virtualapplications.get(d-4e04e98d-8c3d-4bec-bab1-ca033419ffc3).virtualmachines[0].get_compliance_policy() Note: The get_compliance_policy command returns a null string if you have not issued the set_compliance_policy command. The default protocol configuration is SSL_TLSv2, which enables TLSv1.2, TLSv1.1, TLSv1, and SSLv3. 7. Use the following steps to deploy a new caching service instance using the new version of the caching service plug-in: a. Click Manage > Operations > CachingMaster, Grid Administration > Create grid to go to the new caching service instance. b. Create a session grid with a dedicated user name and password and a proper grid cap for the web application. c. Use a Secure Shell (SSH) connection to connect to the virtual machine where Websphere Application Server is running. d. Run the wsadmin command: /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/bin/wsadmin.sh -lang jython e. Run the following command to configure the web application's session management with the new caching service IP, user, password, and grid name. The following command uses the example of configuring the web application HttpSessionSample.war. AdminApp.edit('HttpSessionSample.war', '[-SessionManagement [[true XC10SessionManagement "' + + ':!:' + + ':!:' + + ':!:' + + '"]]]') f. Locate the web application's splicer.properties file and set reuseSessionId=true. g. Restart WebSphere Application Server for the new configuration to take effect. To disable SSLv3 protocol in classic virtual system deployed instances, use a Secure Shell (SSH) connection to connect to each virtual machine and perform the following steps: Important: You must perform these steps in the following order or the fix will not be successful. 1. Use the following steps to verify that SSLv3 is disabled and that the deployed virtual machine supports TLSv1.2 protocols: a. Run the following command: openssl s_client -connect vm_ip:9999 where vm_ip is the IP address of the deployed virtual machine. b. SSH into each virtual machine and run the following command: /opt/IBM/ibm-java-dir/jre/bin/java -version • Virtual machines running JRE6 (classic virtual system instances) see the version updated to SR16 FP3 • Virtual machines running JRE7 (shared service, virtual applications, and virtual system instances) see the version updated to SR8 FP10 c. Run the following command to verify that SSLv3 is disabled by JRE by default: openssl s_client -connect vm_ip:9999 -ssl3 where vm_ip is the IP address of the deployed virtual machine. An error message returns showing a handshake failure because SSLv3 is not supported. 2. Use the following steps if SSLv3 is not disabled by JRE default: a. Use a SSH connection to connect to the virtual machine and create the following configuration file: /etc/iwd/ssl_protocol.properties b. In the configuration file, specify the supported protocols. For example, DEFAULT_SSL_PROTOCOL=SSL_TLSv2 Note: Supported protocol suites include SSL_TLSv2, SSL_TLS, TLS, TLSv1, TLSv1.1, TLSv1.2, SSL, and SSLv3. SSLv3 is disabled by JRE default policy in the new base operating system images unless you remove the jdk.tls.disabledAlgorithms=SSLv3 property from the JRE java.security file. c. Restart your virtual machine for the configuration to take effect. If you specified any protocol suite containing TLS, then SSLv3 is disabled after the virtual machine restart. 3. Run the following command to check the supported TLS protocols: deployer.settings.compliancepolicy._getCompliancePolicy() Note: A null string returns if you have not issued a _setCompliancePolicy CLI command. The default protocol configuration is SSL_TLSv2 which enables TLSv1.2, TLSv1.1, and TLSv1. 4. Use the following steps if all deployments support TLS protocols: a. Run the following command to disable SSLv3 in the PureApplication management software: deployer.settings.compliancepolicy._setCompliancePolicy('SSL_TLSv2') Note: Running this command also activates a JRE fix to disable SSLv3 by default. In this example the configuration command selects TLSv1.2, TLSv1.1, TLSv1, and SSLv3 protocols, however, SSLv3 will be disabled at runtime by JRE. b. On the primary PureApplication System management node, restart the PureApplication management software for the change to take effect.