Hackers are determined to exploit any security flaws in Apple’s newest mobile device. Independent Security Evaluators (ISE) to the rescue: Dr. Charles Miller explains how his team of security analysts uncovered a potentially devastating iPhone vulnerability.
What compelled ISE to analyze the iPhone?
Apple wasn’t a client of ours, but the iPhone is an extremely popular device that millions of people will be using, so we worked in the interest of the consumers to make sure the iPhone was safe.
How long did it take you to uncover the flaw?
We got our iPhones two Mondays ago and discovered the vulnerability last Wednesday, so about a week and a half. We worked on it in our spare time, when we weren’t working on security analysis projects for our clients.
How did you hack into the iPhone?
We used a method called “fuzzing,” which is putting invalid data into a device and monitoring to see if a program crashes. Data goes into an application, which then processes it. The program then makes assumptions and arranges memory accordingly. If the program doesn’t allocate enough memory, it results in something called buffer overflow, a condition where a process attempts to store data beyond the boundaries of a fixed-length buffer. We create a buffer overflow and the extra data overwrites to adjacent memory locations that we control. At that point we can take control of the device.
How could hackers exploit this vulnerability?
In the case of the iPhone, buffer overflow can occur in a couple of ways. You can send an e-mail with a link in it that points to a Web page that the hacker can then exploit or you can use a bad Wi-Fi connection. In a location like an airport where Wi-Fi networks are common, whenever users access the bad connection to go on the Internet, hackers can infiltrate the Web pages they visit with bad data and exploit the device in that way. When the iPhone’s version of Safari opens a malicious Web page, arbitrary code embedded in the exploit is run with administrative privileges. This code reads the log of SMS messages, the address book, the call history and the voicemail data. It then transmits all this information to the attacker. This code could be replaced with code that does anything that the iPhone can do, like sending the user’s mail passwords to the attacker, sending text messages that sign the user up for pay services or recording audio that could be relayed to the attacker.
What solutions did you provide to Apple?
We sent Apple detailed information about the problem and a patch to correct it. They can use the patch and test it and then push it out in an update. This is a small problem but can have serious consequences if exploited, so we hope Apple takes the information we supplied them and uses it to correct the flaw.
What is the most common security flaw you uncover?
With both devices and software, buffer overflows are very common. We track everything to make sure that the device or software is secure beyond just the client program. A lot of our clients make assumptions with the security of their programs based on user input. The trouble with this is users will stick to the client program, while hackers will stray from it to exploit an application. Fuzzing is an example of not using the real client program, which is why it’s so effective in uncovering security flaws. We encourage our clients to not make any assumptions and make sure they’re developing code that is secure in all stages of the design, development and testing processes. Awareness is the number one issue with security.
Tweet This
9 
