Emergency Java Patch Re-Issued for 2013 Vulnerability

Oracle yesterday released an emergency patch for a Java vulnerability that was improperly patched in 2013.

Oracle yesterday released an emergency patch for a Java vulnerability that was improperly patched in 2013.

Researchers at Security Explorations in Poland two weeks ago disclosed that a Java patch for an issue the company reported in 2013, CVE-2013-5838, was still trivially exploitable, and it enabled attackers to remotely execute code and bypass the Java sandbox.

Oracle did not confirm many details in its advisory Wednesday, other than to urge users to patch immediately since details on the flaw were publicly available. Java SE 7 Update 97 and Java 8 Update 73 and 74 for Windows, Mac OS X, Linux and Solaris are vulnerable, Oracle said. Security Explorations founder Adam Gowdiak told Threatpost today that the patch correctly addressed the flaw.

“We ran our POC code and found out that it stopped working. We don’t expect the patch to be broken again as Oracle is now aware of our modified disclosure policy,” he said.

Security Explorations released the details in a paper and during a talk at the JavaLand conference. The public disclosures, Gowdiak said, reflect a new policy for the company around broken patches for vulnerabilities it discloses to vendors.

“If an instance of a broken fix for a vulnerability we already reported to the vendor is encountered, it gets disclosed by us without any prior notice,” Gowdiak wrote to the Full Disclosure mailing list.

Gowdiak told Threatpost that the original vulnerability was an insecure implementation of the Reflection API that could be exploited by a class-spoofing attack against the Java virtual machine. Oracle said it backported from the Java Development Kit 8 a patched implementation of the method handles API to address the vulnerability.

The Security Explorations researchers, however, said that a four-character change to the proof-of-concept code sent to Oracle along with the original private disclosure could bypass sandbox protections in Java. “It’s rather easy to exploit” Gowdiak said. “A malicious Java applet needs to be fetched from a custom HTTP (WWW) server. The reason for it is that the server needs to respond with a “Not found” error when a given Java class file is requested for the first time.”

Suggested articles

Discussion

Subscribe to our newsletter, Threatpost Today!

Get the latest breaking news delivered daily to your inbox.