Restrictions on what legitimate apps can do within iOS make it impossible for third parties to produce anti-malware software, putting the security onus entirely on Apple.

Kurt Marko, Contributing Editor

July 11, 2011

4 Min Read

By now, security-conscious IT pros know about the new and improved version of the iOS jailbreaking software, jailbreakme, now with iPad 2 support. It ingeniously exploits a flaw in the iOS PDF display code to, via a buffer overrun attack, load jailbreak code into the root file system of the device. Once rebooted, the hacked code injects itself into the device's startup sequence using the video frame buffer as its temporary scratch memory.

What makes this exploit so nefarious is not only its device-independence (it works on everything from the original iPhone and iPad Touch to the latest iPad 2), but that it uses innocuous-looking PDF files, delivered via the browser using Safari's built-in PDF viewer, as its distribution method. While jailbreakers generally know what they're getting into, the same technique could be used more deviously by those with less wholesome intentions to deliver "modified" PDF files via obfuscated URL shortening and a Twitter or Facebook feed. While the specific PDF vulnerability has not been publicly identified, and the current exploit isn't known to have a malicious payload, the technique could easily be used for more nefarious purposes than jailbreaking. As a posting on F-Secure's blog points out:

"A Twitter account belonging to Fox News was recently hacked and used to declare the death of Barack Obama. That hacked account could just have easily posted malicious links. Heck, the links wouldn't even need to be malicious. "We can easily imagine AntiSec hackers tweeting links directly to jailbreak PDF files. When somebody clicks on such a link from their Twitter app, it would open Safari — as Apple doesn't allow for other default browsers — and then Safari would attempt to view the PDF. And then… jailbreak."

So, although the intent and results of this hack appear to be relatively benign (and reversible), it's still interesting and disturbing because of its technique -- an app running in user space that can inject code into the device's root file system -- and distribution method -- untethered, wireless browsing to a site with the malicious payload versus Apple's standard method for kernel modifications using iTunes and DFU (device firmware update) mode. Of course, Apple promises a patch for this iOS vulnerability, and based on the last time this PDF vulnerability was exploited (August), the fix will likely be quick in coming, perhaps even by the time you read this.

However, this incident raises a larger issue: What should Apple's (or any mobile device vendor's) strategy be toward security? While iOS incorporates many security techniques not seen in the more open PC environment, including a tightly controlled, curated application ecosystem, this incident clearly demonstrates that it's still not immune to serious security holes. Since we're on the third iteration of this particular exploit, I'm wondering if Apple should do more than play whack-a-mole, issuing iOS patches in response to the latest hack.

Sure, the reactive approach is the norm; witness Microsoft's monthly Patch Tuesday releases to fix the endless stream of discovered Windows holes. But Apple's tight control of the iOS application ecosystem also means it's impossible for third parties to produce antivirus/anti-malware software. There are too many restrictions on what legitimate applications can do within iOS, such as scanning another app's memory or local storage, to allow traditional A/V techniques to work.

Of course, this is a blessing and a curse. Such tight control over an application's access to the rest of the system is a cornerstone of the iOS security model. However, it also means the security onus is entirely on Apple. Android's more open approach enables third-party security apps, such as AVG, Lookout, and Symantec, to augment native runtime protections built in to the OS with code-scanning and data-protecting features that arguably can catch (or mitigate) zero-day -- read: unpatched -- exploits. Still, I'm not sure which model will work best on mobile devices: Apple's tightly controlled, IBM-mainframe approach or Android's freewheeling, all-comers, Microsoft PC-like paradigm.

If history is any guide, my bet's on the former. How about you?

Black Hat USA 2011 presents a unique opportunity for members of the security industry to gather and discuss the latest in cutting-edge research. It happens July 30-Aug. 4 in Las Vegas. Find out more and register.

About the Author(s)

Kurt Marko

Contributing Editor

Kurt Marko is an InformationWeek and Network Computing contributor and IT industry veteran, pursuing his passion for communications after a varied career that has spanned virtually the entire high-tech food chain from chips to systems. Upon graduating from Stanford University with a BS and MS in Electrical Engineering, Kurt spent several years as a semiconductor device physicist, doing process design, modeling and testing. He then joined AT&T Bell Laboratories as a memory chip designer and CAD and simulation developer.Moving to Hewlett-Packard, Kurt started in the laser printer R&D lab doing electrophotography development, for which he earned a patent, but his love of computers eventually led him to join HP’s nascent technical IT group. He spent 15 years as an IT engineer and was a lead architect for several enterprisewide infrastructure projects at HP, including the Windows domain infrastructure, remote access service, Exchange e-mail infrastructure and managed Web services.

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like


More Insights