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