It is good to see some analysis turning up on the exploit front. I was (and still am) surprised that the coverage of this jailbreak has been focused almost exclusively on the jailbreak itself rather than the attack vector and its implications.
The fact that a zero-day remote code execution exploit can be triggered so reliably in every iOS 4 and iPad 3.x device that the creators could drop a cute "Slide to Jailbreak" widget on a web page is alarming. With nothing more than a single rogue link and a bit of Objective C, this exploit could easily be used to produce a worm spread by e-mail or SMS to every contact with a link to the same rogue code, hopping from device to device as users tap an innocent link from a friend. In fact, the action of clicking a link could be bypassed entirely by script injection -- resulting in infection should the user merely browse to a page serving the rouge JS. Considering that the exploit is PDF-based, it's likely that it could also be triggered by viewing a document in Mail.
The prospect of iOS worms is very real, and unless Apple begins to take security more seriously (note that this is the second remote code execution exploit accessible from within MobileSafari, and they've yet to even make a peep about this one), I would not be surprised if we begin to see malware on the platform.
While I agree with your general take on the severity of the problem, I'm going to point out:
* The teardown you've linked to is (a) pretty superficial and (b) wrong (though I see it's now been corrected) --- here I will annoy you by smugly noting that you've linked to an exploit teardown written by someone who thinks it's likely that the iPhone would have been vulnerable to an Acrobat Reader flaw.
* It is not generally the impression I get from vulnerability researchers that the iPhone does a poorer job of defending against remote code execution vulnerabilities than Android; specifically: the iPhone has much stricter (DEP-style) page protections than OSX, and the iPhone has strict code signing.
Does Apple need to take security seriously? Indubitably. But I don't think you can read tea leaves here. Things like this are going to happen to every phone. Let's see how Apple handles it; that, at least, is a signal we can actually discuss reasonably.
Apologies, Thomas - wasn't attempting to hop on the FUD box, proclaim doom, or voice an opinion about the relative security of one platform to another.
I intended the comment to bring a few possibilities to the surface that I've not seen raised elsewhere surrounding an exploit which is otherwise being received by many in the community as a Good Thing.
Thanks for pointing out the error in the (original) write-up I'd linked. Yesterday I found myself telling a friend I thought it unfortunate to see others hopping blame upon Adobe for something they clearly had nothing to do with. If you're aware of a more detailed link to a writeup on the vulnerability in the font file processing, I expect people might be interested to see it.
Agreed. There are dozens of WebKit bugs fixed in every iOS point release. These bugs are usually exploitable on any WebKit browser which includes iOS, Android, and a number of desktop platforms like Safari and Chrome.
It's not the end of the world, but it would be nice to see companies take browser security more seriously.
Charlie Miller suggested that this flaw actually tickles a bug in IOKit, which suggests that it isn't a cross-platform flaw, which makes sense since WebKit doesn't (AFAIK) do PDF.
>the iPhone has much stricter (DEP-style) page protections than OSX
Not sure relative to OSX (or why that relates to Android), however note that Android makes just as heavy of a use of the ARM's NX bit. Gruber recently subtly implied that Android was more reckless about security -- in a blurb about Android 2.2s V8 JIT engine for JavaScript, Gruber offhandedly mentioned that iOS "couldn't" perform such optimization because it barred executable segements -- implying that it didn't have NX-type uses, and he was simply blindly wrong.
And clearly it isn't quite so universal in iOS. This demonstration makes that amply clear.
RPW and Vince from Zynamics wrote a compiler that transforms the REIL intermediate form Zynamics BinDiff/BinNavi tools generate into synthesized stack frames that continually return through fragments of legitimate basic blocks in signed executable iOS code; I believe they're working with fully general programs built in that form, which is to traditional computer programs what Voltron is to Johnny 5.
Which is to say that the cat is thoroughly out of the bag here. All I can point out is, it's not like Apple is totally slacking on the iPhone.
The fact that a zero-day remote code execution exploit can be triggered so reliably in every iOS 4 and iPad 3.x device that the creators could drop a cute "Slide to Jailbreak" widget on a web page is alarming. With nothing more than a single rogue link and a bit of Objective C, this exploit could easily be used to produce a worm spread by e-mail or SMS to every contact with a link to the same rogue code, hopping from device to device as users tap an innocent link from a friend. In fact, the action of clicking a link could be bypassed entirely by script injection -- resulting in infection should the user merely browse to a page serving the rouge JS. Considering that the exploit is PDF-based, it's likely that it could also be triggered by viewing a document in Mail.
The prospect of iOS worms is very real, and unless Apple begins to take security more seriously (note that this is the second remote code execution exploit accessible from within MobileSafari, and they've yet to even make a peep about this one), I would not be surprised if we begin to see malware on the platform.
[ See the original exploit teardown here: http://digdog.tumblr.com/post/894317027/jailbreak-with-pdf-f... ]