iOS Exploiting
Physical use-after-free
This is a summary from the post from https://alfiecg.uk/2024/09/24/Kernel-exploit.html moreover further information about exploit using this technique can be found in https://github.com/felix-pb/kfd
Memory management in XNU
The virtual memory address space for user processes on iOS spans from 0x0 to 0x8000000000. However, these addresses don’t directly map to physical memory. Instead, the kernel uses page tables to translate virtual addresses into actual physical addresses.
Levels of Page Tables in iOS
Page tables are organized hierarchically in three levels:
L1 Page Table (Level 1):
Each entry here represents a large range of virtual memory.
It covers 0x1000000000 bytes (or 256 GB) of virtual memory.
L2 Page Table (Level 2):
An entry here represents a smaller region of virtual memory, specifically 0x2000000 bytes (32 MB).
An L1 entry may point to an L2 table if it can't map the entire region itself.
L3 Page Table (Level 3):
This is the finest level, where each entry maps a single 4 KB memory page.
An L2 entry may point to an L3 table if more granular control is needed.
Mapping Virtual to Physical Memory
Direct Mapping (Block Mapping):
Some entries in a page table directly map a range of virtual addresses to a contiguous range of physical addresses (like a shortcut).
Pointer to Child Page Table:
If finer control is needed, an entry in one level (e.g., L1) can point to a child page table at the next level (e.g., L2).
Example: Mapping a Virtual Address
Let’s say you try to access the virtual address 0x1000000000:
L1 Table:
The kernel checks the L1 page table entry corresponding to this virtual address. If it has a pointer to an L2 page table, it goes to that L2 table.
L2 Table:
The kernel checks the L2 page table for a more detailed mapping. If this entry points to an L3 page table, it proceeds there.
L3 Table:
The kernel looks up the final L3 entry, which points to the physical address of the actual memory page.
Example of Address Mapping
If you write the physical address 0x800004000 into the first index of the L2 table, then:
Virtual addresses from 0x1000000000 to 0x1002000000 map to physical addresses from 0x800004000 to 0x802004000.
This is a block mapping at the L2 level.
Alternatively, if the L2 entry points to an L3 table:
Each 4 KB page in the virtual address range 0x1000000000 -> 0x1002000000 would be mapped by individual entries in the L3 table.
Physical use-after-free
A physical use-after-free (UAF) occurs when:
A process allocates some memory as readable and writable.
The page tables are updated to map this memory to a specific physical address that the process can access.
The process deallocates (frees) the memory.
However, due to a bug, the kernel forgets to remove the mapping from the page tables, even though it marks the corresponding physical memory as free.
The kernel can then reallocate this "freed" physical memory for other purposes, like kernel data.
Since the mapping wasn’t removed, the process can still read and write to this physical memory.
This means the process can access pages of kernel memory, which could contain sensitive data or structures, potentially allowing an attacker to manipulate kernel memory.
Exploitation Strategy: Heap Spray
Since the attacker can’t control which specific kernel pages will be allocated to freed memory, they use a technique called heap spray:
The attacker creates a large number of IOSurface objects in kernel memory.
Each IOSurface object contains a magic value in one of its fields, making it easy to identify.
They scan the freed pages to see if any of these IOSurface objects landed on a freed page.
When they find an IOSurface object on a freed page, they can use it to read and write kernel memory.
More info about this in https://github.com/felix-pb/kfd/tree/main/writeups
Step-by-Step Heap Spray Process
Spray IOSurface Objects: The attacker creates many IOSurface objects with a special identifier ("magic value").
Scan Freed Pages: They check if any of the objects have been allocated on a freed page.
Read/Write Kernel Memory: By manipulating fields in the IOSurface object, they gain the ability to perform arbitrary reads and writes in kernel memory. This lets them:
Use one field to read any 32-bit value in kernel memory.
Use another field to write 64-bit values, achieving a stable kernel read/write primitive.
Generate IOSurface objects with the magic value IOSURFACE_MAGIC to later search for:
Search for IOSurface
objects in one freed physical page:
Achieving Kernel Read/Write with IOSurface
After achieving control over an IOSurface object in kernel memory (mapped to a freed physical page accessible from userspace), we can use it for arbitrary kernel read and write operations.
Key Fields in IOSurface
The IOSurface object has two crucial fields:
Use Count Pointer: Allows a 32-bit read.
Indexed Timestamp Pointer: Allows a 64-bit write.
By overwriting these pointers, we redirect them to arbitrary addresses in kernel memory, enabling read/write capabilities.
32-Bit Kernel Read
To perform a read:
Overwrite the use count pointer to point to the target address minus a 0x14-byte offset.
Use the
get_use_count
method to read the value at that address.
64-Bit Kernel Write
To perform a write:
Overwrite the indexed timestamp pointer to the target address.
Use the
set_indexed_timestamp
method to write a 64-bit value.
Exploit Flow Recap
Trigger Physical Use-After-Free: Free pages are available for reuse.
Spray IOSurface Objects: Allocate many IOSurface objects with a unique "magic value" in kernel memory.
Identify Accessible IOSurface: Locate an IOSurface on a freed page you control.
Abuse Use-After-Free: Modify pointers in the IOSurface object to enable arbitrary kernel read/write via IOSurface methods.
With these primitives, the exploit provides controlled 32-bit reads and 64-bit writes to kernel memory. Further jailbreak steps could involve more stable read/write primitives, which may require bypassing additional protections (e.g., PPL on newer arm64e devices).
Last updated