Last updated at Wed, 26 Jul 2017 16:59:22 GMT
In part two of "Cracking the iPhone", the final result was a working exploit for the libtiff vulnerability. This exploit depended on four key addresses to work properly. The first address was the stack pointer where our string was stored. The stack pointer is static across the same version of the application, but does change between major versions. Due to this address change, a different stack address had to be used for MobileMail versus MobileSafari, and version 1.02 had a different address than 1.1.1. The second address was the location of a writable and executable page on the heap. The original address chosen by our exploit didn't work on all applications. The third and fourth addresses referred to two locations inside the libSystem.dylib library. These addresses did not change between versions or applications.
We can do better. In a perfect world, we can find a sequence of instructions, already in memory, at a static location, that copies a usable heap address into r0 (memcpy dst), the stack pointer into r1 (memcpy src), allow us to control r3 (the memcpy length), executes memcpy(), and then allow us to return back to the destination pointer on the heap. A quick grep of the libSystem.dylib disassembly for "mov r1, sp" pulls up quite a few matches. If we use the -A 1 and -B 3 grep flags, we notice the following block of code.
300d562c e2840030 add r0, r4, #0x30
300d5630 e1a0100d mov r1, sp
300d5634 e1a02008 mov r2, r8
300d5638 eb0029c6 bl _memcpy
A miracle! As mentioned in the previous blog post, we control almost all registers between r4 and r11 after the stack overwrite. We can set r4 to our destination pointer (-0x30), r8 to our memcpy length value, and let this function do our work for us. This code calls memcpy() and eventually returns to another address stored on the stack. There is one snag though, a few lines down we hit the following instruction:
300d566c e247d014 sub sp, r7, #0x14
The stack pointer is being overwritten with the value of the r7 register (-0x14). The two lines following are loading register values (and our return address, via pc) from this stack pointer.
300d5670 e8bd0500 ldmia sp!, {r8, r10}
300d5674 e8bd80f0 ldmia sp!, {r4, r5, r6, r7, pc}
Since we are copying our entire string from the stack to the heap, and we want to return back to the heap anyways, we can set r7 to the address of the memcpy() destination pointer and make this heap address our new stack pointer. After reviewing the memory mappings between MobileSafari, MobileMail, and the iTunes Music Store (in 1.1.1), we notice that the memory at 0x00802000 is always valid, writable, and executable within these applications. This address will become our new heap destination pointer.
The new version of this exploit only depends on two specific addresses in the target process. This is a huge improvement over the previous code and has been successfully tested on MobileMail, MobileSafari, and the iTunes Music Store on firmware versions 1.02 and 1.1.1. Two new modules have been committed to the Metasploit Framework development tree. When reading the source to these exploits, it helps if you have watched Charlie: Candy Mountain
The MobileSafari exploit can be found here.
The MobileMail exploit can be found here
.
