Android Mobiles Showcase

Author: admin

  • From Permissive to Pwned: A Step-by-Step Guide to Android SELinux Bypass Techniques

    Introduction to Android SELinux and Its Importance

    Security-Enhanced Linux (SELinux) is a mandatory access control (MAC) system that enhances the traditional discretionary access control (DAC) model of Linux. On Android, SELinux plays a critical role in sandboxing applications, protecting system services, and enforcing resource isolation. Introduced in Android 4.3 and enforcing since 4.4 KitKat, it operates at the kernel level, defining granular permissions for processes, files, and other resources. Unlike DAC, where permissions are decided by the owner, SELinux policy is defined system-wide, making it a formidable barrier for attackers.

    However, even the most robust security mechanisms can have weaknesses. This guide delves into various advanced techniques used to bypass Android SELinux policies, moving beyond the simple ‘permissive’ mode exploits to more sophisticated attacks that target policy misconfigurations, kernel vulnerabilities, or logical flaws in system services. Understanding these bypasses is crucial for both offensive security researchers and developers striving to build more secure Android systems.

    Understanding SELinux Policy: A Prerequisite

    Before attempting to bypass SELinux, it’s essential to understand its core components:

    • Subjects (Domains): Processes running with a specific SELinux context (e.g., untrusted_app, system_server).
    • Objects (Types): Files, directories, sockets, devices, and other resources (e.g., system_file, app_data_file).
    • Permissions (Classes/Access Vectors): Specific actions a subject can perform on an object (e.g., read, write, execute).

    SELinux policy rules dictate what interactions are allowed. For example, a rule might state: allow untrusted_app system_file:file { read getattr };. Bypass techniques often involve finding ways to perform an action not explicitly allowed by the policy, or tricking a more privileged domain into performing an action on our behalf.

    # Example: Check current SELinux status and policy loadedpidof init | xargs ls -l /proc/*/attr/currentcat /sys/fs/selinux/enforce

    Technique 1: Exploiting Permissive Domains or Services

    While a fully enforcing SELinux system is difficult to bypass, misconfigured devices or specific development builds might run certain services or even the entire system in ‘permissive’ mode. In permissive mode, denied actions are logged but not prevented. An attacker can use this to probe the system, identify forbidden actions, and potentially elevate privileges once enforcement is re-enabled, or if the permissive state is temporary. More commonly, specific domains might be permissive to facilitate debugging or legacy app compatibility.

    Steps to Identify and Exploit Permissive Domains:

    1. Check Global Enforcing Status:adb shell 'getenforce' If it returns ‘Permissive’, congratulations, a significant barrier is down.
    2. Identify Permissive Domains:adb shell 'for pid in $(ls /proc | grep -E "^[0-9]+"); do cat /proc/$pid/attr/current 2>/dev/null; done | sort | uniq -c | grep "_permissive"' Look for domains like init_permissive or service-specific permissive contexts.
    3. Target Permissive Services: If a critical service (e.g., a system server, a privileged daemon) runs in a permissive domain, an attacker might be able to interact with its files or IPC channels without SELinux blocking, potentially leading to information disclosure or remote code execution within that service’s context.

    Technique 2: Domain Transition Abuse (Privilege Escalation)

    Domain transition occurs when a process with one SELinux domain executes a program labeled with a different, often more privileged, domain. For instance, an untrusted_app domain might execute a program that transitions it to mediaserver or another specific service domain. If the policy allows an unprivileged domain to execute a program that transitions to a powerful domain, and that program has vulnerabilities (e.g., buffer overflows, command injection), an attacker can achieve privilege escalation.

    Example Scenario: Service Exploitation

    Consider a vulnerable service /system/bin/vulnerable_service labeled vulnerable_service_exec which, when executed, causes a domain transition to vulnerable_service_domain. If untrusted_app is allowed to execute this file and the service itself has a local root vulnerability, the app could trigger the vulnerability after the domain transition.

    # SELinux policy snippet for domain transitionallow untrusted_app vulnerable_service_exec:file { execute getattr read };domain_auto_trans(untrusted_app, vulnerable_service_exec, vulnerable_service_domain);# Attacker's perspective (from an unprivileged app process)execve("/system/bin/vulnerable_service", args, envp);# Inside vulnerable_service_domain, if vulnerable, achieve arbitrary code exec

    Technique 3: Arbitrary File Write/Read Exploits and Labeling

    A common primitive in Android exploits is arbitrary file write or read. While SELinux is designed to prevent these, clever techniques can sometimes bypass it. If an attacker can achieve an arbitrary write to a file that later gets a more privileged label (e.g., a system binary or a configuration file read by a privileged service), they can achieve arbitrary code execution or policy manipulation.

    The Strategy: Target Unlabeled or Mis-labeled Files

    1. Find Writable Locations: Identify directories or files where an unprivileged process can write (e.g., /data/local/tmp if not restricted, temporary files created by services).
    2. Hijack File Context: If a privileged service creates a file in a location controlled by the attacker (e.g., a temporary directory), and the service then changes the file’s SELinux context to a more privileged one (e.g., system_data_file) or if the file is later moved/copied to a privileged location, the attacker can replace the file’s content before the context change/move occurs.
    3. Example: Overwriting a System Binary: If a vulnerability allows writing to /data/local/tmp/myservice_binary and then a system updater service (running in a highly privileged domain) moves this file to /system/bin/myservice_binary, the attacker could inject malicious code. The SELinux policy for the updater would need to permit the write to /system/bin from its domain.
    # Simplified attack flowadb shell 'echo "#!/system/bin/shnecho PWNED > /data/local/pwned.txt" > /data/local/tmp/malicious_script'# Assume vulnerability allows a privileged service to cp /data/local/tmp/malicious_script to /system/bin/privileged_scriptcp /data/local/tmp/malicious_script /system/bin/privileged_script# When privileged_script is executed, the malicious code runs.

    This relies heavily on precise timing and understanding how specific services handle files. The SELinux policy would need to permit the ‘move’ or ‘write’ operation for the privileged service into the target system directory.

    Technique 4: IOCTL Abuse and Device Driver Exploits

    ioctl (Input/Output Control) calls are used by applications to communicate directly with device drivers. Many kernel vulnerabilities reside within these drivers. If an unprivileged application can call a vulnerable ioctl on a device node it has access to (e.g., /dev/binder, /dev/kgsl-3d0), it can trigger a kernel vulnerability, leading to kernel arbitrary read/write, and subsequently, SELinux enforcement bypass.

    Exploiting Vulnerable IOCTLs:

    1. Identify Accessible Device Nodes: Use ls -lZ /dev/ to list device nodes and their SELinux contexts. Look for device nodes accessible to domains like untrusted_app or app_domain.
    2. Analyze Driver Code: For accessible device nodes, analyze the corresponding kernel module’s source code (if available) for ioctl handlers. Look for integer overflows, out-of-bounds writes, use-after-free, or time-of-check-to-time-of-use (TOCTOU) issues.
    3. Craft Malicious IOCTL Calls: If a vulnerability is found, craft a specific ioctl call with malicious arguments to trigger the flaw, gaining kernel-level privileges. This bypasses SELinux because the kernel itself is compromised, allowing the attacker to effectively disable or modify policy at runtime.
    // Example C code snippet for an ioctl call (conceptual)// Assume device_fd is opened to a vulnerable device driverint ioctl_ret = ioctl(device_fd, VULNERABLE_IOCTL_COMMAND, &malicious_payload);if (ioctl_ret == -1) {  perror("ioctl failed");}// On success, kernel vulnerability is triggered.

    Technique 5: Binder IPC and Service Manager Abuse

    Binder is Android’s inter-process communication (IPC) mechanism. Services communicate via Binder, and SELinux policies heavily restrict which domains can talk to which services and what actions they can perform. Misconfigurations in Binder policies can lead to privilege escalation.

    Exploiting Binder Policy Loopholes:

    1. Find Undocumented Binder Services: Some services might be accessible but not well-documented, potentially leading to less scrutinized code.
    2. Abuse Permitted Transactions: If an unprivileged domain is allowed to send a specific Binder transaction to a privileged service, and that service processes the transaction in a vulnerable way, it could be exploited. This is a form of domain transition abuse, but specifically through IPC.
    3. Service Manager Attacks: The servicemanager itself is a critical component. If an attacker can register a malicious service or manipulate existing service registrations, they could potentially redirect legitimate calls to their own malicious implementations. SELinux heavily protects servicemanager, so this would likely require a kernel or service manager specific vulnerability first.

    Conclusion and Mitigation

    Bypassing Android SELinux is a complex endeavor, typically requiring a combination of deep understanding of SELinux policy, kernel internals, and specific service implementations. While ‘permissive’ mode exploits are straightforward, the more advanced techniques involve exploiting logical flaws in domain transitions, arbitrary file primitives, or kernel vulnerabilities via ioctl calls. These techniques highlight that SELinux, while powerful, is not a silver bullet. Its effectiveness relies on a correctly configured policy and the absence of underlying vulnerabilities in the kernel and system services.

    Mitigating these bypasses requires:

    • Strict Policy Design: Adhering to the principle of least privilege, ensuring no domain has more permissions than necessary.
    • Code Auditing: Thoroughly auditing kernel drivers and system services for common vulnerabilities (buffer overflows, integer overflows, race conditions).
    • Up-to-Date Patches: Regularly applying security patches to address known vulnerabilities in the Android kernel and framework.
    • Hardening: Employing additional hardening measures like pointer authentication codes (PAC), memory tagging extension (MTE), and strict application sandboxing.

    By understanding these advanced bypass techniques, developers and security engineers can better fortify Android systems against sophisticated attacks, moving towards a truly ‘enforced’ security posture.

  • Mastering SELinux Policy: A Practical Guide to Bypassing Android’s Security Context

    Introduction: The Android Security Enforcer

    Android’s security model is a multi-layered defense system, with SELinux (Security-Enhanced Linux) standing as one of its most critical components. Introduced in Android 4.3 (Jelly Bean) and moving to enforcing mode in Android 5.0 (Lollipop), SELinux provides Mandatory Access Control (MAC) over all processes, files, and system resources. Unlike traditional Discretionary Access Control (DAC) which relies on user and group IDs, SELinux policies dictate what an application or process *can* do, regardless of its user ID. This significantly strengthens the sandboxing of apps and system services, making it exceptionally difficult for exploits to escalate privileges or access sensitive data outside their designated security contexts.

    Every file, process, and IPC object on an SELinux-enabled Android system has a security context (e.g., u:object_r:system_file:s0 or u:r:untrusted_app:s0). The SELinux policy, a set of rules loaded into the kernel, determines whether a specific operation (like reading a file, executing a program, or sending a signal) is allowed between two contexts. When an operation is denied, an Access Vector Cache (AVC) denial is logged, a clear indicator of SELinux in action.

    The Challenge: Overcoming Strict Policy Enforcement

    For security researchers and penetration testers, SELinux presents a formidable barrier. A successful exploit often requires not just finding a vulnerability, but also navigating the SELinux policy to achieve the desired impact. Bypassing SELinux typically means either finding a way to operate within an already overly permissive context, modifying the policy, or escalating privileges to a domain that can disable or modify SELinux itself.

    Understanding the current SELinux status is crucial. On a rooted device, you can check it using:

    adb shellgetenforce

    This command will return either Enforcing or Permissive. In Permissive mode, AVC denials are logged but not enforced, allowing operations to proceed. However, production Android devices are almost exclusively in Enforcing mode.

    Technique 1: Exploiting Policy Weaknesses and Misconfigurations

    The first avenue for bypassing SELinux involves scrutinizing the existing policy for weaknesses. Manufacturers or custom ROM developers might introduce custom SELinux rules, sometimes inadvertently granting excessive permissions to certain domains. An attacker might exploit a vulnerability within a process running in such an overly permissive domain.

    To analyze the policy, tools like sepolicy-analyze (from AOSP source) can be invaluable for understanding the rules. On-device, you can often inspect file contexts using ls -Z and process contexts using id -Z.

    adb shell ls -Z /data/data/com.example.appadb shell id -Z

    Imagine a scenario where a third-party daemon (e.g., vendor_daemon) has a broad allow rule, perhaps:

    allow vendor_daemon system_data_file:file { read write execute create };

    If a vulnerability exists in vendor_daemon that allows arbitrary file writes, this broad rule would permit the daemon to write to any file labeled system_data_file, potentially leading to arbitrary code execution if it can overwrite a system executable or library within that context.

    Technique 2: Leveraging Overly Privileged Services or Unconfined Domains

    Some domains on Android are inherently more privileged than others, such as init, system_server, or the kernel itself. If an attacker can find a vulnerability in a service running in one of these highly trusted domains, they can potentially inherit those higher privileges.

    The init process, for example, often runs with broad capabilities to initialize the system. While its direct interaction surface is limited, an exploit targeting a bug in init or a service launched directly by it could gain significant control. Similarly, vulnerabilities in system_server (the core Android framework process) are gold mines, as system_server has extensive permissions to interact with almost all other system services and app data.

    Identifying such targets involves a deep understanding of Android’s system architecture and careful auditing of services. The goal is to find a path from a less privileged context (e.g., untrusted_app) to one of these highly privileged domains, typically through a chain of exploits.

    Technique 3: Dynamic Policy Manipulation (Requires Root/Bootloader Unlock)

    For devices where the bootloader can be unlocked, or custom recovery/root solutions like Magisk are available, dynamic SELinux policy manipulation becomes possible. This is not a direct bypass of an enforced policy but rather a method to *change* the policy to one that suits the attacker’s needs.

    The SELinux policy is typically stored in the sepolicy file within the boot.img or as part of the vendor partition. Modifying this file at boot allows for custom rules. For instance, an attacker could add a rule to make a specific application’s domain permissive, or grant it direct access to critical system resources.

    Example: Creating a Permissive Domain via Custom Policy

    If you can unpack and repack boot.img or modify sepolicy.cil directly (e.g., using AOSP build tools or Magisk modules), you could add a rule similar to this:

    # In a .te file (Type Enforcement)define(`my_exploit_app_domain', `domain')type my_exploit_app_domain, domain;type my_exploit_app_domain_exec, exec_type, file_type, system_file;# In a .te file (Type Enforcement) or .cil (Common Intermediate Language)permissive my_exploit_app_domain;

    Then, by labeling your malicious application’s executable with my_exploit_app_domain_exec and ensuring it runs in my_exploit_app_domain, SELinux enforcement would be disabled for that specific domain. This method is often employed by advanced rooting solutions to achieve full system control while bypassing SELinux’s restrictions on modifying system files.

    Magisk, for instance, uses its ‘magic’ mount to apply policy changes dynamically at boot without permanently altering the system partition, often by loading supplementary policy rules.

    Technique 4: Privilege Escalation via Kernel Vulnerabilities

    The ultimate bypass involves exploiting a vulnerability in the Linux kernel itself. A successful kernel exploit can allow an attacker to gain arbitrary code execution in kernel mode, effectively bypassing all user-space security mechanisms, including SELinux. Once in kernel mode, an attacker can:

    • Disable SELinux entirely by manipulating kernel variables (e.g., setting selinux_enforcing to 0).
    • Modify the loaded SELinux policy dynamically.
    • Change the security context of any process.
    • Access or modify any file on the system.

    Kernel vulnerabilities (CVEs) are rare and highly sought after. They often involve complex memory corruption bugs (e.g., use-after-free, double-free, out-of-bounds writes) that allow an attacker to gain control over the kernel’s execution flow. While exceedingly difficult to achieve, a kernel exploit represents a complete and unequivocal bypass of SELinux.

    Conclusion

    Mastering SELinux policy on Android is a continuous battle between attackers and defenders. While SELinux provides a robust layer of defense, understanding its mechanisms is key to both exploiting and securing Android devices. Techniques range from meticulously auditing existing policies for weaknesses and leveraging highly privileged system services, to more advanced methods involving dynamic policy manipulation on unlocked devices, and ultimately, exploiting kernel vulnerabilities to gain unfettered control. As Android’s security model continues to evolve, so too must our approaches to understanding and navigating its most formidable security enforcer.

  • Beyond Denials: Crafting Custom SELinux Policies to Achieve Sandbox Bypass on Android

    Beyond Denials: Crafting Custom SELinux Policies to Achieve Sandbox Bypass on Android

    Introduction: The Android Security Model and SELinux

    Android’s robust security architecture relies heavily on a multi-layered approach, with SELinux (Security-Enhanced Linux) serving as a critical mandatory access control (MAC) mechanism. Introduced in Android 4.3 and strictly enforced since Android 5.0, SELinux complements traditional discretionary access control (DAC) by defining fine-grained permissions for all processes and files. It dictates what subjects (processes) can do to objects (files, sockets, IPC mechanisms), effectively sandboxing applications and system components to mitigate the impact of vulnerabilities.

    For security researchers, exploit developers, and Android enthusiasts, understanding and manipulating SELinux policies is paramount. While most exploits focus on achieving code execution within an app’s sandbox, a true “sandbox bypass” often implies escaping these SELinux constraints to access resources or perform actions outside the intended domain. This article delves into the expert-level process of analyzing existing SELinux policies, identifying weaknesses, and crafting custom rules to achieve specific sandbox bypasses, moving beyond simple denial logs to active policy modification.

    SELinux Fundamentals on Android

    To effectively bypass SELinux, a solid grasp of its core concepts is essential:

    • Subjects and Objects: Processes are subjects, and resources like files, directories, network sockets, IPC objects, and devices are objects.
    • Security Contexts: Every subject and object has a security context (e.g., u:r:untrusted_app:s0 for an application, u:object_r:wifi_data_file:s0 for a Wi-Fi configuration file). This context comprises user, role, type, and sensitivity level. The “type” field is the most significant for policy decisions.
    • Type Enforcement (TE): The primary mode of SELinux. Rules specify what types can access what other types, and with what permissions.
    • Classes and Permissions: Objects belong to specific classes (e.g., file, socket, binder). For each class, a set of permissions exists (e.g., read, write, execute, call).
    • Policy Rules: The heart of SELinux. Common rules include:
      • allow S T:C P;: Grants subject type S permission P to object type T of class C.
      • dontaudit S T:C P;: Prevents denials for this rule from being logged, useful for reducing noise.
      • neverallow S T:C P;: A critical rule that explicitly forbids specific access and is enforced during policy compilation. Circumventing neverallow rules is significantly harder, often requiring changes to the AOSP source or a deep understanding of policy enforcement.

    The Sandbox Challenge: Why SELinux Matters for Exploitation

    Traditional memory corruption vulnerabilities (like buffer overflows or use-after-free) often grant an attacker arbitrary code execution within the compromised process’s context. However, on Android, this is often insufficient for a full system compromise. Even with root privileges, SELinux might prevent a process from accessing files, interacting with critical services, or modifying system configurations, due to its MAC policies. This is where a targeted SELinux bypass becomes crucial.

    Consider an `untrusted_app` that achieves arbitrary code execution. Without an SELinux bypass, it remains confined. Any attempt to read sensitive system files, modify a core system property, or inject into another process will likely trigger an AVC (Access Vector Cache) denial, logged by the kernel:

    avc: denied { read } for pid=1234 comm=

  • Bypassing KASLR on Android: Techniques for Reliable Kernel UAF Exploitation

    Introduction to KASLR and its Impact on Android Exploitation

    Kernel Address Space Layout Randomization (KASLR) is a crucial security feature designed to prevent arbitrary kernel code execution by randomizing the memory locations of kernel code and data. On Android, KASLR is implemented across various kernel components, making traditional kernel exploits that rely on hardcoded addresses largely unreliable. For attackers, this means that even if a kernel vulnerability like a Use-After-Free (UAF) is discovered, successfully exploiting it to achieve arbitrary code execution or privilege escalation requires first bypassing KASLR to determine the kernel’s base address and the addresses of critical functions or data structures.

    This article delves into the techniques used to bypass KASLR on modern Android kernels, specifically focusing on how these bypasses enable reliable exploitation of Use-After-Free vulnerabilities. We will explore common information leak primitives, their practical application, and how to leverage the leaked information to achieve control flow or arbitrary memory access within the kernel.

    Understanding KASLR on Android

    Android’s implementation of KASLR varies across devices and kernel versions, but generally involves randomizing the base address of the kernel image at boot time. Additionally, kernel modules, slab caches, and the kernel stack may also be subject to randomization. This dynamic placement effectively negates exploits that rely on static memory addresses, forcing attackers to find a way to leak these randomized addresses at runtime.

    A significant challenge in Android exploitation is the typical restriction on reading /proc/kallsyms, often controlled by kptr_restrict, which is usually set to 1 or 2. When kptr_restrict is 1, unprivileged users cannot read kernel pointers from /proc/kallsyms. When it’s 2, even privileged users (without specific capabilities) are restricted. This prevents a direct and easy information leak, pushing attackers to more sophisticated methods.

    Information Leak Primitives for KASLR Bypass

    The primary method to bypass KASLR involves discovering an information leak vulnerability that reveals a kernel pointer. These vulnerabilities often manifest as:

    1. Uninitialized Kernel Stack or Heap Data Leaks

    When the kernel allocates memory (stack frames or heap objects) and fails to initialize all its bytes before returning it to userspace or making it accessible, residual data from previous kernel operations might be exposed. This residual data often contains kernel pointers. For instance, a `read` operation on a kernel object that returns more data than initialized might leak adjacent memory. Similarly, a stack-based vulnerability where a function’s local variables are not fully initialized could reveal stack addresses.

    2. Out-of-Bounds (OOB) Reads

    An OOB read vulnerability allows an attacker to read data beyond the intended bounds of a kernel buffer. If a kernel object containing pointers is placed immediately after the vulnerable buffer, an OOB read could directly expose those pointers. Finding such vulnerabilities often involves fuzzing or meticulous code review of kernel drivers.

    3. Exploiting `seq_file` Operations

    Many kernel interfaces expose information via `seq_file` operations (e.g., /proc/self/maps for userspace processes, but also various device-specific entries in /proc or /sys). If a kernel developer mistakenly exposes an internal kernel pointer through a `seq_file` entry without proper sanitization (e.g., masking out higher bits or converting to an offset), it can serve as a direct KASLR bypass. Although rare due to stringent checks, it’s a potent source when present.

    Example: Conceptual Information Leak via OOB Read

    Consider a hypothetical kernel module with a vulnerable buffer:

    struct my_data {  char buffer[16];  void (*callback_fn)(void); // Located just after buffer};void my_write_handler(struct my_data *data, const char *user_buf, size_t len) {  if (len <= sizeof(data->buffer)) {    memcpy(data->buffer, user_buf, len);  } else {    // Vulnerable: Allows writing beyond buffer, but we're interested in read  }}void my_read_handler(struct my_data *data, char *user_buf, size_t len) {  // Imagine an OOB read here, if len can exceed sizeof(data->buffer)  // and kernel doesn't bounds check properly before copying.  // For simplicity, let's assume a separate bug exposes `callback_fn`.  // e.g., an ioctl returns uninitialized data that was overwritten by callback_fn.  // Or, a crafted input makes the driver miscalculate size and reads 'callback_fn' out.  if (len > 0 && len <= sizeof(struct my_data)) { // Incorrect bounds check    memcpy(user_buf, data, len); // Copies entire struct, potentially exposing callback_fn  }}

    If such a vulnerability exists, reading the entire `struct my_data` through a `read` or `ioctl` could leak the address of `callback_fn`, which points into kernel text. With this address, the kernel base address can be calculated by subtracting the known offset of `callback_fn` within the kernel image.

    Leveraging Leaked Pointers for Reliable UAF Exploitation

    Once a kernel pointer is leaked, it serves as the foundation for a reliable UAF exploit. The typical steps involve:

    1. Calculate Kernel Base Address

      Subtract the known offset of the leaked symbol (e.g., a function address) from the leaked absolute address. This provides the randomized kernel base address. You can often find symbol offsets from `vmlinux` or `System.map` files of the target kernel version.

      // Assuming 'leaked_addr' is the address of 'some_kernel_func'// And 'some_kernel_func' is at offset 0x123456 in the kernel imageunsigned long kernel_base = leaked_addr - 0x123456;

    2. Locate Gadgets and Target Structures

      With the kernel base known, you can now reliably locate ROP (Return-Oriented Programming) gadgets, critical function pointers (e.g., within `tty_operations`, `file_operations`), or data structures (e.g., `modprobe_path`) anywhere in kernel memory. These addresses are no longer random but are simply an offset from the known base.

    3. Trigger and Exploit UAF

      A Use-After-Free vulnerability allows an attacker to control the contents of freed kernel memory that is subsequently reallocated. By carefully orchestrating memory allocations, an attacker can get a controlled object (e.g., user-controlled data) into the memory region previously occupied by the freed object. The leaked kernel base address is critical here because it allows the attacker to craft the controlled object with legitimate kernel pointers. For example:

      • Overwriting a Function Pointer: If the UAF allows overwriting a function pointer within a freed structure (e.g., `tty_operations` vtable, or a callback in a network socket structure), the attacker can replace it with the address of a ROP gadget chain or a `commit_creds(prepare_kernel_cred(0))` sequence, now precisely known due to KASLR bypass.
      • Arbitrary Read/Write Primitive: A UAF might be leveraged to create an arbitrary read/write primitive. For example, if a `msg_msg` or `pipe_buffer` object can be sprayed into the freed memory, and its `msg_next` or `page` pointer can be controlled, the attacker can use the KASLR-bypassed addresses to construct an arbitrary read/write operation.

    Example: UAF with KASLR Bypass for Privilege Escalation

    Imagine a UAF on a `struct file` object where `f_op` (file operations table) can be overwritten. With KASLR bypassed, we can find the address of `commit_creds` and `prepare_kernel_cred`.

    // Leaked kernel base address obtained from info leakunsigned long kernel_base = ...;// Known offsets (from vmlinux)unsigned long prepare_kernel_cred_offset = 0xabcdef00; // Example offsetunsigned long commit_creds_offset = 0x12345000;      // Example offsetunsigned long swapgs_restore_regs_and_return_to_usermode_offset = 0x56789000; // Example ROP gadgetunsigned long kpti_trampoline_offset = 0xdeadbeef; // Example for recent kernels// Calculate absolute addressesunsigned long prepare_kernel_cred_addr = kernel_base + prepare_kernel_cred_offset;unsigned long commit_creds_addr = kernel_base + commit_creds_offset;unsigned long rop_gadget_addr = kernel_base + swapgs_restore_regs_and_return_to_usermode_offset;// 1. Trigger UAF to free target object (e.g., a `struct file`)// 2. Spray controlled objects (e.g., `msg_msg` or custom kernel module data) to reclaim the freed memory.   //    Craft the spray object to contain a fake `file_operations` table.   //    The fake `file_operations` table would point to our ROP chain.   //    The ROP chain would typically be:   //    call prepare_kernel_cred(0)   //    call commit_creds(previous_result)   //    call rop_gadget_addr (to return to userspace with new privileges)

    By overwriting a function pointer within the reallocated UAF object with an address pointing to our ROP gadget, and ensuring the ROP chain contains the KASLR-bypassed addresses of `prepare_kernel_cred` and `commit_creds`, we can execute arbitrary code with kernel privileges.

    Conclusion

    Bypassing KASLR is a fundamental step in achieving reliable kernel exploitation on modern Android devices. While KASLR significantly raises the bar for attackers, the existence of information leak vulnerabilities provides a pathway to defeat this protection. By carefully identifying and exploiting these leaks to determine the kernel’s randomized base address, security researchers and attackers can then reliably leverage Use-After-Free and other kernel vulnerabilities to achieve privilege escalation or arbitrary code execution. The constant evolution of kernel security features necessitates an adaptive approach, where understanding memory layout, common vulnerability patterns, and KASLR bypass techniques are paramount for successful exploit development.

  • Kernel Race Conditions & UAF: Crafting Timely Exploits on Android Devices

    Introduction: The Android Kernel Frontier

    Android’s security model, primarily enforced by the Linux kernel, presents a formidable barrier to attackers. While application-level vulnerabilities are common, kernel exploits offer the ultimate prize: arbitrary code execution in kernel mode, leading to full control over the device, bypassing SELinux, and elevating privileges. Among the myriad of kernel vulnerabilities, Use-After-Free (UAF) flaws, especially when combined with race conditions, represent a critical class for exploit development on Android.

    This article delves into the intricacies of UAF vulnerabilities, the role of race conditions in their timely exploitation, and the techniques involved in crafting reliable kernel exploits for Android devices. We will explore how an attacker can leverage these primitives to gain control and bypass existing security mechanisms.

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

    A Use-After-Free (UAF) vulnerability occurs when a program continues to use a pointer after the memory it points to has been freed. In the kernel context, this can be catastrophic. When a kernel object is freed, its memory is returned to the slab allocator. If a stale pointer to this freed memory is subsequently dereferenced, and that memory region has been reallocated for a different purpose (potentially with attacker-controlled data), the attacker can manipulate the new object’s structure to achieve arbitrary read/write primitives or even direct code execution.

    Consider a simplified kernel module scenario:

    struct my_kernel_object {    void (*callback_fn)(void);    int id;    char name[16];};struct my_kernel_object *global_obj;void my_legit_callback(void) {    printk(KERN_INFO "Legit callback executed!");}long my_ioctl(struct file *file, unsigned int cmd, unsigned long arg){    switch (cmd) {        case CREATE_OBJ:            global_obj = kmalloc(sizeof(*global_obj), GFP_KERNEL);            if (!global_obj) return -ENOMEM;            global_obj->callback_fn = my_legit_callback;            global_obj->id = 0xDEADBEEF;            strcpy(global_obj->name, "Original");            printk(KERN_INFO "Object created at %pn", global_obj);            break;        case FREE_OBJ:            if (global_obj) {                kfree(global_obj);                global_obj = NULL; // Best practice, but often missed in vulnerable code            }            printk(KERN_INFO "Object freed.n");            break;        case USE_OBJ:            if (global_obj) {                // UAF here if global_obj was freed and reallocated                printk(KERN_INFO "Using object at %p (ID: %x, Name: %s)n",                    global_obj, global_obj->id, global_obj->name);                global_obj->callback_fn(); // Potential UAF trigger            } else {                printk(KERN_INFO "Object is null, cannot use.n");            }            break;    }    return 0;}

    In this example, if FREE_OBJ is called, but global_obj is not immediately nulled out (or if another path keeps a reference), a subsequent USE_OBJ call could trigger a UAF if the memory has been reallocated by the time global_obj->callback_fn() is invoked.

    The Role of Race Conditions in UAF Exploitation

    While UAF itself is dangerous, successfully exploiting it often requires precise timing. This is where race conditions become paramount. A race condition occurs when the outcome of a program depends on the sequence or timing of uncontrollable events, such as the scheduling of concurrent threads or processes. In the context of UAF, a race condition can be leveraged to:

    1. **Trigger the UAF reliably:** Ensure that the stale pointer is dereferenced exactly when the freed memory has been reallocated with attacker-controlled data.
    2. **Control re-allocation:** Win the race to reallocate the freed memory chunk with a custom object or data structure that the attacker controls, before legitimate kernel operations can claim it.

    Consider the previous UAF example. If global_obj is freed, the attacker needs to quickly allocate new memory with a malicious payload (e.g., a fake my_kernel_object containing a pointer to a kernel shellcode) into the same memory slot before the kernel reuses that slot for something benign. Then, the stale pointer needs to be dereferenced.

    This sequence typically involves at least two threads or processes:

    • **Thread A (Vulnerable Thread):** Triggers the `kfree` of the target object and subsequently attempts to use the stale pointer.
    • **Thread B (Attacker Thread):** Engages in

  • Patch Diffing Android Kernels: Uncovering UAF Fixes & Exploitable Bugs

    Introduction to Patch Diffing for Android Kernel Exploits

    Patch diffing is a highly effective methodology in offensive security, particularly for uncovering kernel vulnerabilities. By comparing different versions of a kernel’s source code, security researchers can pinpoint changes that indicate bug fixes, sometimes revealing the very bugs they were designed to patch. For Android kernel exploitation, this technique is invaluable, allowing us to identify Use-After-Free (UAF) vulnerabilities – a class of memory corruption bugs often leading to powerful arbitrary code execution capabilities within the kernel context.

    This tutorial will guide you through the process of setting up a patch diffing environment for Android kernels, obtaining relevant sources, performing the diff, and critically analyzing the output to identify potential UAF fixes that can be reverse-engineered into exploitable vulnerabilities.

    Prerequisites and Environment Setup

    Before diving into the intricate world of kernel patch diffing, ensure you have the following prerequisites and a suitable environment:

    • Linux Workstation: A powerful Linux machine (Ubuntu, Debian, Fedora) is recommended.
    • Disk Space: Android kernel sources and build artifacts require significant disk space (50-100GB).
    • Toolchain: An ARM64/AArch64 cross-compilation toolchain. The Android NDK often provides suitable toolchains, or you can use a pre-built one like aarch64-linux-gnu-gcc.
    • Kernel Sources: You’ll need at least two versions of the target Android kernel. Typically, this involves a vulnerable version and a patched version.
    • Familiarity: Basic understanding of C, Linux kernel internals, and Git.

    Setting Up the Toolchain

    One way to get a reliable toolchain is to use the Android NDK. Download and extract it:

    wget https://dl.google.com/android/repository/android-ndk-r25b-linux.zip
unzip android-ndk-r25b-linux.zip
export PATH=$PATH:$(pwd)/android-ndk-r25b/toolchains/llvm/prebuilt/linux-x86_64/bin/

    Alternatively, use a system-provided toolchain if available:

    sudo apt update
sudo apt install crossbuild-essential-arm64

    Verify your setup:

    aarch64-linux-android-gcc --version
# or
aarch64-linux-gnu-gcc --version

    Obtaining Kernel Sources and Patches

    The first crucial step is acquiring the kernel source code for the versions you intend to compare. For Android devices, these often come from two primary sources:

    1. Android Open Source Project (AOSP): Google releases kernel source for Pixel devices and generic Android builds.
    2. Device Manufacturers (OEMs): OEMs like Samsung, Xiaomi, etc., often provide their kernel sources, usually on dedicated developer portals or through their Git repositories.

    Cloning AOSP Kernel Sources

    For a common AOSP kernel, like the one for Pixel devices (e.g., android-msm-pixel-4.9), you would clone the relevant branches. Let’s assume we’re looking at a patch between android-msm-pixel-4.9-q-r1 (vulnerable) and android-msm-pixel-4.9-q-r2 (patched).

    git clone https://android.googlesource.com/kernel/msm.git msm_kernel_vulnerable
cd msm_kernel_vulnerable
git checkout android-msm-pixel-4.9-q-r1
cd ..

git clone https://android.googlesource.com/kernel/msm.git msm_kernel_patched
cd msm_kernel_patched
git checkout android-msm-pixel-4.9-q-r2
cd ..

    Ensure both repositories are fully checked out to their respective stable tags or commits representing the versions you wish to compare. It’s often helpful to build both kernels once to ensure all dependencies are met and the environments are functional, although not strictly necessary for simple patch diffing.

    Performing the Diff

    Once you have both kernel source trees, the diffing process is straightforward. The diff utility with specific flags is your best friend for a recursive, human-readable comparison.

    diff -Naur msm_kernel_vulnerable/ msm_kernel_patched/ > kernel_patch.diff
    • -N: Treat absent files as empty.
    • -a: Treat all files as text.
    • -u: Output in unified format (context lines).
    • -r: Recursively compare directories.

    The kernel_patch.diff file will contain a comprehensive record of every change between the two kernel versions. This file can be thousands or even tens of thousands of lines long. For targeted analysis, it’s often more practical to focus on specific subsystems or files known to be common sources of vulnerabilities, such as drivers, network stack components, or IPC mechanisms.

    Analyzing Diffs for Use-After-Free Vulnerabilities

    The real art of patch diffing lies in intelligently sifting through the diff output to identify security-relevant changes. When hunting for UAFs, we’re looking for modifications that affect object lifetimes, memory allocations, and deallocations.

    Key Indicators of UAF Fixes

    Focus your attention on code areas where changes involve:

    • Memory Allocation/Deallocation: Look for additions or removals of kmalloc, kfree, kzalloc, kmem_cache_alloc, kmem_cache_free, rcu_dereference, synchronize_rcu, etc.
    • Reference Counting: Patches often introduce or fix improper reference counting (e.g., kref_get, kref_put) to prevent an object from being freed while still in use. Look for new kref_get before a use or kref_put after a use that wasn’t there before.
    • Object State Transitions: Changes in state machines where an object might transition to a “freed” or “invalid” state while still reachable or used by another code path.
    • NULL Checks: The addition of if (ptr == NULL) checks before dereferencing a pointer, especially after a kfree call, can indicate a UAF attempt was prevented.
    • Locking Mechanisms: Changes in mutexes, spinlocks, or semaphores might indicate an attempt to synchronize access to shared resources and prevent race conditions that could lead to UAF.

    Example Pattern: RCU-Protected Objects

    A common pattern for UAF is improper handling of RCU-protected objects. Consider a diff showing changes around rcu_dereference and synchronize_rcu:

    --- a/drivers/char/foo_driver.c
+++ b/drivers/char/foo_driver.c
@@ -100,6 +100,7 @@
 struct foo_device *foo_dev_get(int id)
 {
  struct foo_device *dev;
+ rcu_read_lock();
  list_for_each_entry_rcu(dev, &foo_list, list) {
   if (dev->id == id)
    return dev;
@@ -112,6 +113,7 @@
  if (!dev)
   return ERR_PTR(-ENODEV);
  kref_get(&dev->refcount);
+ rcu_read_unlock();
  return dev;
 }
 
@@ -120,6 +122,7 @@
 {
  if (kref_put(&dev->refcount, foo_dev_release)) {
   list_del_rcu(&dev->list);
+  synchronize_rcu(); /* Ensures no more readers */
   kfree(dev);
  }
 }

    In this hypothetical diff, the patched version (+++) introduces rcu_read_lock()/rcu_read_unlock() around foo_dev_get and synchronize_rcu() before kfree(dev) in foo_dev_put. This suggests that foo_dev_release might have been freeing dev while an RCU reader could still hold a reference, leading to a UAF. The synchronize_rcu() ensures all existing RCU read-side critical sections have completed before the memory is freed, preventing the UAF.

    By analyzing the context of these changes, an attacker can understand how the original bug worked, potentially enabling them to trigger it in the unpatched kernel version.

    Reproducing and Exploiting the Vulnerability

    Once a potential UAF fix is identified, the next steps involve:

    1. Understand the Original Bug: Based on the patch, reconstruct the conditions under which the UAF could occur in the vulnerable kernel.
    2. Develop a Proof-of-Concept (PoC): Write a kernel module or user-space program to trigger the UAF. This often involves specific timing, concurrent operations, or misuse of API calls.
    3. Heap Spraying and Object Reclaiming: For a UAF, the goal is often to reclaim the freed memory with a controlled object. This requires understanding kernel heap grooming techniques.
    4. Achieve Primitive: Turn the UAF into a more powerful primitive, such as arbitrary read/write, or control over a function pointer, ultimately leading to root privileges.

    This phase often involves deep kernel debugging (e.g., using gdb with QEMU or a physical device) to observe memory states and execution flow.

    Conclusion

    Patch diffing is a powerful, proactive methodology for discovering kernel vulnerabilities, especially UAFs, in Android. By meticulously analyzing the differences between kernel versions, security researchers can reverse-engineer bug fixes into exploitable flaws. This technique not only enhances understanding of kernel security but also provides a systematic approach for identifying critical vulnerabilities before they are widely known or actively exploited. Mastering this skill is a cornerstone for advanced Android kernel exploit development.

  • From Crash to Control: Developing a Custom Android Kernel UAF Exploit Walkthrough

    Introduction: The Lure of Kernel UAFs

    The Android operating system, at its core, relies on the Linux kernel. A vulnerability within this kernel can provide an attacker with unparalleled control over the device, bypassing all sandbox restrictions and achieving full system compromise. Among the most potent kernel vulnerabilities are Use-After-Free (UAF) flaws. A UAF occurs when a program continues to use a pointer to memory that has been freed, leading to unpredictable behavior, data corruption, or, in the hands of an attacker, arbitrary code execution and privilege escalation. This article provides an expert-level walkthrough of developing a custom Android kernel UAF exploit, taking you from understanding the vulnerability to achieving root control.

    Understanding Use-After-Free Vulnerabilities

    A Use-After-Free bug manifests in three distinct phases:

    1. Allocation: A chunk of memory is allocated and a pointer (let’s call it ptr_A) refers to it.
    2. Free: The memory chunk pointed to by ptr_A is freed, but ptr_A itself is not nullified or reset.
    3. Use-After-Free: The program attempts to use ptr_A to access the freed memory. At this point, the kernel’s memory allocator might have already reallocated that same memory chunk for a different purpose (e.g., to hold attacker-controlled data).

    When an attacker can control the data that reclaims the freed memory, they can manipulate kernel structures, hijack control flow, or leak sensitive information. On Android, this typically means a local attacker gaining root privileges, thus escaping the Android sandbox.

    The Exploit Target: A Hypothetical UAF

    To illustrate, let’s consider a simplified, hypothetical kernel module that manages ‘widget’ objects. This module might expose ioctl commands for creating, destroying, and operating on widgets. Imagine a flaw where a widget structure is freed by one ioctl, but a global or per-file-descriptor pointer to it is not properly cleared, allowing a subsequent ioctl to dereference the stale pointer.

    // Simplified Vulnerable Kernel Code Structurevoid *my_widget_ptr = NULL;struct widget {    int id;    void (*callback)(void);};long my_module_ioctl(struct file *filp, unsigned int cmd, unsigned long arg){    switch (cmd) {        case CMD_CREATE_WIDGET:            my_widget_ptr = kmalloc(sizeof(struct widget), GFP_KERNEL);            if (my_widget_ptr) {                ((struct widget*)my_widget_ptr)->id = get_next_id();                ((struct widget*)my_widget_ptr)->callback = default_callback;            }            break;        case CMD_DESTROY_WIDGET:            if (my_widget_ptr) {                kfree(my_widget_ptr);                // VULNERABILITY: my_widget_ptr is NOT set to NULL            }            break;        case CMD_USE_WIDGET:            if (my_widget_ptr) {                // UAF triggered here if my_widget_ptr was freed!                ((struct widget*)my_widget_ptr)->callback();            }            break;    }    return 0;}

    In this example, calling CMD_DESTROY_WIDGET then CMD_USE_WIDGET creates a UAF condition.

    Step 1: Triggering the Vulnerability

    The first step for an exploit is reliably triggering the UAF. From user space, this involves a specific sequence of system calls, often ioctl operations, to interact with the vulnerable kernel driver. Assuming our hypothetical widget driver, the trigger sequence would be:

    1. Open the device file associated with the kernel module (e.g., /dev/my_widget).
    2. Call CMD_CREATE_WIDGET to allocate a widget object.
    3. Call CMD_DESTROY_WIDGET to free the allocated widget object, leaving my_widget_ptr stale.
    4. Before the next step, ensure no other kernel allocations occur that might immediately reclaim the freed memory.
    5. Call CMD_USE_WIDGET to dereference the stale my_widget_ptr. This is where we want our crafted data to reside.
    // User-space C code snippet to trigger UAF#include <fcntl.h>#include <sys/ioctl.h>#define CMD_CREATE_WIDGET 0x13370001#define CMD_DESTROY_WIDGET 0x13370002#define CMD_USE_WIDGET 0x13370003int main(){    int fd = open("/dev/my_widget", O_RDWR);    if (fd < 0) {        perror("open");        return 1;    }    ioctl(fd, CMD_CREATE_WIDGET, 0);    printf("Widget created. Now freeing...n");    ioctl(fd, CMD_DESTROY_WIDGET, 0);    printf("Widget freed. Now attempting UAF use...n");    // At this point, we need to spray the heap before calling CMD_USE_WIDGET    // ... (heap spray code goes here) ...    ioctl(fd, CMD_USE_WIDGET, 0); // UAF Use!    close(fd);    return 0;}

    Step 2: Heap Grooming and Spraying

    After freeing the widget, the goal is to reclaim that specific memory address with attacker-controlled data. This is achieved through heap grooming and spraying. The Linux kernel’s slab allocator (kmalloc) tends to reuse recently freed memory of the same size. We can exploit this by allocating numerous objects of the same size as our freed widget, filling them with our payload.

    A common technique on Android is using msg_msg structures via msgrcv and msgsnd system calls. The msg_msg structure allows allocating arbitrary data sizes and offers control over the contents. By sending many messages of the widget‘s size, we increase the probability that one of our messages reclaims the freed widget memory.

    // User-space C code snippet for msg_msg heap spray#include <sys/msg.h>#include <string.h>#define WIDGET_SIZE 16 // Example size, adjust based on actual struct size#define NUM_MSQ_OBJECTS 100struct msgbuf {    long mtype;    char mtext[WIDGET_SIZE - sizeof(long)];};int main_spray(void){    int msqid[NUM_MSQ_OBJECTS];    struct msgbuf msg;    msg.mtype = 1;    // Prepare our fake widget payload    // For example, overwrite 'callback' pointer with address of our shellcode or a kernel gadget    memset(msg.mtext, 'A', sizeof(msg.mtext));    // Assuming the callback pointer is at offset 8 (sizeof(int))    // We'd overwrite msg.mtext[4] with the address of a kernel gadget    // Example: * (unsigned long *)(msg.mtext + 4) = KERNEL_GADGET_ADDR;    for (int i = 0; i < NUM_MSQ_OBJECTS; i++) {        msqid[i] = msgget(IPC_PRIVATE, IPC_CREAT | 0666);        if (msqid[i] < 0) {            perror("msgget");            return -1;        }        if (msgsnd(msqid[i], &msg, sizeof(msg.mtext), 0) < 0) {            perror("msgsnd");            return -1;        }    }    printf("Heap sprayed with %d msg_msg objects.n", NUM_MSQ_OBJECTS);    return 0;}

    The `mtext` field in `msg_msg` will now contain our controlled data, effectively becoming our fake `widget` object. When `CMD_USE_WIDGET` is called, the `callback` pointer within our fake `widget` will be dereferenced.

    Step 3: Achieving Arbitrary Read/Write Primitive

    While directly overwriting a function pointer like `callback` can lead to arbitrary code execution if KASLR (Kernel Address Space Layout Randomization) is bypassed, a more robust primitive is often an arbitrary read/write. This can be achieved by carefully crafting the spray payload. For instance, if the vulnerable object is a `file` struct, spraying with a crafted `seq_operations` struct can allow us to control the `release` function pointer. Alternatively, a technique known as

  • Setting Up Your Android Kernel Exploit Lab: Essential Tools for UAF Development

    Introduction to Android Kernel Exploitation and UAF

    The Android operating system, built atop the Linux kernel, presents a formidable target for security researchers and exploit developers. Unlike userland applications, kernel exploits offer unparalleled control over the device, bypassing many security mechanisms. Among the most common and potent kernel vulnerabilities are Use-After-Free (UAF) bugs. A UAF vulnerability occurs when a program attempts to use memory after it has been freed, potentially allowing an attacker to overwrite freed memory with controlled data, leading to arbitrary code execution or privilege escalation.

    Setting up an effective Android kernel exploit development environment is a multi-faceted task, requiring a blend of software tools, hardware understanding, and meticulous configuration. This guide will walk you through establishing a robust lab environment specifically tailored for identifying, analyzing, and exploiting Use-After-Free vulnerabilities in the Android kernel.

    Setting Up Your Core Development Environment

    Operating System: The Foundation

    A Linux-based operating system is virtually mandatory for Android kernel development due to its native support for essential tools and build systems. Ubuntu LTS or Debian are highly recommended for their stability, extensive package repositories, and widespread community support.

    # Recommended initial setup for Ubuntu/Debian
sudo apt update
sudo apt upgrade -y
sudo apt install -y build-essential git python3 python3-pip openjdk-11-jdk bc flex libssl-dev bison libelf-dev libncurses-dev axel cpio bzip2 xz-utils curl wget make

    Android SDK & NDK: Bridging Userland and Kernel

    While direct kernel development doesn’t always rely on the full Android SDK, the NDK (Native Development Kit) is crucial for compiling userland helper binaries and exploit payloads that interact with the kernel. The SDK also provides `adb` (Android Debug Bridge), an indispensable tool for device interaction.

    # Download Android SDK Command-line Tools (e.g., from developer.android.com)
mkdir -p ~/Android/cmdline-tools
unzip commandline-tools-linux-*.zip -d ~/Android/cmdline-tools/latest
export PATH=$PATH:~/Android/cmdline-tools/latest/bin

# Install NDK and Platform Tools
sdkmanager --install "ndk;25.2.9519653" "platform-tools" "platforms;android-33"
export ANDROID_HOME=~/Android
export PATH=$PATH:$ANDROID_HOME/platform-tools:$ANDROID_HOME/ndk/25.2.9519653

    Cross-Compilation Toolchains

    Android devices typically use ARM (AArch32) or AArch64 architectures. You’ll need cross-compilation toolchains to build kernel modules and userland programs for your target device from your x86_64 host. The NDK includes suitable toolchains, but standalone GCC/Clang toolchains from Linaro or similar projects are also excellent choices.

    # NDK-provided toolchain (example path, adjust NDK version)
export PATH=$PATH:$ANDROID_HOME/ndk/25.2.9519653/toolchains/llvm/prebuilt/linux-x86_64/bin

# For standalone toolchains (e.g., from Linaro)
# wget https://developer.arm.com/-/media/Files/downloads/gnu/10.3-2021.07/binrel/gcc-arm-10.3-2021.07-x86_64-aarch64-none-linux-gnu.tar.xz
# tar -xf gcc-arm-10.3-2021.07-x86_64-aarch64-none-linux-gnu.tar.xz -C /opt/
# export PATH=$PATH:/opt/gcc-arm-10.3-2021.07-x86_64-aarch64-none-linux-gnu/bin

    Acquiring and Building the Android Kernel

    Identifying Your Target Kernel Sources

    The first step is to obtain the kernel source code matching your target device and Android version. For Google Pixel devices, AOSP (Android Open Source Project) provides kernel manifests. For other manufacturers (Samsung, Xiaomi, etc.), you might need to check their respective open-source portals or firmware repositories.

    Downloading Kernel Sources

    AOSP kernels are typically managed with `repo`.

    # Example for a Pixel 6 kernel (adjust manifest and branch as needed)
mkdir android-kernel
cd android-kernel
repo init -u https://android.googlesource.com/kernel/manifest -b android-gs-raviole-5.10-android12-qpr3 --depth=1
repo sync -j$(nproc)

    Building the Kernel

    Once sources are downloaded, configure and build the kernel. You’ll need the appropriate `defconfig` for your device (e.g., `gki_defconfig` for Generic Kernel Image, or device-specific ones like `gs201_defconfig`).

    # From your kernel source directory
export ARCH=arm64
export CROSS_COMPILE=aarch64-linux-android-

# Or for standalone toolchain (adjust prefix)
# export CROSS_COMPILE=/opt/gcc-arm-10.3-2021.07-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-

make gs201_defconfig # Replace with your device's defconfig
make menuconfig # Optional: customize kernel options for debugging
make -j$(nproc) # Build the kernel and modules

    Upon successful compilation, the kernel image (`Image.gz` or `Image.lz4`) will be found in `arch/arm64/boot/` and kernel modules (`.ko` files) in various subdirectories. You might need to package these into a boot image (e.g., `boot.img`) using tools like `mkbootimg` for flashing to a device or loading into QEMU.

    Setting Up Your Debugging Environment

    QEMU for Rapid Prototyping and Initial Debugging

    QEMU allows you to emulate ARM/AArch64 Android devices, offering a safer and faster environment for initial exploit development and debugging compared to physical hardware. It’s ideal for iterating on kernel modules and triggering UAF conditions without risking device bricking.

    # Example QEMU invocation for an AArch64 kernel (requires a rootfs/initrd)
qemu-system-aarch64 -M virt -cpu cortex-a57 -smp 2 -m 2048M 
-kernel arch/arm64/boot/Image.gz-dtb 
-initrd /path/to/ramdisk.img 
-append "console=ttyAMA0,115200 root=/dev/ram0 rw earlyprintk loglevel=8" 
-net nic -net user,hostfwd=tcp::5555-:5555 
-nographic -S -gdb tcp::1234,ipv4

    GDB for Kernel Debugging

    GDB (GNU Debugger) is your primary tool for kernel-level debugging. When used with QEMU, you can connect GDB to the emulated kernel’s debug port (e.g., TCP port 1234 in the QEMU example above).

    # From your kernel source directory
aarch64-linux-android-gdb vmlinux # Load the uncompressed kernel image with symbols

(gdb) target remote :1234 # Connect to QEMU
(gdb) b start_kernel # Set a breakpoint at kernel entry
(gdb) c # Continue execution
(gdb) bt # Backtrace
(gdb) x/i $pc # Disassemble current instruction
(gdb) add-symbol-file path/to/your_module.ko 0xffffffffXXXXXXX # Load module symbols (address from /proc/modules)

    For UAF analysis, GDB allows you to set breakpoints on `kmalloc`, `kfree`, and suspect functions, inspect registers and memory, and trace execution flow during object allocation and deallocation.

    Hardware Debugging (Advanced)

    For real-world device exploitation, hardware debugging via JTAG/SWD interfaces provides unparalleled visibility into the kernel’s execution. This typically involves specialized hardware debuggers (e.g., Lauterbach TRACE32, OpenOCD with a compatible JTAG adapter) and soldering to debug pads on the device’s PCB. This is significantly more complex and beyond the scope of a basic setup guide but crucial for advanced exploit development.

    Essential Tools for UAF Analysis and Exploitation

    Static Analysis: Ghidra and IDA Pro

    Reverse engineering tools like Ghidra (free) and IDA Pro (commercial) are vital for static analysis of kernel binaries (`vmlinux`, kernel modules). They allow you to decompile/disassemble code, identify potential vulnerability patterns, understand driver logic, and map out memory allocation/deallocation routines. For UAF, you’d look for paths where an object is freed but a pointer to it might still be accessible and dereferenced later.

    Dynamic Analysis & Fuzzing: Syzkaller

    Syzkaller is a powerful, open-source kernel fuzzer developed by Google. It systematically tests the kernel’s syscall interface to discover bugs, including UAFs. Setting up Syzkaller for Android kernels is a complex task but immensely rewarding for automated vulnerability discovery. It can be configured to run on QEMU or physical devices.

    Kernel Patches for Enhanced Debugging

    Sometimes, the default kernel doesn’t offer enough visibility into memory management. Custom patches can be applied to the kernel sources (e.g., to the SLUB or SLAB allocator) to add extensive debugging information. For instance, you can log allocations/frees, track object lifetimes, or introduce canary values to detect heap corruptions related to UAF. Look into `CONFIG_SLUB_DEBUG` and similar options in `make menuconfig`.

    # Example: Enabling SLUB debug via .config or make menuconfig
CONFIG_SLUB_DEBUG=y
CONFIG_SLUB_DEBUG_ON_BY_DEFAULT=y
CONFIG_DEBUG_KMEM=y
CONFIG_BUG_ON_DATA_CORRUPTION=y

    These settings introduce significant overhead but provide invaluable insights into heap behavior, critical for understanding and exploiting UAF conditions. Remember to rebuild your kernel after making such changes.

    Conclusion

    Setting up an Android kernel exploit lab for UAF development requires a commitment to detail and a foundational understanding of both Android and Linux kernel internals. By meticulously configuring your development environment, mastering kernel compilation, and leveraging powerful debugging and analysis tools like QEMU, GDB, Ghidra, and potentially Syzkaller, you’ll be well-equipped to dive into the intricate world of Android kernel exploitation. This lab provides the essential groundwork; the next step is to start hunting for and exploiting those elusive Use-After-Free vulnerabilities.

  • Building Kernel Exploitation Primitives: Mastering Heap Spraying on Android for UAF

    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.

  • Advanced Android Kernel Debugging: Troubleshooting UAF Exploits with GDB & QEMU

    Introduction to Android Kernel Exploitation and UAF

    Android kernel security is a critical battleground, and understanding kernel vulnerabilities like Use-After-Free (UAF) is paramount for both exploit developers and defenders. A UAF vulnerability occurs when a program continues to use a pointer to freed memory, leading to unpredictable behavior, data corruption, or even arbitrary code execution. Debugging these complex kernel exploits requires a specialized environment, and the combination of QEMU and GDB offers an unparalleled platform for in-depth analysis.

    This article will guide you through setting up an advanced debugging environment for the Android kernel, specifically tailored for identifying and troubleshooting UAF vulnerabilities using GDB in conjunction with a QEMU-emulated Android system. We’ll cover environment setup, basic UAF identification techniques, and advanced GDB features essential for kernel exploit development.

    Prerequisites and Environment Setup

    Before diving into debugging, ensure you have the necessary tools and a suitable environment. We’ll be working with a customized Android kernel built for QEMU.

    Required Tools:

    • AOSP Build Environment: A Linux-based system with sufficient disk space and RAM to build Android from source.
    • QEMU: A powerful emulator capable of running ARM-based Android kernels.
    • GDB (GNU Debugger): Specifically, a cross-compiler version (e.g., aarch64-linux-android-gdb) from the Android NDK.
    • Android Kernel Source: Downloaded from AOSP repositories.

    Building a Debuggable Android Kernel for QEMU

    To effectively debug, your kernel must be built with debugging symbols. Navigate to your kernel source directory and configure it.

    cd /path/to/android-kernel-source
export ARCH=arm64
export CROSS_COMPILE=/path/to/android-ndk/toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64/bin/aarch64-linux-android-
make defconfig
make menuconfig # Enable debugging options

    Inside `menuconfig`, navigate to ‘Kernel hacking’ and enable:

    • ‘Kernel debugging’
    • ‘Compile the kernel with debug info’ (CONFIG_DEBUG_INFO)
    • ‘Enable __GFP_ZERO and PAGE_POISONING’ (useful for detecting UAF)
    • ‘Slab debugging (SLUB)’ -> ‘SLUB debugging’ (CONFIG_SLUB_DEBUG)

    Save and exit, then build the kernel:

    make -j$(nproc)

    This will generate `arch/arm64/boot/Image` and `vmlinux` (the unstripped kernel image with symbols).

    Launching QEMU with GDB Server

    Once your debuggable kernel is built, launch QEMU with an Android ramdisk and a GDB server listening on a specific port.

    qemu-system-aarch64 
    -M virt -cpu cortex-a57 -m 2G -smp 2 
    -kernel /path/to/android-kernel-source/arch/arm64/boot/Image 
    -append "console=ttyAMA0,115200 root=/dev/vda rw init=/init androidboot.console=ttyAMA0" 
    -initrd /path/to/android/ramdisk.img 
    -drive file=/path/to/android/system.img,if=none,id=system 
    -device virtio-blk-device,drive=system 
    -serial mon:stdio 
    -netdev user,id=mynet -device virtio-net-device,netdev=mynet 
    -S -s
    • `-S`: Halts the CPU at startup, waiting for GDB to connect.
    • `-s`: Equivalent to `-gdb tcp::1234`, making QEMU listen for GDB connections on port 1234.
    • Replace `/path/to/android/ramdisk.img` and `/path/to/android/system.img` with your actual Android images.

    Connecting GDB to QEMU and Basic Debugging

    In a separate terminal, launch your `aarch64-linux-android-gdb` and connect to the QEMU instance.

    /path/to/android-ndk/toolchains/.../bin/aarch64-linux-android-gdb 
    /path/to/android-kernel-source/vmlinux

(gdb) target remote localhost:1234
(gdb) continue

    You are now connected! GDB will load the kernel symbols from `vmlinux`, and `continue` will start the QEMU VM. You can set breakpoints, inspect registers, and step through kernel code.

    Identifying and Troubleshooting UAF Exploits

    UAF vulnerabilities are often subtle. They involve a pointer becoming ‘stale’ after its memory has been freed, only to be dereferenced later. Your goal is to catch this dereference and observe the memory state.

    Scenario: Custom Kernel Module UAF

    Consider a hypothetical kernel module with a UAF flaw:

    struct my_data {
    int value;
    char name[16];
};

static struct my_data *global_data_ptr = NULL;

// Allocate and initialize
static ssize_t alloc_write(struct file *file, const char __user *buf, size_t count, loff_t *ppos) {
    global_data_ptr = kmalloc(sizeof(struct my_data), GFP_KERNEL);
    if (global_data_ptr) {
        global_data_ptr->value = 0xDEADBEEF;
        strncpy(global_data_ptr->name, "initial", sizeof(global_data_ptr->name) - 1);
    }
    return count;
}

// Free the data
static ssize_t free_write(struct file *file, const char __user *buf, size_t count, loff_t *ppos) {
    if (global_data_ptr) {
        kfree(global_data_ptr);
        // global_data_ptr is now a stale pointer!
        // A real bug would involve it being used *after* this point without being set to NULL.
    }
    return count;
}

// Use the data AFTER it might have been freed (hypothetical UAF trigger)
static ssize_t use_read(struct file *file, char __user *buf, size_t count, loff_t *ppos) {
    if (global_data_ptr) {
        // If memory at global_data_ptr was freed and re-allocated by something else,
        // this read is a UAF!
        printk(KERN_INFO "UAF Read: Value = %x, Name = %sn", global_data_ptr->value, global_data_ptr->name);
    }
    return count;
}

    Debugging Steps with GDB:

    1. Set Breakpoints: Identify the `kmalloc`, `kfree`, and potential ‘use’ sites.
      2. (gdb) b alloc_write
(gdb) b free_write
(gdb) b use_read
    2. Trigger Allocation: From the Android shell (via `adb shell`), trigger the `alloc_write` operation (e.g., by writing to a `/dev/mydevice` file).
    3. Inspect Memory After Allocation: When GDB hits `alloc_write` (or just after), inspect `global_data_ptr`.
      4. (gdb) p global_data_ptr
(gdb) x/16wx global_data_ptr  // Examine 16 words in hex at the address
    4. Trigger Free: Continue execution and trigger the `free_write` operation.
    5. Observe After Free: After `kfree` returns, the memory pointed to by `global_data_ptr` is free. Ideally, `global_data_ptr` should be nulled. If not, it’s stale.
      6. (gdb) p global_data_ptr // The address won't change, but the content might.
(gdb) x/16wx global_data_ptr // What's there now? Poisoned data? New data from another allocation?
    6. Heap Spray (to re-occupy freed memory): To make the UAF impactful, you often need to re-occupy the freed memory with attacker-controlled data. This is typically done by triggering other kernel allocations (e.g., creating pipes, sockets, or specific kernel objects) of the same size as the freed object.
    7. Trigger Use-After-Free: Finally, trigger the `use_read` function. If `global_data_ptr` points to re-occupied memory, you’ll observe your sprayed data instead of the original or an immediate crash.

    Advanced GDB Techniques for UAF

    • Watchpoints: Set a watchpoint on the memory location `global_data_ptr` points to. GDB will halt whenever that memory address is written to or read from. This is incredibly powerful for tracking memory corruption.
      • (gdb) watch *global_data_ptr
(gdb) watch -l global_data_ptr->value // Watch a specific member
    • Conditional Breakpoints: Break only when certain conditions are met, such as when `global_data_ptr` is not NULL after `kfree`.
      • (gdb) b free_write if global_data_ptr != 0
    • Python Scripting in GDB: Automate complex debugging tasks, like logging memory contents at various stages, or analyzing heap metadata (if SLUB debugging is enabled).
      • python
  # Example: Print memory content before and after free
  # gdb.execute("commands 1")
  # gdb.execute("x/16wx global_data_ptr")
  # gdb.execute("end")
end

    Conclusion

    Debugging Use-After-Free vulnerabilities in the Android kernel is a challenging but essential skill for security researchers and exploit developers. By leveraging QEMU for emulation and GDB for precise memory inspection and execution control, you can systematically identify, analyze, and troubleshoot these critical flaws. The techniques outlined here – from setting up a debuggable kernel to using advanced GDB features like watchpoints – provide a robust foundation for deeper dives into kernel exploit development and hardening Android’s security posture.