| Vulnerability in SecureROM | |
|---|---|
| Software | iPhone 3GS |
| Vulnerable versions | 359.3 - 359.4[1] |
| Fixed in version | 359.5 |
| Disclosed | 11 April 2017 |
| Discovered by | axi0mX (tweet) |
| CVE | CVE-2019-9536 |
The alloc8 exploit is a bootrom exploit with a CVE ID of CVE-2019-9536 used to run unsigned code on both the new bootrom and the old bootrom iPhone 3GS (and thereby jailbreak it). It is the first public untethered bootrom exploit for the new bootrom iPhone 3GS.
axi0mX published a detailed analysis of alloc8 at GitHub following his discovery of the exploit - of which this page is heavily based off of.
ipwndfu is currently the primary and most simple way of using the alloc8 exploit.
Background
The S5L8920 SoC is an ARMv7 CPU - which means that the ARM exception vector table is mapped at 0x0. This holds exceptions that will handle any errors in the BootROM code should they arise. This is a commonly exploited attack surface on ARMv7 CPUs.
Vulnerability
The malloc() function - used to allocate memory on the heap - is fundamentally broken in this version of SecureROM. Usually, if unable to allocate the memory requested, the function should return NULL. Instead, it returns a pointer to the memory address 0x8. This means that by trying to allocate memory when it cannot be allocated will cause SecureROM to return to us a pointer to this address.
Exploit
axi0mX found that the only way they could fill up the heap during boot was with additional images. By filling up NOR with more than the single LLB required to boot the device, SecureROM will try to parse them all and allocate them each. 44-byte structure. This is fixed in later versions of the SecureROM.
Once the heap has been filled up with images, we will receive the pointer to 0x8 and that can be used for reading and writing to that address. By overwriting the exception vector table, the pointers that usually point to the exception handlers can be changed to point to our shellcode. While SecureROM is parsing the images in NOR, each image is allocated a temporary buffer of 4096 bytes. Because there are so many images, eventually, one of these buffers will not be allocated and will start to fill memory at 0x8 - from images we have full control over.
Using this, we can overwrite the data abort exception handler pointer to point to our shellcode. When it has finished reading all images in NOR, SecureROM tries to free the temporary buffer at 0x8 - which triggers a bad memory access and therefore a data abort exception, jumping to our shellcode.
Shellcode
The first 52 bytes of NOR contain an IMG2 header that holds metadata about the NOR - which is left untouched. Before parsing images, SecureROM copies the first 512 bytes from NOR into memory. This gives us 460 bytes to fill with our shellcode which wouldn't be used anyway. This data is always allocated at the same addresses.
Post-exploitation
After exploitation, the shellcode returns from the data abort exception, cleans the heap of the 44-byte image structures and restores the pointer for the original data abort handler. The only 44-byte structure left on the heap is that of the LLB to actually boot.
