Sergey Nivens - Fotolia
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.
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
Dig Deeper on Microsoft Patch Tuesday and patch management
Related Q&A from Michael Cobb
Pirated software is still a major concern nowadays. Uncover how to prevent software piracy and protect your organization's intellectual property. Continue Reading
Port scans provide data on how networks operate. In the wrong hands, this info could be part of a larger malicious scheme. Learn how to detect and ... Continue Reading
By performing ongoing risk assessments, organizations can keep their SSH vulnerabilities at a minimum and ensure their remote access foundation is ... Continue Reading