3 ms·

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 exc

by cscotta 16y ago

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. [ See the original exploit teardown here: http://digdog.tumblr.com/post/894317027/jailbreak-with-pdf-flatedecode-filter http://digdog.tumblr.com/post/894317027/jailbreak-with-pdf-f... ]

vinhboy 16y ago
Yea I find it annoying that coverage is all about "jailbreaking". For gosh sake, they could use this and do drive-by looting of virtually any iPhone.
tptacek 16y ago
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.
- illumin8 16y ago
  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.
  - tptacek 16y ago
    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.
- cscotta 16y ago
  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.
- ergo98 16y ago
  >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.
  - 16y ago

by cscotta 16y ago

vinhboy 16y ago

Yea I find it annoying that coverage is all about "jailbreaking". For gosh sake, they could use this and do drive-by looting of virtually any iPhone.

tptacek 16y ago

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.

illumin8 16y ago
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.
- tptacek 16y ago
  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.
cscotta 16y ago
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.
ergo98 16y ago
>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.
- 16y ago