The next phase after this involves a callback-chain which is only necessary for a few of the currently compatible devices of checkm8. The next parts involve allocating and freeing the IO buffer without clearing the global state, overwriting the usb_device_io_request in the head with use-after-free and placing the payload. While the attack is possible without this technique, this does ensure that the exploitation of the use-after-free is more reliable and consistent. The heap feng-shui tricks the heap allocation algorithm in to placing data a specific offset, which can then be computed based on the changes to the heap. The process has several steps but one of the most important is known as Heap feng-shui which is essential to checkm8 as it arranges the heap in a very specific way to make the exploitation of the use-after-free vulnerability easier. The use-after-free vulnerability lies in the process, if the process is interrupted and the Data Stage is skipped, the global state will remain intact during the next DFU cycle and it will be possible to write to the address of the IO buffer allocated during the first DFU cycle.Ĭheckm8 essentially just takes advantage of this use-after-free vulnerability in the DFU process to allow for arbitrary code to be executed. When DFU is exited the IO buffer is freed and the image is booted but if the image fails to boot then the BootROM enters DFU mode again. Once all data is received, the contents of the IO buffer are copied into the memory location where the image is later booted. When the data package is received it is then written to the IO buffer, and global variable keeps track of the amount of data received. The interface then checks the length of the data is shorter than the IO buffer and if it is, then the handler returns two things, an address to the IO Buffer and a length for the amount of data it expects to receive, both of which are stored in global variables. When you send data to the device the setup packet is handled by the DFU part of the USB interface. When an iPhone is put into DFU mode and DFU is initialized, an IO buffer is allocated and a USB interface is created for processing requests to DFU. Use-After-Free vulnerability is when you reference memory after is has been freed which can cause various results such as program to crash, unexpected values, or in this case code executionįirst to understand the expolit we need to understand how DFU mode works. In my experimentation I used an iPhone 5s which just involves hold the home and power button for 10 seconds and then letting go of power and continuing to hold the home button for another 10 seconds. This is usually done by booting the iPhone while executing certain button presses. This heart of the exploit lies in a use-after-free vulnerability found in the USB code of the BootROM which is carried out in DFU mode.Ī little background on two things mentioned in that last sentence:ĭFU mode stands for Device Firmware Upgrade and it generally used to restore devices from any state, most commonly after an unsuccessful update. The BootROM is incredibly important to the security of the boot chain and with a compromise to it, a user could compromise the subsequent stages: iBoot, Kernel, and iOS. It does initialization of the platform, parsing of IMG3/IMG4 images (these are iOS firmware images), decrypting of these images files with the GID key, image verification, and DFU mode. As shown in the image below, the BootROM is the first thing executed when an iPhone turns on. We should first start with some background information on the BootROM itself. All of which will give greater insight into how the iPhone operates at a low level and the high level. Regardless, this new development is not only beneficial to the jailbreaking community but to security researchers as it allows you to dump secureROM, decrypt firmware images, and enable JTAG. But Apple seems to have been aware of the issue as they have already patched this issue on both the A12 and A13 chip. It should also be noted that since this exploit lies in the BootROM it is impossible for Apple to patch, fixing this issue requires a hardware revision. Which is vulnerable on devices with any SoC ranging from an A5 to A11 chip (iPhone 4S – iPhone 8 & iPhone X). While there have been BootRom exploits released recently they have all been for old devices such as the iPhone 3GS, this is not the case for checkm8. An exploit of this severity has not been seen since geohot released the limera1n exploit for the iPhone 4 back in 2010. This exploit will give iOS hacker and researchers unprecedented access to the iPhone. Recently security researcher axi0mX discovered at BootROM Exploit which has been dubbed as “checkm8” (pronounced checkmate).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |