Introduction to ART JIT Exploitation

The Android Runtime (ART) is the managed runtime used by the Android operating system and its applications. Introduced in Android 4.4 KitKat and becoming the default in Android 5.0 Lollipop, ART replaced Dalvik. A core component of ART is its Just-In-Time (JIT) compiler, which dynamically compiles frequently executed bytecode into native machine code to improve performance. While enhancing user experience, the JIT compiler also introduces a new and powerful attack surface for adversaries.

Exploiting the ART JIT involves understanding how the runtime handles types, memory, and optimizes code. Two fundamental techniques in this realm are type confusion and heap spraying. Mastering these allows attackers to manipulate program execution flow, achieve arbitrary read/write primitives, and ultimately gain code execution within the sandbox of an Android application or even the system itself.

Understanding ART and the JIT Compiler

ART primarily uses Ahead-Of-Time (AOT) compilation during app installation, but it also employs a JIT compiler. The JIT compiler monitors running applications, identifies ‘hot’ methods (those executed frequently), and compiles them into highly optimized native code. This compilation happens dynamically, often introducing complex optimizations that can lead to subtle vulnerabilities if not handled with extreme care.

How JIT Compilation Works

• Profiling: ART tracks method execution counts and identifies performance-critical code paths.
• Tiered Compilation: Initially, methods might be interpreted or compiled with a ‘quick’ JIT compiler. If deemed hot enough, a more optimizing JIT compiler processes them.
• Deoptimization: If assumptions made during optimization prove incorrect (e.g., due to polymorphic calls or type changes), the code can deoptimize back to interpretation.

The JIT compiler, operating on dynamic runtime information, makes assumptions about types and object layouts. Errors in these assumptions, especially when combined with malicious input or specific program states, can be leveraged for exploitation.

The Attack Surface: Type Confusion in JIT Compilers

Type confusion occurs when a program accesses a resource (e.g., an object in memory) using a type that is incompatible with the resource’s actual type. In the context of a JIT compiler, this can happen if the compiler makes an incorrect assumption about the type of an object during optimization, leading to generated native code that misinterprets memory. For example, treating an integer as an object pointer, or an object of type A as an object of type B.

Manifestation and Exploitation of Type Confusion

Consider a scenario where the JIT compiler, due to some optimization, incorrectly believes a variable holds an instance of `ClassA` when it actually holds `ClassB`. If `ClassA` and `ClassB` have different memory layouts (e.g., `ClassA` has fewer fields or fields of different types at the same offset), accessing a field of `ClassA` could inadvertently read or write to an adjacent object’s memory or even control data structures.

Let’s illustrate with a simplified Java-like pseudo-code example:

class ClassA { int field1; long field2; }class ClassB { String field1; int field2; int field3; }public void vulnerableMethod(Object obj, boolean condition) {    if (condition) {        obj = new ClassA();    }    // JIT might assume 'obj' is always ClassA after optimization due to 'condition' logic    // but if 'obj' was previously ClassB and 'condition' is false, a type confusion arises.    // This is a simplified conceptual example; real vulnerabilities are more subtle.    long value = ((ClassA) obj).field2;    // If obj was ClassB, 'field2' of ClassA would overlap with 'field2' or 'field3' of ClassB    // potentially leading to reading an unintended memory location or even an object pointer.    System.out.println(value);}

A successful type confusion primitive often allows an attacker to achieve arbitrary read and write capabilities, which are crucial steps towards arbitrary code execution. For instance, misinterpreting an object pointer as an integer could allow writing an arbitrary value to an arbitrary address if the integer is later used as an address in an instruction.

Heap Spray Techniques for JIT Exploits

Heap spraying is a technique used to reliably place specific data (often exploit payloads or controlled object layouts) at predictable memory locations within the heap. This is critical for JIT exploits because type confusions or other memory corruption vulnerabilities often rely on the corrupted object being adjacent to or overlapping with attacker-controlled data.

Why Heap Spraying is Essential

In a JIT context, heap spraying serves several purposes:

• Predictable Layouts: It helps ensure that when a vulnerable object is allocated, it is surrounded by or overlaps with objects whose contents are controlled by the attacker.
• Bypassing ASLR: While not fully bypassing ASLR on its own, a massive heap spray can increase the probability of landing a payload in a known, reachable address space if an information leak is absent.
• Controlling Data: Placing large amounts of controlled data on the heap. This could be fake object headers, vtables, or shellcode.

Methods of Heap Spraying in ART

In Android and ART, heap spraying typically involves allocating a large number of objects of a specific size. This can be done by repeatedly creating instances of a class with fields designed to occupy a desired memory footprint.

// Example Java code for a simple heap spraypublic class HeapSprayer {    private static final int SPRAY_COUNT = 100000; // Number of objects to spray    private static final int PAYLOAD_SIZE = 1024; // Size of each payload in bytes    public static Object[] sprayObjects;    public static void performSpray() {        sprayObjects = new Object[SPRAY_COUNT];        for (int i = 0; i < SPRAY_COUNT; i++) {            // Create an object with a specific size.            // This could be a byte array, or an instance of a custom class            // designed to have a certain memory footprint.            sprayObjects[i] = new byte[PAYLOAD_SIZE]; // Each byte array is 1KB            // Fill the byte array with attacker-controlled data (e.g., a known pattern, fake pointers)            for (int j = 0; j < PAYLOAD_SIZE; j++) {                ((byte[]) sprayObjects[i])[j] = (byte) (j % 256);            }        }        System.out.println("Heap spray completed with " + SPRAY_COUNT + " objects.");        // To prevent garbage collection, hold references to the sprayed objects    }}

By repeatedly calling `new byte[PAYLOAD_SIZE]`, an attacker can fill the heap with many objects of a predictable size and content. When a vulnerable object is allocated, it might land within this controlled