Sergey Nivens - Fotolia

Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

How did a Java security vulnerability with a bad patch go unnoticed?

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.

Next Steps

Experts recommend faster patch releases from Oracle

Find out why an old Java serialization vulnerability had not been patched

Read about patching practices to prevent bad implementations of Microsoft security updates

This was last published in August 2016

Dig Deeper on Microsoft Patch Tuesday and patch management