Analysis of Java Exploit CVE-2013-2460

Lately I’ve been looking very much into the Java Security model as the news coverage is quite excessive since September 2012. Today I took a closer look at  issue CVE-2013-2460.

In principle these exploits all work more or less in the same way. Usually, they come in the form of an applet that can be easily delivered to the possible victims with a web site.  These applets now try to break the sandboxing security model of Java. In order to do this, they use functionality of the JCL that is not properly checked. These in turn provide access to security critical functionality that is used to break applet encapsulation. We call them “Confused Deputies” with respect to the definition of Norm Hardy.

In CVE-2013-2460, these are calls to java.lang.reflect.InvocationHandler, which is an interface.  The used instance has the concrete type sun.tracing.NullProvider, but the interesting method is implemented in its superclass sun.tracing.ProviderSkeleton.

Here, the method Method.invoke is called. This method does not implement any checks whether a public method should be invoked. Therefore, also security critical, caller-sensitive methods can be called with this proxy.

This was actually fixed after Java 7u21 with the following lines:

Class localClass = paramMethod.getDeclaringClass();
if ((localClass == Provider.class) || (localClass == Object.class))

Using this vulnerability three classes are being loaded:

They are then being used to create objects of the type MethodHandle that point to the following methods:


To get this to work, the exploit is using a very mean trick…

Using the InvocationHandler the method MethodHandles.lookup is called. This leaks a reference to the class Lookup, which also falls under the Confused Deputy category.

This class is somehow infamous for such nice implementations as this: 

/* Obtain the external caller class, when called from Lookup.<init> or
*  a first-level subroutine. */
private static Class<?> getCallerClassAtEntryPoint(boolean inSubroutine) {
final int CALLER_DEPTH = 4;

// Stack for the constructor entry point (inSubroutine=false):
//   0: Reflection.getCC, 1: getCallerClassAtEntryPoint,
//   2: Lookup.<init>, 3: MethodHandles.*, 4: caller
// The stack is slightly different for a subroutine of a
// Lookup.find* method:
//   2: Lookup.*, 3: Lookup.find*.*, 4: caller
// Note:  This should be the only use of getCallerClass in this file.

assert(Reflection.getCallerClass(CALLER_DEPTH-2) == Lookup.class);
assert(Reflection.getCallerClass(CALLER_DEPTH-1) == (inSubroutine ? Lookup.class : MethodHandles.class));
return Reflection.getCallerClass(CALLER_DEPTH);

And just this small and benign looking return statement in the last line of code is spreading the misery here. It SHOULD return the calling class but in fact is returning sun.tracing.ProviderSkeleton in this case…

Which is of course highly privileged… Red Alert!

Then the usual stuff happens… A fresh ClassLoader is used to load and create a class from a byte array, that of course includes some highly miserable code, namely:


That loaded class of course is privileged as the ProviderSkeleton itself is. The SecurityManager is then disabled and disaster may begin…

You will find the code for this exploit as well as other exploits in the Java Exploit Library I am maintaining with Johannes Lerch.

Also, here is a very interesting report on the exploit provided by Security Explorations, a Polish team concerned with Java security since 2002.