|
The iPhone Wiki is no longer updated. Visit this article on The Apple Wiki for current information. |
Pwnage
This exploit is in the S5L8900 bootrom, thus available in the iPhone, iPod touch, and iPhone 3G. The exploit is that the bootrom doesn't signature check LLB.
Credit
Exploit
S5L8900
Pwnage exploits a bad chain of trust in the boot sequence of the S5L8900 device. The boot sequence includes LLB and iBoot modules which are stored in the device's NOR flash and are typically encrypted (as of 1.1.*). However, they are not signed with RSA signature at that point, because the 8900 container is dropped away before the file is written to NOR. Pwnage exploits this vulnerability.
First, Apple assumes that if something is in NOR, it had necessarily passed through an RSA signature verification, and is therefore authentic Apple code. This is incorrect, because the only mechanism preventing the writing of unauthorized code to the NOR flash is the kernel. The iPhone/iPod touch kernel contains an extension designed specifically to write to NOR, called AppleImage2NORAccess. This extension performs an RSA signature verification on any data it tries to write. The verification itself is performed by the FairPlay extension, which is heavily obfuscated, but neutering the check is very simple. After the check is patched out, anything can be written to the NOR flash.
Second, Apple assumes that disabling the encryption keys in “normal” environment will prevent from writing firmware files to the NOR flash. Luckily, we have found a way to run our code in “secure” environment and use AppleImage2NORAccess extension the same way as Apple does it on restore.
Before iOS 2.0, the NOR was set up in a way that when the firmware images were flashed there, the RSA signatures were dropped along with the rest of the firmware container. So although iBoot signature checked the kernel, LLB did not signature check iBoot, and the VROM did not signature check LLB.
Pwnage starts by booting from a memory device (ramdisk) in “secure” environment to prevent the kernel from disabling encryption keys. Also, we add another memory device, pointed at the kernel's address space, to allow live kernel patching. After booting up, we patch out signature check from AppleImage2NorAccess extention and proceed with flashing our custom firmware files (iBoot, LLB, DeviceTree, and pictures). Because the signature check has been patched out, and encryption keys are available, AppleImage2NORAccess happily writes them to the suitable location in NOR flash. After that, the device can be restarted, and will accept any unsigned 8900 file without complaint.
One specific aspect of the attack that is worth examining more closely is the iBoot patch. iBoot is the last and most complicated bootloader on the devices, and is what actually loads up the kernel with DeviceTree. However, Apple made the decision to keep all the PKE (Public Key Encryption) logic out of iBoot, instead putting it in the secure bootloader. Thus, iBoot actually jumps into the secure bootloader when it wants to verify the authenticity of an 8900 file. This makes it hard to directly patch out the RSA signature verification from iBoot, as it actually occurs in the secure bootloader. Simply killing the jump into the secure bootloader is impossible, as it also fills in other information iBoot needs to proceed.
Because of the tight coupling between the secure bootloader and the higher-level bootloaders, Apple gave us a solution: the secure bootloader often needs to call functions in the higher-level bootloaders, but it has the problem of knowing where to jump, as functions move around in different revisions. To get around this, Apple made thunks out of the function calls, and makes the higher-level bootloaders patch the secure bootloader on the fly (in RAM) with the relevant jump addresses. They just copy the secure bootloader into RAM and blindly apply a list of patches to it. We exploited this pre-existing patching mechanism to patch out the RSA signature verification from secure bootloader.
Post-2.0, images are now written to NOR in a way that one can verify the other, like LLB verifying iBoot, the bootrom cannot be written to, so it still defaults to just reading LLB normally, un-signature checked.
The bootrom has a vulnerability in DFU Mode when processesing iBoot certificates which are on a DER format. It copies all the certificate information onto the stack, but the signature itself is copied without any sort of bounds checking. So then you have classic stack buffer overflow and then you just make the signature checking function return true.
S5L8720 and on
This exploit has been fixed on the iPod touch 2G and all devices released after it. The bootrom sigchecks LLB before jumping to it now, and if the LLB is patched, it will default to DFU Mode. The 0x24000 Segment Overflow exploit was later found in the first revisions of the iPod touch 2G and iPhone 3GS bootroms, allowing the device to be fully jailbroken. It has since been fixed with new bootrom revisions for these devices. Newer devices were never susceptible to the 0x24000 Segment Overflow.
