Two Year Old Java Vulnerability Reappeared Thanks to Broken Patch
Alexander Neil / 3 years ago
Back in 2013, Oracle released a patch for a critical security flaw in Java. Now it has been found that this patch was ineffectual and easily bypassed, once again making PCs and servers running even the latest version of Java vulnerable to it.
The tracking code for this flaw in the Common Vulnerabilities and Exposures (CVE) database was CVE-2013-5838 and managed to be rated at 9.3 out of 10 by Oracle according to the Common Vulnerability Scoring System (CVSS). This vulnerability allows attackers to escape from the Java security sandbox that usually limits the code that can be run in a Java virtual machine using the Java Runtime Environment. Able to be utilized remotely without authentication allows attackers to totally compromise a target system.
Now, researchers at Security Explorations discovered that the patch used to fix the vulnerability was majorly flawed, with the proof-of-concept code from 2013 requiring a change of only 4 characters in order to bypass it. The full details of the ability to bypass the patch were documented in a full technical report released by Security Explorations.
The versions of Java affected by this flaw include all of the latest versions: Java SE 7 Update 97, Java SE 8 Update 74 and Java SE 9 Early Access Build 108. Additionally, Oracle’s original advisory stating that CVE-2013-5838 only affected client deployments of Java and is exploited through “sandboxed Java Web Start applications and sandboxed Java applets.” Security Explorations CEO Adam Gowdiak explained that this was incorrect, stating that “We verified that it could be successfully exploited in a server environment as well as in Google App Engine for Java.”
While attackers would still require an additional vulnerability in order to bypass the security prompts that feature in newer versions of Java, it is easily possible that victims could be convinced to allow the malicious applet to run.
Unlike many firms, Security Explorations did not report the issue to Oracle prior to releasing it publicly. Gowdiak stated that “We do not tolerate broken fixes any more,” and that there would be full public releases whenever broken vulnerability fixes are found. Oracle are yet to respond to the report, with it currently unknown if an emergency update will occur to patch the issue, or whether it will remain in place until the next quarterly Critical Patch Update, on April 19.