Sign in with
Sign up | Sign in

Explaining The Vulnerability

Exclusive Interview: Hacking The iPhone Through SMS
By

Alan: So, in essence, you’re slowly transmitting the machine code for a full fledged application of your own, only it’s done over 140 bytes at a time?

Charlie: Sort of. I am also carefully setting things up so that memory is in a predictable fashion. Normally, the layout of memory is very unpredictable. But if you make enough allocations of a particular size, you can start to introduce some predictability. This technique is sometimes called heap feng shui, and is used to make exploits that rely on certain conditions more reliable. For example, I have to make sure data I control shows up right before this array that I can access before the first element.

This attack is especially dangerous for a few reasons. One is that it doesn't require any user interaction. Normally, I do browser exploits where you have to get a user to go to a particular site. Here, I can attack your phone while it’s in your pocket or on the charger or whatever. The other thing that makes it really bad is the process that handles SMS messages, CommCenter, runs as root and has no restrictions. By comparison, the browser runs as the lowly "mobile" user and has a sandbox, which prevents it from doing things like forking or sending SMS messages.

Alan: So how did you first discover the vulnerability?

Charlie: I found the bug by sending in thousands of malformed SMS messages to the device, a process known as fuzzing.

Alan: So, the injection framework allowed you direct access to CommCenter? Thousands? Were you sending thousands of random strings and tracking the output?

Charlie: Actually, the framework sat right between CommCenter and the modem on the device. The framework relays all the information from the modem to CommCenter and also could inject SMS messages as well. In this way, there was no way for CommCenter to know if the message had really come from the modem or if it had come for us. 

The data wasn’t totally random. The way it works is you take good data, obtained by reading the SMS-related specifications, and add small anomalies to them. So the whole SMS message is legitimate except one small part. Repeat this for all small parts. It takes a lot of effort to generate these types of test cases.

Alan: So, once you had identified the vulnerability, what did it take to move it toward the exploit stage?

Charlie: As for writing the exploit, it was extremely difficult. I'm used to writing browser exploits where you have a lot of control in the environment. You can make the browser do whatever you want using JavaScript and HTML. This allows the attacker to set up memory in very predictable ways. Here, I was limited to 140 byte SMS messages and the process performed a lot of actions between each message. It took me about 2.5 weeks to get it all worked out, but it was really cool when it worked.

Alan: 2.5 weeks? Wow. That’s essentially nothing compared to how long the iPhone has been around. Was this in the original iPhone software?

Charlie: The bug’s probably been there forever. I checked back to iPhone OS 2.2. That's the scary thing. How many other bugs like this do bad guys know about? I'm a smart guy, but there are plenty of people as smart and smarter than me out there who can find these kinds of bugs.

React To This Article