Java 7 Zero-Day Possible Because Oracle Didn’t Properly Address Old Vulnerability

Experts from Security Explorations detail the attack vectors

Yesterday, we learned that a new zero-day exploit affecting Java 7 update 10 was identified. According to experts, the zero-day code could not have worked if Oracle had properly addressed an old vulnerability.

Adam Gowdiak, the CEO of Security Explorations – the company that’s responsible for identifying and reporting most of the latest vulnerabilities affecting Java – has told Softpedia in an email that this is another instance of Java vulnerabilities that stem from the insecure implementation of the Reflection API.

According to Gowdiak, the new attack is a combination of two vulnerabilities.

“The first flaw allows to load arbitrary (restricted) classes by the means of findClass method of com.sun.jmx.mbeanserver.MBeanInstantiator class. The problem stems from insecure call to Class.forName() method,” the expert explained.

“The second issue abuses the new Reflection API to successfully obtain and call MethodHandle objects that point to methods and constructors of restricted classes. This second issue relies on invokeWithArguments method call of java.lang.invoke. MethodHandle class, which has been already a subject of a security problem.”

The security problem that Gowdiak is talking about is the one dubbed “Issue 32,” which they reported to Oracle on August 31, 2012.

Oracle released a patch for it in October 2012, but the fix wasn’t complete, allowing an attacker to continue to abuse the invokeWithArguments method to set up calls to invokeExact method with a trusted system class as a target method caller.

“The zero-day code would not work if Issue 32 was properly addressed. The issue can be still abused to call arbitrarily security sensitive methods with a trusted class set as a caller. This allows to bypass certain security checks relying on the caller class (this is the case for both core and new Reflection API),” the researcher noted.

“Also, the zero-day would not work if the exploitation vector relying on DefiningClassLoader class was addressed by Oracle. We sent Oracle additional Proof of Concept code for Issue 32 that illustrated this exploitation vector in Sep 2012,” he added.

“Bugs are like mushrooms, in many cases they can be found in a close proximity to those already spotted. It looks Oracle either stopped the picking too early or they are still deep in the woods,” Gowdiak concluded.

In the meantime, users are advised to disable or uninstall Java from their systems completely if the component is not needed.

Alternatively, Windows customers can turn to a new feature added to Java 7 update 10, designed to warn the user when they’re about to launch untrusted code.

Update. Additional technical details of the flaw have been published on Bugtraq.

Hot right now  ·  Latest news