Introduction to Kernel Exploitation and Heap Spraying on Android

Android’s robust security model relies heavily on the kernel to enforce isolation and protect critical system resources. However, vulnerabilities within the Linux kernel, particularly those leading to memory corruption, can severely compromise this security. Use-After-Free (UAF) is a notorious class of memory corruption bug where a program attempts to use memory after it has been freed. In the kernel context, a UAF can lead to data manipulation, privilege escalation, or even full system compromise. While discovering a UAF is a critical first step, reliably exploiting it often requires a technique called heap spraying. This article delves into the intricacies of heap spraying on Android, focusing on how to build reliable primitives to exploit kernel UAF vulnerabilities.

Understanding Use-After-Free (UAF) in the Kernel

A Use-After-Free vulnerability occurs when an object is freed, but a pointer to that object remains in active use. If the kernel attempts to access the freed memory region via this dangling pointer, and that memory has been reallocated for a different purpose, the kernel will operate on invalid or unexpected data. This can manifest in several ways:

• Data Corruption: Overwriting critical kernel data structures, potentially leading to system instability or security bypasses.
• Arbitrary Read/Write Primitives: If the reallocated object contains controllable data, the UAF can be leveraged to read from or write to arbitrary kernel memory addresses.
• Control Flow Hijacking: By overwriting function pointers or object vtables (in C++ kernel modules), an attacker can redirect execution to arbitrary code.

The challenge in exploiting UAF reliably lies in controlling what data replaces the freed memory region. This is where heap spraying becomes indispensable.

The Role of Kernel Heap Spraying

Kernel heap allocators, such as SLAB, SLUB, and page allocators, are designed for efficiency and speed. When memory is freed, it doesn’t immediately become zeroed or inaccessible; it’s often returned to a free list within the allocator. The next allocation request of a compatible size might reuse this freed block. The exact block chosen is often non-deterministic, depending on various factors like system load, concurrent allocations, and allocator internal logic. This non-determinism makes direct exploitation of a UAF difficult because the attacker cannot guarantee that their malicious data will occupy the freed UAF object’s memory.

Heap spraying addresses this by flooding the kernel heap with numerous objects of a specific size, significantly increasing the probability that one of these controlled objects will occupy the memory region freed by the UAF. The primary goals of heap spraying are:

• Reliable Re-allocation: To ensure that the freed UAF object’s memory is reallocated with attacker-controlled data.
• Controlling Contents: To place specific, crafted data at the address of the UAF object, allowing for exploitation.
• Predictable Behavior: To make an otherwise non-deterministic exploitation path more reliable.

Common Kernel Objects for Heap Spraying on Android

To perform kernel heap spraying, an attacker needs a method to allocate numerous kernel objects of a specific size from user-space. Several kernel mechanisms provide this capability:

• msg_msg Objects (Message Queues): The Linux message queue (msgget, msgsnd) mechanism is a prime candidate for heap spraying. When a message is sent via msgsnd, the kernel allocates a struct msg_msg and a buffer for the message data. Critically, the size of the data buffer is user-controlled, allowing an attacker to allocate arbitrary sizes on the kernel heap. This flexibility makes msg_msg an extremely powerful spraying primitive.
• pipe_buffer Objects (Pipes): Creating and writing to pipes (pipe, write) allocates struct pipe_buffer objects in the kernel. While useful, these often allocate objects of fixed sizes (typically page-sized chunks or smaller, depending on kernel configuration), which might not perfectly match the target UAF object’s size.
• ioctl with Custom Structures: If a vulnerable kernel driver exposes ioctl commands that allocate kernel memory based on user-provided sizes or data, these can also be used. However, this relies on finding such a driver-specific primitive.
• Netlink Sockets: Netlink sockets can also be used to send and receive messages of user-defined sizes, similar to msg_msg, offering another flexible spraying option.

For its flexibility in controlling allocation size, msg_msg is often the preferred choice for sophisticated kernel heap sprays.

Crafting a Heap Spray Primitive with msg_msg

Let’s consider a scenario where a UAF occurs on a kernel object of size `X`. To exploit this, we want to spray `msg_msg` objects whose data buffer size matches `X`. The msg_msg structure itself takes up some kernel memory (typically 48-64 bytes on 64-bit systems), plus the user-provided data. Therefore, if our target UAF object size is `TARGET_SIZE`, we would send a message of length `TARGET_SIZE – sizeof(struct msg_msg)` (approximately). This ensures that the entire kernel memory chunk allocated for the message (including the msg_msg header and data buffer) is roughly `TARGET_SIZE`. By sending many such messages, we fill the heap with our controlled data.

