0x24000 Segment Overflow

Also known by its codename, "24kPwn", this was the first exploit in the S5L8720 that allowed us to bypass the bootrom signature checks on LLB and create what is known as an untethered jailbreak.

Note

It is unclear how, but the company "NitroKey" is selling this. We were planning on holding back for the new iPhone (which subsequently could mean an iPod 3G as well), but now that they are profiteering off of this we would like to explain exactly how this works as soon as possible so people do not have to pay for it.

Credit

A "hybrid" team, in alphabetical order: chronic, CPICH, ius, MuscleNerd, planetbeing, pod2g, posixninja, et al. (anyone wishing to be unnamed)

Background

Upon boot-up, the S5L8720 SoC has a MIU configuration which maps the "Secure ROM" to 0x0, providing the newly turned on device with an ARM exception vector and the first code to execute. This MIU configuration also maps a small amount of SRAM to 0x22000000. Statically allocated variables, heap, and stack must use the SRAM, as "Secure ROM" is unwritable. A region of memory starting from 0x22024000 is used for this purpose. The region of memory from 0x22000000 to 0x22024000 is used as a buffer for loading the next stage bootloader code (the LLB). The LLB code is stored in NOR, along with code for all other bootloader stages, as well as art resources (boot logos) and the OpenFirmware device tree to provide to the XNU kernel. The first portion (first 0x160 bytes) of memory at 0x22024000 is used for initialized statically allocated variables. Shortly after boot, values for that region are initialized from Secure ROM.

Vulnerability

The code that reads the LLB img3 from NOR into memory does not check the size of the LLB image being loaded, instead taking the size directly from the non-signature checked portion of its img3 header on the NOR (see ROM offset 0x2178). Any image greater than 0x24000 bytes in length will begin overwriting the portion of memory used to store Secure ROM statically allocated variables. Immediately vulnerable data includes USB data structures for DFU mode, a pointer to the bdev list structure, task list structures for the Secure ROM's scheduler, as well as the addresses of the hardware SHA1 registers. All of the above are potential avenues for exploitation. The method described below uses the SHA1 register addresses.

This vulnerability was discovered independently by pod2g and MuscleNerd.

Exploit

The goal of the exploit is to gain arbitrary code execution capability.

The exploit, as proposed by planetbeing, uses the overflow to overwrite one of the addresses of the SHA1 registers. The particular register is the only one that directly copies data to be hashed into the hardware (or into an arbitrary memory location, once the destination address has been overwritten). Code execution is achieved by writing data into the stack, specifically by overwriting the LR of the function performing the write to the "SHA1 register" so that instead of returning to the main SHA1 routine, it returns to a chosen location in memory that contains the payload code. The location chosen is within the range of memory that is filled with the LLB img3, so that the payload code can be placed within the LLB img3.

The challenge is determining what to put in as the SHA1 register location so that the right portion of stack can be overwritten with the payload LR. This can be challenging without having access to any sort of exception dump (crash register dumps in the bootrom had been disabled by Apple). planetbeing performed a static analysis of a very detailed IDB produced by chronic and CPICH and determined the theoretical call stack for both of the invocations of the SHA1 hardware within the bootrom code [1].

In-situ verification of the LR location was performed by posixninja. CPICH discovered a way to alter the img3 DER so that the second invocation of the SHA1 hardware was not performed without affecting the first, allowing better confirmation that this step was performed properly.

The final SHA1 register address was chosen so that the first dword of the DATA tag of the LLB img3 would replace sub_5E54's LR. This is because this is the first dword of the img3 that can be altered without substantially changing the img3's structure (and possibly disrupting earlier parsing code). The LR replacement must be done the first time the exploit is triggered (by the invocation of sub_5E54), or else the bootrom would crash. Since sub_5E54 takes 0x40 bytes of data at a time, the replacement LR thus must be within the first 0x40 bytes of data to be hashed. Data to be hashed starts at 0xC bytes from the start of the img3, and the first dword of the DATA tag is 0x20 bytes from the start of the img3. Thus, the SHA1 register address chosen should be 0x20 - 0xC = 0x14 bytes before sub_5E54's LR. So, it must be 0x2202FE24. Note that the exploit will also trash up to 0x2202FE24 + 0x40 = 0x2202FE64. So a size-able portion of doComputeSHA1's stack will be trashed as well.

The final exploit img3 was verified by posixninja under planetbeing's instructions to allow arbitrary code execution. It was a regular Img3 with padding up to 0x24000 bytes. The next 0x100 bytes were taken from the original initialization values for 0x22024000. However, 0x240FC, the offset of the SHA1 register address, was altered to 0x2202FE24. The first dword of the DATA tag (offset 0x20) was altered to 0x22023000. Payload code was placed at offset 0x23000.

Payload

The goal of the payload is to allow an unsigned LLB to be loaded.

There are several ways that can be used, including directly calling the JumpToMemory function which is designed to prepare the SoC and invoke the LLB code. However, it's designed to be used on decrypted, unpacked code, and the LLB code currently resides in an encrypted from within the img3's DATA tag. The simplest solution is thus to use the bootrom's own machinery to decrypt and execute the code.

The final payload evolved out of a discussion between pod2g and planetbeing, based on an IDB documented by pod2g, chronic, CPICH, et al. The lowest impact solution is to apply the pwnage patch to the rsaCheck subroutine of the bootrom, and returning from the payload from computing the SHA1 without crashing the bootrom. However, in this case, since bootrom text is unwritable, this was not a viable solution.

The next lowest impact solution is to return from the entire parseFirmwareFooter function with a successful value, instead of the failure value it would normally return if signature checks fail. This would skip any remaining code in that subroutine. This solution did not work in-situ. Failures checking the epoch tags prevented the firmware from being executed. The cause of this was not investigated.

The final payload was to return past the verification of epoch and other tags in the LLB img3 to a spot right before the DATA tag was loaded from memory and decrypted. R5 was set to 0 to ensure decryption would not be skipped. The original value for the first DATA dword (before we had to overwrite it with the exploit LR) is written back to 0x22000020 by the payload, and the original SHA1 register value was written back to 0x2202FE24 to ensure the payload only activates once.

Deployment

Although the exploitive LLB can be manually written to NOR by bootstrapping from a tethered jailbreak, the easiest way is to use the Apple restore process itself. Apple's Restore process will write arbitrary img3s onto the NOR, even if they fail signature checks. However, the "total size" value of the img3 is fixed up by the kernel before it is written to NOR. This would negate the exploit. However, MuscleNerd discovered that this could be bypassed by including the padding in another tag, such as CERT. Then, the written exploit LLB would have the "correct", exploitive total size.

Timing Impact

This exploit would have allowed the pwnage of the next generation iPhone without the discovery of an additional code execution vulnerability (required to write the exploit LLB), provided that the bug still existed in the next generation's bootrom. Even if it is too late to fix the bootrom now, it is not too late for Apple to fix the restore process in the initial shipping ipsw so that we have no way to get the exploitive LLB onto the device. Before, Apple would have no reason to fix this, since writing arbitrary data to NOR does not negate their chain of trust. However, now that a way has been found, they now can prioritize a fix for this oversight.

Thanks to irresponsible handling of the exploit by a third-party, this eventuality is a near-certainty and erased the possibility of the next generation iPhone from being jailbroken right off the bat. May they burn in hell.