IBM Patches Pair Of TLS Flaws In IBM i

March 7, 2016 Alex Woodie

IBM i shops are encouraged to be vigilant following a pair of security vulnerabilities that have emerged in the encryption protocols used by the platform. This includes the SLOTH vulnerability in the IBM i JVM that IBM patched February 15. But a bigger threat looms in the form of DROWN, a potentially significant vulnerability in the SSL/TLS stack that IBM patched on March 1.

IBM issued a series of patches to address the SLOTH vulnerability in the IBM i JVMs. According to IBM’s Security Bulletin for SLOTH, a problem with the IBM i JVM’s implementation of the TLS 1.2 protocol and how it processes MD5 hash algorithms could weaken security during the TLS handshake with the server. “An attacker could exploit this vulnerability using man-in-the-middle techniques to impersonate a TLS server and obtain credentials,” the company says.

The security vulnerability, which is identified by the Common Vulnerabilities and Exposures database as CVE-2015-7575, carries a Common Vulnerability Scoring System (CVSS) base score of 7.1, which is relatively high. Karthikeyan Bhargavan, a security researcher with miTLS, is credited with discovering the SLOTH flaw in 2015, although its presence was not disclosed until this year. The TLS working group is reportedly working to remove the MD5 hash algorithm from TLS 1.3.

IBM issued nearly two dozen PTFs to address the SLOTH vulnerability across all supported versions of IBM i (versions 6.1, 7.1, and 7.2); across all supported versions of Java and the associated JVM (Java versions 6.0, 6.26, 7.0, 7.1, and version 8); and in both 32-bit and 64-bit versions. There are no workarounds and IBM recommends applying the patches immediately.

But a potentially more significant problem with TLS emerged last week when security researchers disclosed the existence of the DROWN vulnerability. On Friday morning, IBM’s Product Security Incident Response team issued the following note on its PSIRT blog:

“OpenSSL vulnerabilities were disclosed on March 1, 2016, by the OpenSSL Project. OpenSSL is used by IBM i. IBM i has addressed the applicable CVEs including the ‘DROWN: Decrypting RSA with Obsolete and Weakened eNcryption’ vulnerability.”

Eight individual OpenSSL vulnerabilities collectively compose the DROWN problem, according to IBM’s Security Bulletin for DROWN. While the flaws exist in OpenSSL, they can be used to weaken TLS security, which is the latest encryption protocol used for ecommerce and is considerably more robust than early SSL standards and the open source OpenSSL standard that have caused so much trouble.

Taken together, the DROWN flaws could allow a remote attacker to bypass security restrictions. “By using a server that supports SSLv2 and EXPORT cipher suites. . . an attacker could exploit this vulnerability to decrypt TLS sessions between clients and non-vulnerable servers,” IBM says in its security bulletin. Three of the individual DROWN flaws carry CVSS base scores of 7.4, indicating a potent threat.

TLS is the latest and most secure version of Secure Sockets Layer (SSL) encryption protocol standard that has been in use for decades. Following the critical Heartbleed vulnerabilities in OpenSSL that were disclosed in 2014 and additional flaws found in SSL version 3, organizations across the world were encouraged to upgrade their encryption capabilities to TLS.

With DROWN making headlines across the security world, experts are emphasizing the need to disable SSL version 2, which was first released in 1995 and has long been obsolete. Ivan Ristic, a security researcher with the security software company Qualys, explains the complexity of the DROWN problem.

“The especially bad aspect of this attack is that it can be used to exploit TLS, even in cases when client devices don’t support SSL v2, and sometimes even in cases when the servers don’t support SSL v2 (but use the same RSA key as some other server that does),” Ristic says in a March 1 blog post. “The researchers estimate that up to 22 percent of servers could be impacted by this problem.”

It is unclear how the DROWN or SLOTH vulnerabilities might impact third-party products in the IBM i ecosystem. Emulators and managed file transfer (MFT) tools tend to use these protocols fairly extensively to encrypt remote communications with the server. It’s likely that if IBM is patching these problems in its IBM i products, that the exposures exist elsewhere too, which means IBM i shops should contact their vendors to see if patches might be coming down the pike.

In any event, the lesson to remember is that obsolete cryptography is dangerous. “For many years the argument for not disabling SSL v2 was that there was no harm because no browsers used it anyway,” Ristic says. “This approach is obviously not working. Instead, in the future we must ensure that all obsolete crypto is aggressively removed from all systems. If it’s not, it’s going to come back to bite us, sooner or later.”

Table of Contents

Recent Posts

Subscribe

Pages

Search