Here’s a simplified C code example demonstrating how to create message queues and send messages of a specific size for heap spraying:

#include <stdio.h> #include <stdlib.h> #include <string.h> #include <sys/ipc.h> #include <sys/msg.h> #include <sys/types.h> #include <unistd.h> #define NUM_QUEUES 1000 #define MESSAGE_SIZE 1024 // Example target UAF object size #define SPRAY_MAGIC 0x4141414141414141UL struct spray_msg { long mtype; char mtext[MESSAGE_SIZE]; }; int main() { int msqids[NUM_QUEUES]; struct spray_msg msg; // Fill message with spray data for target object memset(msg.mtext, 0x41, MESSAGE_SIZE); // For example, fill with 'A's *(unsigned long *)&msg.mtext[0] = SPRAY_MAGIC; // A distinct marker *(unsigned long *)&msg.mtext[8] = SPRAY_MAGIC; // More distinct markers msg.mtype = 1; // Message type can be arbitrary for spraying printf("[*] Starting kernel heap spray with %d messages of size %dn", NUM_QUEUES, MESSAGE_SIZE); for (int i = 0; i < NUM_QUEUES; i++) { msqids[i] = msgget(IPC_PRIVATE, 0666 | IPC_CREAT); if (msqids[i] == -1) { perror("msgget failed"); return 1; } // Send message. MSG_NOERROR prevents truncation if message is too long, though we control size here. if (msgsnd(msqids[i], &msg, sizeof(msg.mtext), 0) == -1) { perror("msgsnd failed"); // On failure, attempt to clean up created queues for (int j = 0; j < i; j++) msgctl(msqids[j], IPC_RMID, NULL); return 1; } } printf("[*] Heap spray completed. %d message queues created and messages sent.n", NUM_QUEUES); printf("    These messages are now occupying kernel heap memory.n"); // At this point, you would trigger the UAF, // hoping the freed object's memory is re-allocated by one of our sprayed messages. // The message queues (msqids) must be kept alive until the UAF is triggered and exploited. // To clean up: // for (int i = 0; i < NUM_QUEUES; i++) { // msgctl(msqids[i], IPC_RMID, NULL); // } return 0; } 

In this code, we create `NUM_QUEUES` message queues and send a message of `MESSAGE_SIZE` to each. The `mtext` buffer is filled with ‘A’s and a `SPRAY_MAGIC` value. If a UAF occurs on an object of `MESSAGE_SIZE`, the kernel’s allocator is highly likely to reuse one of these sprayed message buffers for the freed UAF object.

Exploiting UAF with the Spray

The typical exploitation sequence for a kernel UAF using heap spraying is:

1. Trigger UAF: Cause the kernel to free an object while retaining a dangling pointer to it.
2. Spray the Heap: Execute the heap spraying primitive (e.g., using the `msg_msg` code above) to fill the kernel heap with attacker-controlled data. The goal is to ensure that the memory formerly occupied by the UAF object is now filled by one of your sprayed objects.
3. Trigger Use: Cause the kernel to dereference the dangling pointer to the UAF object. Because the memory is now occupied by your sprayed data, the kernel will operate on your data.

If the sprayed data contains crafted values at specific offsets (e.g., a fake object structure, function pointers, or arbitrary values), the UAF can be transformed into a powerful primitive, such as arbitrary kernel read/write or direct control flow hijacking, leading to full kernel compromise.

Mitigations and Future Challenges

Modern Android kernels incorporate various mitigations against UAF and other memory corruption vulnerabilities, including KASLR (Kernel Address Space Layout Randomization), CFI (Control Flow Integrity), and stricter memory management policies. While these make exploitation harder, sophisticated heap spraying techniques combined with information leaks can often bypass KASLR, and careful crafting of arbitrary read/write primitives can sometimes circumvent CFI. Developers continue to improve these defenses, making the cat-and-mouse game of exploitation and mitigation an ongoing challenge.

Conclusion

Heap spraying is a fundamental technique in Android kernel exploitation, offering a critical bridge between identifying a Use-After-Free vulnerability and reliably exploiting it. By understanding kernel heap allocators and mastering primitives like `msg_msg` objects, attackers can deterministically overwrite freed kernel objects with controlled data, transforming complex UAFs into exploitable primitives for privilege escalation. As kernel security evolves, so too will the methods of exploitation, but the core principles of heap manipulation remain central to this field.