IBM Issues More POODLE Patches, Warns Not to Use SSLv3
December 9, 2014 Alex Woodie
IBM i shops that continue to use SSLv3 to encrypt their communications are susceptible to the POODLE security vulnerability and could have their data compromised, IBM warned today in a security bulletin. IBM also issued new security patches that disable SSLv3 in IBM i’s Java runtime. While IBM recommends moving to the newer TLS protocol, many IBM i applications still require SSLv3 and will likely break when it’s disabled, IBM warns. IBM started patching its various systems against the POODLE vulnerability over a month ago when it became clear that SSLv3 needed to go. Applications patched in November include the Apache-based HTTP server, WebSphere Application Server, and Domino, which was upgraded for the first time to support TLS, a newer and more secure encryption protocol for protecting data in motion. POODLE, which stands for “Padding Oracle On Downgraded Legacy Encryption,” is a man-in-the-middle attack that was first spotted by a group of Google researchers in September. If successfully executed, the POODLE attack enables hackers to decrypt messages encrypted with SSLv3. The big news with today’s round of security PTFs is the removal of SSLv3 from the Java runtime. Once the patches are applied, SSLv3 will be disabled in the IBM i runtime for Java 6 and Java 7 (product numbers 5760-JV1 and 5770-JV1). Programmers can take steps to re-enable SSLv3 by making a simple configuration change. But in doing so, they should be fully cognizant that they are running their systems with a known security vulnerability. IBM did not take this approach lightly, explains Tim Rowe, the IBM i business architect for application development and systems management. “We’re very conscious about ensuring backwards compatibly and not breaking things, he tells IT Jungle. “With this particular vulnerability, the IBM i … Java team determined the best course of action was to change the default behavior of Java to not use SSLv3–the rationale being, if you use it, you’re vulnerable. It’s better to ensure there’s no vulnerability, and force the user to explicitly turn it back on.” There’s nothing that says you can’t continue to use SSLv3, Rowe says. “There’s nothing that says it won’t continue to work. But it’s more along the lines of, you’re exposed,” he says. “What is the real exposure? Somebody has to execute a POODLE attack, which is not exactly trivial. But nonetheless, there’s a potential exposure and if you need, for whatever business reasons, to continue to use SSLv3 it will be upon you to enable that specifically for the application you require that for.” Some IBM i shops may choose to continue to use SSLv3 after discovering that their applications require it and won’t work without it. The protocol was first made available over a decade ago and, while there are newer and more security protocols like TLS, SSLv3 is still widely used and supported in Web applications. IBM i shops will need to examine their own systems to determine where their SSLv3 dependencies are and whether it’s worth making an exception to continue to run SSLv3, or whether it’s better to shut the applications down and reconfigure them to use the newer TLS protocol. “Applications will probably break and they won’t work because you’re turning off something they’re dependent upon,” Rowe says. “People need to be aware that they have the ability to get their system set up to be completely compliant and no longer exposed to POODLE. But they’re going to have some work they need to do.” For some applications, avoiding the POODLE vulnerability could be as simple as getting a new TLS certificate and loading it into the system. TLS version 1.2, the latest version of TLS, is supported by default (and SSLv3 is disabled by default) in IBM i version 7.2. TLS is also supported by IBM i 7.1 and 6.1, but older OSes may be dependent on SSLv3 and may not support TLS. Ridding your IBM i server of all traces of SSLv3 takes a bit of work. The protocol exists in operating system configurations and the IBM i Licensed Internal Code (LIC); in the Digital Certificate Manager (DCM) and in APIs. It’s used in the Java and PASE runtimes; in the WebSphere and Apache Web servers; and in the IBM i Access and Access Client Solutions (ACS) products. It’s also used in many third-party providers of file transfer and emulation products. In addition to the Java patches and the security bulletin, IBM is publishing a FAQ about POODLE and will be sharing tips about it on the developerWorks website. Because SSLv3 was used so extensively, IBM wants to be sure that IBM i shops get all the help they need in addressing the problem. Some of the first POODLE patches have been out for over a month. But now that all the POODLE patches are out, IBM is making a big push to let everybody know about the problem and what they can do to fix it. “The biggest thing to make people aware of is there is no fix for SSLv3,” Rowe says. “The fix is, don’t use it.” RELATED STORY IBM And ISVs Fight POODLE Vulnerability In SSL 3.0
|