3 ms·

> Apple has allowed (benign) root exploits to slip through their approval process in the past. Citation please. To my knowledge, Apple has never allowed code

> Apple has allowed (benign) root exploits to slip through their approval process in the past. Citation please. To my knowledge, Apple has never allowed code through the official app store that would jailbreak or root an iOS device. There have been, however, web based exploits that were quickly patched, but you can't really blame this on Apple's approval process. The most notable one of these was the PDF viewer exploit used by jailbreakme.com. This incident seems to prove to me that a curated app store is the best way to keep a large monoculture safe from malware.

ekidd 16y ago
Citation please. [I would like to edit my original remarks, but it appears that I no longer can. So I've upvoted your comment instead.] When I wrote that, I had been thinking of the Handy Light exploit which slipped through the App Store's approval process: http://appshopper.com/blog/2010/07/20/handy-light-tethering-app-camouflaged-as-flashlight/ http://appshopper.com/blog/2010/07/20/handy-light-tethering-... But upon further investigation, I can't find any evidence that Handy Light used an actual root exploit. It may have just been an easter egg which violated Apple's policies using standard APIs. Even if it's not a root exploit, though, there's no cause for celebration. Handy Light shows that the App Store process can sneak major, prohibited functionality onto users' devices in the guise of a clearly useless and trivial app. Apple's biggest advantage may be checking for pirated apps. If Google hadn't allowed obviously pirated apps into the Market, then any attack would have required writing useful, popular applications from scratch, which would raise the bar considerably.
- illumin8 16y ago
  > When I wrote that, I had been thinking of the Handy Light exploit which slipped through the App Store's approval process: Yes, I can see how you would make that simple mistake. The Handy Light application did allow tethering, which on an Android device might have meant rooting it. Other people mentioned in this thread that Apple run each binary through a scanner that looks for undocumented API calls. The Handy Light application must have been using all publicly available API calls, so it passed through their approval process. I think Google could improve dramatically by keeping their store open, but running each binary through an automated scanner that looks for known exploit signatures. I'm not intimately familiar with the Android sandbox, but I am familiar with native assembly. Assuming that there is a public API or list of "approved/sanctioned machine instructions", it would be somewhat trivial to decompile the bytecode and check each instruction against the list and kick the application back to the developer with a list of instructions or API calls that were not allowed.
  - joebadmo 16y ago
    I guess this is the start of the malware arms race, then? I actually already have Lookout installed on my Android phone, that scans every app I install (though I'm actually not sure what the scanning criteria are). Isn't it really moot, though, considering the web exploits? I mean: what is there that you can get with this Android exploit, that you wouldn't be able to with the iOS web exploit?
    - jsf 16y ago
      The difference is that these apps were downloaded thousands of times before being removed. Getting thousands of people to go to your malicious website is probably much harder.
  - jonhohle 16y ago
    Even with a static analysis tool, most of a Cocoa app is dynamic enough to easily get around them. I had an app which relied on a private API (one that was relatively stable, it had been available in Cocoa for years before iOS existed) by simply finding the selector at runtime. Function pointers would be no different.
- Zev 16y ago
  Even if it's not a root exploit, though, there's no cause for celebration. Handy Light shows that the App Store process can sneak major, prohibited functionality onto users' devices in the guise of a clearly useless and trivial app. Any competent iOS developer should be able to think of a handful of ways to sneak past Apple's approval process if they felt like it and had sufficient reason to do so.
recoiledsnake 16y ago
While not a root exploit, I believe this is what the OP was hinting at: http://gizmodo.com/#!5592521/how-a-guy-tricked-apple-with-a-disguised-iphone-tethering-app http://gizmodo.com/#!5592521/how-a-guy-tricked-apple-with-a-... >This incident seems to prove to me that a curated app store is the best way to keep a large monoculture safe from malware. An even better way would be to disallow third party apps at all. There is definitely a trade off between encouraging the ecosystem to grow and fending off malware. If that can be snuck in, is it far fetched to assume that an actual root exploit can't be?
trotsky 16y ago
Clearly, the best way to prevent applications you don't want running on your platform is to prevent applications you don't want running on your platform. The problem comes when the user's opinion of an application they want is different from the platform's opinion. Apple's approach doesn't prevent malware, just limits it to installs by exploit - jailbreakme.com was a very public example of a webkit exploit (I assume) - and there have been plenty of others, including currently active ones. On the other hand, applications that will play by the rules only have the official platform to go through. This means that while malware can and will get through, user desired applications like functional alternate browsers, flash and alternate mp3 stores never will.

ekidd 16y ago

Citation please. [I would like to edit my original remarks, but it appears that I no longer can. So I've upvoted your comment instead.] When I wrote that, I had been thinking of the Handy Light exploit which slipped through the App Store's approval process: http://appshopper.com/blog/2010/07/20/handy-light-tethering-app-camouflaged-as-flashlight/ http://appshopper.com/blog/2010/07/20/handy-light-tethering-... But upon further investigation, I can't find any evidence that Handy Light used an actual root exploit. It may have just been an easter egg which violated Apple's policies using standard APIs. Even if it's not a root exploit, though, there's no cause for celebration. Handy Light shows that the App Store process can sneak major, prohibited functionality onto users' devices in the guise of a clearly useless and trivial app. Apple's biggest advantage may be checking for pirated apps. If Google hadn't allowed obviously pirated apps into the Market, then any attack would have required writing useful, popular applications from scratch, which would raise the bar considerably.

illumin8 16y ago
> When I wrote that, I had been thinking of the Handy Light exploit which slipped through the App Store's approval process: Yes, I can see how you would make that simple mistake. The Handy Light application did allow tethering, which on an Android device might have meant rooting it. Other people mentioned in this thread that Apple run each binary through a scanner that looks for undocumented API calls. The Handy Light application must have been using all publicly available API calls, so it passed through their approval process. I think Google could improve dramatically by keeping their store open, but running each binary through an automated scanner that looks for known exploit signatures. I'm not intimately familiar with the Android sandbox, but I am familiar with native assembly. Assuming that there is a public API or list of "approved/sanctioned machine instructions", it would be somewhat trivial to decompile the bytecode and check each instruction against the list and kick the application back to the developer with a list of instructions or API calls that were not allowed.
- joebadmo 16y ago
  I guess this is the start of the malware arms race, then? I actually already have Lookout installed on my Android phone, that scans every app I install (though I'm actually not sure what the scanning criteria are). Isn't it really moot, though, considering the web exploits? I mean: what is there that you can get with this Android exploit, that you wouldn't be able to with the iOS web exploit?
  - jsf 16y ago
    The difference is that these apps were downloaded thousands of times before being removed. Getting thousands of people to go to your malicious website is probably much harder.
- jonhohle 16y ago
  Even with a static analysis tool, most of a Cocoa app is dynamic enough to easily get around them. I had an app which relied on a private API (one that was relatively stable, it had been available in Cocoa for years before iOS existed) by simply finding the selector at runtime. Function pointers would be no different.
Zev 16y ago
Even if it's not a root exploit, though, there's no cause for celebration. Handy Light shows that the App Store process can sneak major, prohibited functionality onto users' devices in the guise of a clearly useless and trivial app. Any competent iOS developer should be able to think of a handful of ways to sneak past Apple's approval process if they felt like it and had sufficient reason to do so.

recoiledsnake 16y ago

While not a root exploit, I believe this is what the OP was hinting at: http://gizmodo.com/#!5592521/how-a-guy-tricked-apple-with-a-disguised-iphone-tethering-app http://gizmodo.com/#!5592521/how-a-guy-tricked-apple-with-a-... >This incident seems to prove to me that a curated app store is the best way to keep a large monoculture safe from malware. An even better way would be to disallow third party apps at all. There is definitely a trade off between encouraging the ecosystem to grow and fending off malware. If that can be snuck in, is it far fetched to assume that an actual root exploit can't be?

trotsky 16y ago

Clearly, the best way to prevent applications you don't want running on your platform is to prevent applications you don't want running on your platform. The problem comes when the user's opinion of an application they want is different from the platform's opinion. Apple's approach doesn't prevent malware, just limits it to installs by exploit - jailbreakme.com was a very public example of a webkit exploit (I assume) - and there have been plenty of others, including currently active ones. On the other hand, applications that will play by the rules only have the official platform to go through. This means that while malware can and will get through, user desired applications like functional alternate browsers, flash and alternate mp3 stores never will.