An old Java security vulnerability was discovered to have been ineffectually patched. Expert Michael Cobb explains how this happened and what can be done to prevent other bad patches.

An Oracle patch for a Java security vulnerability from nearly three years ago was recently discovered to be bad. How did this bad patch go unnoticed for so long? Is there anything enterprises can do to detect a bad patch like this one?

At the JavaLand conference 2016, Polish security and vulnerability research company Security Explorations presented an exploit for a Java security vulnerability Oracle reported as patched in 2013. Adam Gowdiak, CEO of Security Explorations, published proof-of-concept code showing the fix for the vulnerability he originally found in 2012 was ineffective and could be easily bypassed. The exploit allows a complete Java security sandbox escape in Java SE 7 Update 97, Java SE 8 Update 74 and Java SE 9 Early Access Build 108.

The original Java security vulnerability was tracked as CVE-2013-5838, and was assigned a severity rating of 9.3 out of 10.0 because it could be exploited remotely to control vulnerable systems, without authentication. The vagueness of its CVE description may well hint at why no one realized the Oracle patch didn't fix the problem: "Unspecified vulnerability in Oracle Java SE 7u25 and earlier, and Java SE Embedded 7u25 and earlier, allows remote attackers to affect confidentiality, integrity and availability via unknown vectors related to Libraries."

Patch code is like any other code -- it's written by humans and can contain errors. In 2006, Microsoft had to completely rerelease its critical MS06-042 update, as the original update introduced a new exploitable vulnerability that could allow attackers to run unauthorized software on a victim's PC. Patches which contain bad code are usually discovered quite quickly, as they tend to break or change the expected behavior of certain processes. For example, Microsoft's patch caused browsers to crash when using web-based versions of various applications. Patches that contain security flaws, on the other hand, don't necessarily break any processes and often go unnoticed. However, the Oracle patch didn't include any bugs; it just didn't fix the problem.

As the source code for most patches is proprietary, it's very difficult for security researchers to analyze what a patch does, how it resolves a particular vulnerability and, most importantly, confirm that it does in fact mitigate it. Comments by Gowdiak imply Oracle created a patch that merely stopped his original exploit code from working, rather than spending time to fully understand the nature of the vulnerability and creating a patch that eradicated it instead of one which prevented only a particular exploit from working. Unless vendors document how a patch mitigates a vulnerability and how end users can verify it works, enterprises will have to blindly trust the patches they install.

Oracle has assigned a new CVE identifier for the Java security vulnerability, CVE-2016-0636, and in March, it released a security alert strongly advising those affected to apply the fixes that were announced, particularly as the technical details of the vulnerability are public; Oracle Java SE 7 Update 97, and 8 Update 73 and 74 for Windows, Solaris, Linux and Mac OS X are affected. As always, it's important to keep operating systems and applications up to date with the latest version and security patches. To keep up to date with the latest JRE security alerts, subscribe to Oracle's Critical Patch Update Alert Emails and RSS feed.

Join the conversation

1 comment

Register

I agree to TechTarget’s Terms of Use, Privacy Policy, and the transfer of my information to the United States for processing to provide me with relevant information as described in our Privacy Policy.

Please check the box if you want to proceed.

I agree to my information being processed by TechTarget and its Partners to contact me via phone, email, or other means regarding information relevant to my professional interests. I may unsubscribe at any time.