Slashdot Mirror
iPhone Jailbreak Uses a PDF Display Vulnerability
adeelarshad82 writes "Latest reports indicate that the website that 'jailbreaks' iPhones, iPads, and iPod Touches does so by means of a PDF-based vulnerability in OS X. PDF parsing and rendering is a core feature of OS X, and there have been several other vulnerabilities in the past in iOS CoreGraphics PDF components." As Gruber points out, the proper term for this is not "jailbreak," but "remote code exploit in the wild."
It's a bug in the font rendering component, which apparently lives in kernel space. PDFs are allowed to embed fonts, and apparently Preview doesn't verify the font data before tossing it to the renderer. Apparently the renderer doesn't verify it either, because instead of rejecting the data as invalid, it gives the attacker completely unrestricted control over the software.
PDFs having embedded fonts is a very useful and entirely reasonable feature. It would help if Preview validated the fonts, but that's not entirely required (you could validate somewhere further down the pipeline, so long as you don't try to process the unvalidated data). There are several other ways to remotely load fonts, ranging from other document formats to the Web Open Font Format (http://www.w3.org/Submission/2010/03/) and some CSS in a web page. There's a decent chance that at least a few others are vulnerable to this exploit. However, there's been considerable research recently into Apple's PDF reader, with one researcher finding 60 different exploitable bugs in the software (though most of them probably aren't kernel). By comparison, the same testing data found three exploitable bugs in Adobe Reader.
Having font rendering/rasterizing in the kernel is... not brilliant, but not inherently a critical security flaw. It's certainly possible to do in userland, and probably safer, but displaying text is something that almost every app will need to do at some point, and putting it in the kernel will minimize memory footprint and maximize performance. The real WTF here is that the data isn't being validated extremely carefully as soon as it enters the kernel, and possibly before. When kernel-mode code starts parsing unvalidated data, the best you can really hope for is that you get a kernel-mode crash and are forced to do a hard reboot (on Windows, this would be a BSOD).
There's no place I could be, since I've found Serenity...
Not only is it native, it's really, really insecure. A security researcher named Charlie Miller wrote a 5-line Python script to generate fuzzed (slightly corrupted) PDF files from valid templates. He created roughly 2.8 million of these, and then ran them through Apple's Preview program, and through Adobe Reader. His findings:
0.09% crash rate on Reader, and 4 exploitable bugs found.
5.6% crash rate (52x as many), and 61 exploitable bugs found (15x as many).
When your security is more than an order of magnitude worse than Adobe's, you've got a major problem.
By the way, this is the guy who won an iPhone at Pwn2Own. He's presented at CanSecWest and Blackhat, and possibly elsewhere. He knows his stuff.
There's no place I could be, since I've found Serenity...