Java’s miserable 2013 just will not go away.
One of the endless parade of bugs found in the platform throughout 2013—many of which were zero-day vulnerabilities exploited in targeted attacks—apparently wasn’t closed off completely by an October 2013 patch released by Oracle.
Researchers at Polish security company Security Explorations last week disclosed that Oracle’s patch for CVE-2013-5838, which the company privately disclosed in July 2013, could be trivially sidestepped resulting in a Java sandbox bypass.
A request for comment from Oracle as to whether it has confirmed the bypass and what its plans are for an updated patch were not returned in time for publication.
Security Explorations founder and CEO Adam Gowdiak said he has not been contacted by Oracle since last week’s disclosure. Gowdiak not only released his findings on the Full Disclosure mailing list, but also at the JavaLand conference; he told Threatpost that Oracle representatives were speakers at the event and hosted a booth in the expo hall.
“They should [fix this], but it’s hard to speculate on whether and when this will happen,” Gowdiak said.
The public disclosure, Gowdiak said, is a reflection of his company’s new policy around broken fixes.
“As a result, we do not tolerate broken fixes any more,” Gowdiak wrote in an email to the Full Disclosure list. “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 said that the original vulnerability and 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 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.”
Gowdiak said that the new attack was verified in Java SE 7 Update 97, Java SE 8 Update 74, and Java SE 9 Early Access Build 108. Gowdiak added that the attack does not bypass updated Java security levels or Java Click2Play, which prevents the automatic execution of unsigned Java applets.
Gowdiak also said that Oracle downplayed the potential impact of the vulnerability, that it could be exploited only through sandboxed Java Web Start applications and sandboxed Java applets.
“This is not true,” Gowdiak said. “We verified that it could be successfully exploited in a server environment as well such as Google App Engine for Java.”