The iPhone Wiki is no longer updated. Visit this article on The Apple Wiki for current information. |
Difference between revisions of "0x24000 Segment Overflow"
(→Prerequisites) |
Planetbeing (talk | contribs) |
||
Line 7: | Line 7: | ||
chronic, CPICH, ius, planetbeing, pod2g, posixninja, and co. |
chronic, CPICH, ius, planetbeing, pod2g, posixninja, and co. |
||
− | == |
+ | ==Background== |
− | The address that the bootrom loads [[LLB]] into is 0x22000000, and for some reason, it stores it's global variables dangerously close, at 0x22024000. Now, when loading [[LLB]] from [[NOR]], it does not have any sort of maximum size limit, (unlike if it was receiving a file via USB). With an LLB with a size greater then 0x24000, you can gracefully overwrite, and change many of these global variables. Although, for some parts, you may need to reconstruct, with the original data. There are a few different ways you could exploit this to actually run unsigned code at this level. So far the easiest one found is based on another fail decision that Apple made. For some reason, they put the SHA1 hardware address array smack dab in our way. By changing the address at SHA1 Data Input Register 1 (LLB @ 0x240fc), bootrom will attempt to write whatever should be written into sha1, into whatever address we have specified. So, since we can now write to any location in memory, we specify it to point to and overwrite where the current LR is on the stack (0x2202fe24). Now when bootrom starts to copy data over into sha1 register, instead it will actually be overwriting it's own return address and will put whatever address is at 0x20 of the LLB image in LR. Now just add the address of your payload (that's stored somewhere in the padding preferably) into 0x20 of LLB, and it will be executed! For the payload it's wise to put the original bytes that were in 0x20 back, and to restore the proper sha1 hardware address, as well as clean up the stack a little bit before doing your thing and jumping back into code. Also, another important thing to remember is that you must 1. add 0x22000000 to whatever the offset of your payload is in the file, since that is where it loads LLB in memory, and 2. reverse it for endianess. |
||
+ | 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 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. |
||
− | ==Prerequisites== |
||
+ | |||
− | Because files sent over USB have a size limitation, one thing that is the ability to flash the [[NOR]] unsigned. This can be done by putting the device into dfu mode and writing to the nor0 block device using a tools like iRecovery. |
||
+ | ==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. |
||
+ | |||
+ | 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 [http://pastie.org/414981]. |
||
+ | |||
+ | 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 sizeable 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'''. 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. |
||
+ | |||
+ | This 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. |
||
[[Category:Exploits]] |
[[Category:Exploits]] |
Revision as of 07:43, 13 March 2009
Also known by it's 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. I apologize if the wording is odd, as I wrote it up a little while ago, planning to post it this summer.
Credit
chronic, CPICH, ius, planetbeing, pod2g, posixninja, and co.
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 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.
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 sizeable 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. 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.
This 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.