[SE-2012-01] 'Fix' for Issue 32 exploited by new Java 0-day code

Type securityvulns
Reporter Securityvulns
Modified 2013-01-14T00:00:00


Hello All,

We were notified today of ongoing attacks with the use of a new Java vulnerability affecting latest version 7 Update 10 of the software [1][2].

Due to the unpatched status of Issue 50 [3] and some inquiries received regarding whether the attack code found exploited this bug, we had a quick look at the exploit code found in the wild. Below, we are providing you with the results of our analysis.

The 0-day attack code that was spotted in the wild today is yet another instance of Java security vulnerabilities that stem from insecure implementation of Reflection API [4].

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. This can be accomplished by the means of this code:

public static Class loadClass(String name) throws Throwable { JmxMBeanServerBuilder jmxbsb=new JmxMBeanServerBuilder(); JmxMBeanServer jmxbs=(JmxMBeanServer)jmxbsb.newMBeanServer("",null,null); MBeanInstantiator mbi=jmxbs.getMBeanInstantiator();

return mbi.findClass(name,(ClassLoader)null);


The problem stems from insecure call to Class.forName() method.

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 (Issue 32 that we reported to Oracle on Aug 31, 2012).

The company had released a fix for Issue 32 in Oct 2012. However, it turns out that the fix was not complete as one can still abuse invokeWithArguments method to setup calls to invokeExact method with a trusted system class as a target method caller. This time the call is however done to methods of new Reflection API (from java.lang.invoke.* package), of which many rely on security checks conducted against the caller of the target method.

Oracle's fix for Issue 32 relies on a binding of the MethodHandle object to the caller of a target method / constructor if it denotes a potentially dangerous Reflection API call. This binding has a form of injecting extra stack frame from a caller's Class Loader namespace into the call stack prior to issuing a security sensitive method call. Calls to blacklisted Reflection APIs are detected with the use of isCallerSensitive method of MethodHandleNatives class. The blacklisting however focuses primarily on Core Reflection API (Class.forName(), Class.getMethods(), etc.) and does not take into account the possibility to use new Reflection API calls. As a result, the invokeWithArguments trampoline used in the context of a system (privileged) lookup object may still be abused for gaining access to restricted classes, their methods, etc.

The above is important in the context of a security check that is implemented by the Lookup class. Its checkSecurityManager method compares the Class Loader (CL) namespace of the caller class of a target find[*] method (findStatic, findVirtual, etc.) with the CL namespace of a class for which a given find operation is conducted. Access to restricted packages is not checked only if Class Loader namespaces are equal (the case for public lookup object, but also for a trusted method caller such as invokeWithArguments invoked for not blacklisted method).

The exploit vector used by the attack code is the same as the one we used for second instance of our Proof of Concept code for Issue 32 (reported to Oracle on 17-Sep-2012). This exploit vector relies on sun.org.mozilla.javascript.internal.GeneratedClassLoader class in order to define a fully privileged attacker's class in a system Class Loader namespace. From that point all security checks can be easily disabled.

This is not the first time Oracle fails to "sync" security of Core and new Reflection APIs. Just to mention the Reflection API filter.

This is also not the first time Oracle's own investigation / analysis of security issues turns out to be not sufficiently comprehensive. Just to mention Issue 50, which was discovered in the code addressed by the company not so long ago...

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...

Thank you.

Best Regards Adam Gowdiak

Security Explorations http://www.security-explorations.com "We bring security research to the new level"

References: [1] Malware don't need Coffee: 0 day 1.7u10 spotted in the Wild - Disable Java Plugin NOW !

http://malware.dontneedcoffee.com/2013/01/0-day-17u10-spotted-in-while-disable.html [2] New year, new Java zeroday!

http://labs.alienvault.com/labs/index.php/2013/new-year-new-java-zeroday/ [3] [SE-2012-01] Critical security issue affecting Java SE 5/6/7 http://seclists.org/fulldisclosure/2012/Sep/170 [4] SE-2012-01 Details http://www.security-explorations.com/en/SE-2012-01-details.html