Understanding ASLR on Android ARM64

Address Space Layout Randomization (ASLR) is a fundamental security feature designed to prevent memory corruption vulnerabilities from being reliably exploited. By randomizing the base addresses of key memory regions—such as the executable, libraries, heap, and stack—ASLR makes it difficult for an attacker to predict the location of essential gadgets or data structures required for an exploit. On Android ARM64, ASLR is robust, providing high entropy for shared libraries and the executable, making brute-force attacks impractical.

However, ASLR is not an impenetrable shield. Its effectiveness hinges on the inability of an attacker to obtain information about the randomized memory layout. The primary goal of an ASLR bypass is to leak the base addresses of loaded modules (like libc.so, linker, or the application’s executable) and then use these leaked addresses to calculate the precise locations of desired functions or ROP gadgets.

The Challenge of Information Leaks on Android

Android’s security model, coupled with specific ARM64 architectural nuances, introduces unique challenges for ASLR bypass:

• High Entropy: Modern Android versions on ARM64 typically use 28-32 bits of entropy for randomization, making brute-forcing an executable’s base address infeasible within practical timeframes.
• No /proc/self/maps for Non-Root: Unlike Linux, regular unprivileged Android applications cannot access their own /proc/self/maps, severely limiting an attacker’s ability to enumerate memory regions without an information leak.
• Position-Independent Executables (PIE): All executables on Android are PIE, meaning their code can be loaded at any address. This is a crucial defense against memory corruption, as it randomizes the executable’s base address, similar to shared libraries.
• Strict SELinux Policies: SELinux policies can restrict what an application can access, potentially hindering attempts to create or modify certain files that might aid in exploitation.

Despite these defenses, vulnerabilities that lead to information leaks remain the most common path to ASLR bypass.

Primary Information Leakage Vectors

1. Format String Vulnerabilities

Format string bugs in functions like printf, sprintf, or snprintf allow an attacker to read arbitrary data from the stack or even arbitrary memory locations by manipulating format specifiers (e.g., %p, %x). This is a classic and highly effective technique for leaking addresses.

Consider a vulnerable C function:

#include <stdio.h> #include <string.h> void vulnerable_function(char *input) { char buffer[256]; strncpy(buffer, input, sizeof(buffer) - 1); buffer[sizeof(buffer) - 1] = '
'; printf(buffer); // Format string vulnerability } int main(int argc, char **argv) { if (argc < 2) { printf("Usage: %s <input_string>n", argv[0]); return 1; } vulnerable_function(argv[1]); return 0; }

If we provide an input like "AAAA%p.%p.%p.%p.%p.%p", the printf function will interpret %p as format specifiers, printing pointers from the stack. One of these pointers will inevitably be a return address or a saved register value pointing into a loaded library or the executable. By carefully identifying the stack offset to these pointers, we can extract leaked addresses.

Example Leakage Command (conceptual):

adb shell "./vulnerable_app 'AAAA%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p'"

The output will contain a series of hexadecimal addresses. An attacker would look for addresses that fall within typical memory ranges for libraries (e.g., 0x7xxxxxxxxx on ARM64 Android) and then identify which library they belong to based on their relative offset.

2. Heap Leaks (Use-After-Free, Heap Overflows)

Heap vulnerabilities, particularly Use-After-Free (UAF) or heap overflows, can be exploited to disclose pointers. When a chunk of memory is freed, its metadata or surrounding chunks might contain pointers to other heap allocations or even internal library structures. If an attacker can reallocate a chunk in the same location and control its content, or read from a dangling pointer, they can leak these sensitive addresses.

Scenario: A UAF vulnerability allows an attacker to free a chunk, then reallocate it with controlled data, and finally read the content using the dangling pointer. If the original chunk contained pointers to libc.so functions (e.g., function pointers stored in a C++ vtable or internal callbacks), these can be leaked.

3. Uninitialized Memory Leaks

Sometimes, an application might allocate memory but fail to initialize it before returning it to the user or writing it to a log. This uninitialized memory might contain remnants of previous allocations, including pointers to other parts of the memory space or data from other processes, which can sometimes include library base addresses.

Practical ASLR Bypass Workflow on Android ARM64

Step 1: Identify Leakage Primitive

The first step is always to find a vulnerability that allows for reading arbitrary data from memory or the stack. This is the