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 just works!...even though it's not actually supposed to!"
"I'd just like to emphasise that taking a million years isn't a metaphor here..." -Rich Bradshaw
It stands for PeDoFile.
HAND.
"Just don't render it that way." - Adobe
BREAKING NEWS!
Your attention please. We have a very important announcement to make. Listen carefully, because what we have to say MAY SAVE YOUR LIFE!
Today's top story: Hacks can have unintended consequences.
That is all.
Yes, excellent job. Now you just ran an app on your hand held computer that rooted it from a browser. Amazing work of the hackers aside, are you certain you now know for sure your phone is not spying on you and is not going to be used for something you do not want, like someone else using your connection for long distance calls or for spam or DDOS attacks or just a part of some cellular botnet?
Amazing job - someone rooting your phone through a PDF.
You can't handle the truth.
Pardon my language, but, what the fuck?
If my web browser is such that browsing to a page can lead to code execution as root, that's bad. I don't care if the system is open or closed or what government agency might be listening in, it is a serious vulnerability any way you slice it. It should be patched.
Your comment is entirely irrelevant to the post it is replying to. You're phrasing it as a rebuttal of some kind, but it does not say anything to this point.
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...
I looked at the web page for my local newspaper today and it featured two headlines right above one another:
1. iPhone4 Jailbreak Offers Apps to Millions
2. Microsoft Windows Flaw Leaves Millions Vulnerable to Hackers and Malware
I guess we always knew that mass media lives well inside the reality distortion field, but still ...
Genuine question, no sarcasm tag required: How do those who berate Apple's walled-garden approach feel about games consoles? It genuinely puzzles me why we don't hear nearly so many complaints about the lack of open access to consoles, while a similar (to my mind; feel free to put me right) approach to a phone is evil.
As for the exploit that makes this jailbreaking possible, I sympathize with people who wish to jailbreak their phone, but I hope this particular exploit is closed as soon as possible. I've heard there are some unscrupulous types in tha intarweb who might consider using such a thing for less than altruistic purposes.
OK, maybe a touch of sarcasm after all.
The joke is that this so-called "document format" is going way outside its original scope and now supports so much scripting that it might as well be a library for executable files.
I'm going to start sending out all my resumes in dll format... I think it's safer that way...