In my last post, I described the Apple iPhone in terms of being a security tool and a security target. At the time, I had just finished a first pass on iPhone shellcode. What I didn't realize was that a stock iPhone does not include a /bin/sh executable, nor any of the standard Unix command line tools. My shellcode would only be useful against iPhones which had been updated with the BSD environment package.

A few days later, Apple released the 1.1.1 update. This update removed any installed third-party packages and relocked unlocked phones. Fortunately for the iPhone development community, Apple shipped the iPhone with a vulnerable version of the libtiff library and didn't bother updating it for the 1.1.1 release. This vulnerability has already been used to run homebrew games on the Sony PSP and can be exploited through the MobileSafari web browser. Two of the members (Niacin and Dre) put together an impressive exploit for this flaw that jailbreaks the phone directly from the browser. This exploit prepares a gigantic stack frame and returns back to an address within the libSystem shared libary. After a ridiculous amount of chained returns, it manages to rename a file, create a symlink, and remount the root filesystem. A hell of a job, especially considering the state of the iPhone debugging tools.

Using a security vulnerability to enable third-party development is nothing new, but in the case of iPhone, this can be a problem. The libtiff flaw can be triggered by both MobileSafari and MobileMail, two applications which are used heavily by many iPhone users. The tricky part is writing an exploit which is reliable and is not limited to calling existing functions within a shared library. One approach is to return to a memcpy() call, another is to find a bounce path through a system library, back to the heap. Technically, a heap fill attack could work as well, but only by using a large tiff file or through the use of javascript in MobileSafari.

The first step to writing a weaponized exploit for this flaw is to obtain a usable debugger. The weasel utility is a great start, but is missing a few useful features, such as memory search and command repetition. I hacked out a new version of weasel (hdm-0.1) tonight that provides a "v" command (dump the virtual memory mappings), a "f" command (search for an ascii or hex string inside process memory), and the ability to attach to a running process. While this code works, it is still ugly as sin, so try not to judge it too harshly (yes, there are scanf overflows in input parsing, no, I don't care). The following example shows the memory search command locating all instances of the word "Hello" in the MobileSafari process.

# ./weasel -p 259 /Applications/
Read 4 symbols.
[$3008b224 weasel] f 0x0 Hello
009e2168  48 65 6c 6c 6f 3f 27 2c 48 74 6d 6c 55 72 6c 3a
02b2d158  48 65 6c 6c 6f 3f 27 2c 48 74 6d 6c 55 72 6c 3a
3134e113  48 65 6c 6c 6f 00 5f 53 53 4c 50 72 65 70 61 72
3134e179  48 65 6c 6c 6f 44 6f 6e 65 00 5f 53 53 4c 50 72

Check back soon for part two, writing the exploit, and part three, BYOS (bring your own shell).

Update: The libtiff exploit can be triggered through the iTunes Music Store by anyone who can MiTM the WiFi connection (or run a fake access point). Credit for this goes to KF. Another fun use of MiTM attacks against iPhone 1.1.1 users can be found here (also courtesy of KF).