Hacking The iPhone, iPod, And iPad With A Web Page

What Does Jailbreakme Do?

TH: So if jailbreakme.com didn’t provide a progress bar, could this have been done without the user’s awareness?

Charlie: Certainly. The jailbreakme Web site does not try to hide its actions. It is performing a service for the user. A malicious site would run this code in the background and you wouldn't know it.

TH: And if the payload was smaller, say sending passwords or personal information, it could have happened almost instantaneously?

Charlie: Yes. Making permanent changes to the phone, like jailbreaking, is time consuming. But stealing information like contacts, SMS messages, and emails would happen in less than a second.

TH: Let me put a black hat on for a second. How do we know that this vulnerability, which exists in previous versions of iOS, hasn’t been exploited in a targeted fashion somewhere? In June, we had the leak of over 100,000 iPad owners' email addresses, including CEOs and government officials. Could someone have sent one of them a link to a malicious site, which then installed spyware or other malicious code?

Charlie: There is no way to know whether this vulnerability has been exploited in the past.  

TH: Scary stuff. How can we be sure that no existing application available through the App Store does not somehow install a rootkit? We’ve seen SOCKS proxies sneak through the official App store in the past, and there’s the whole story of the Android Wallpaper App stealing private info?

Charlie: So…an App Store app could theoretically use the same privilege escalation exploit to break out of the sandbox and install malware. As a professional reverse engineer and code auditor, I can say that it would be impossible for Apple to audit all the applications that pass through the App Store. They can only do their best and try to restrict the API’s used by the applications, but this can be bypassed. Recently, someone included an application in the Android Marketplace that included a local privilege escalation exploit and rooted the phone.

TH: So it’s possible that an app could do this?

Charlie: It is possible that an app could do this, although as far as I know, no app in the App Store has ever done it.

TH: Why doesn’t the ARM XN-bit, also known as NX-bit or XD-bit, prevent overflows like this?

Charlie: Before Data Execution Prevention (DEP), buffer overflows would redirect execution of the process into user-injected code or shellcode. However, DEP forbids this, as the processor knows that the injected code is data, which is not supposed to be executed. As a way around this, exploits use what is known as return oriented programming (ROP). Here, instead of jumping to user-injected code, the exploit jumps to code from the actual process. In this case, code within MobileSafari and the libraries it needs. By reusing little bits of code from the process, the exploit is able to perform the actions necessary to do general purpose actions.  

TH: So, to understand this correctly, iOS does have some form of DEP, and this prevents arbitrary injection of user code. But the way around it is to use bits and pieces of legitimate code--the equivalent of a ransom note made out of cut up newspaper letters?

Charlie: Yes, the iOS implementation of DEP is very good. The ransom note analogy is a perfect analogy, originally attributed to rapper @drraid’s girlfriend. You take pieces of existing code and glue them together in a way that suits you, but wasn’t intended by the designer.

TH: What about technologies like ASLR and stack randomization? Would that have been a solution?

Charlie: Yes, in general, ASLR defeats return oriented programming by randomizing the location of the resident code, which the exploit would like to reuse. If the exploit cannot find the code to reuse, it cannot use ROP. iPhone does not have any ASLR; all addresses are completely known by an attacker if you know the firmware version of the device.