Http: initial page with some infos from mdowd's presentation

2012-10-16T22:55:30Z

initial page with some infos from mdowd's presentation

New page

The Heap has been hardened since iOS6 to prevent well-known attack strategies. Three mitigations were put in place:
*Pointer validation
*Block poisoning
*Freelist integrity verification
This is specific to the zone allocator (<code>zalloc()</code>, used by <code>kalloc()</code>, <code>MALLOC()</code>, <code>MALLOC_ZONE()</code>).

===Pointer Validation===
The goal is to prevent invalid pointers being entered into <code>kalloc()</code> zone's freelist. Additional checks are performed on pointers passed to <code>zfree()</code>. This is also performed as part of validation on pointers in freelist during allocation (<code>zalloc()</code>).

The pointer is verified to be in kernel memory (<code>0x80000000</code>-<code>0xFFFEFFFF</code>). If <code>allows_foreign</code> is set in zone, no more validation is performed (currently <code>event_zone</code>, <code>vm_map_entry_reserved_zone</code>, <code>vm_page_zone</code>). If the pointer is within kernel image, allow, otherwise ensure pointer is within <code>zone_map</code>.

===Block poisoning===
The goal is to prevent UAF-style attacks. The stategy involves filling blocks with sentinel value (<code>0xdeadbeef</code>) when being freed. This is done by <code>add_to_zone()</code>, called from <code>zfree()</code> and only on selected blocks with block sizes smaller than cache line size of processor (32 bytes on A5/A5X devices) and can be overridden with "<code>‑zp</code>", "<code>‑no‑zp</code>", "<code>zp‑factor</code>" boot parameters.

===Freelist integrity verification===
The goal is to prevent heap overwrites from being exploitable. Two random values are generated at boot time (<code>zone_bootstrap()</code>), 32-bit cookie for "poisoned blocks" and 31-bit cookie (low bit cleared) for "non-poisoned blocks". The value serves as a validation cookie.

The freelist pointers at the top of a free block are since iOS6 validated by <code>zalloc()</code>. This check is done by <code>alloc_from_zone()</code>. The encoded next pointer is placed at the end of block XORed with "poisoned_cookie" or "non-poisoned cookie".

The <code>zalloc()</code> ensures <code>next_pointer</code> matches the encoded pointer at the end of the block and tries both cookies. If the poisoned cookie matches, it checks the whole block for modification of sentinel (0xdeadbeef) values and kernel panics if either check fails. The next pointer and cookie is replaced by <code>0xdeadbeef</code> when allocated as possible information leak protection.

==References==
*[http://conference.hackinthebox.org/hitbsecconf2012kul/materials/D1T2%20-%20Mark%20Dowd%20&%20Tarjei%20Mandt%20-%20iOS6%20Security.pdf Mark Dowd & Tarjei Mandt's iOS6 presentation at HITB 2012 KUL D1T2]

Heap Hardening - Revision history

Http: initial page with some infos from mdowd's presentation