3 ms·

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 h

by 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.

by ekidd 16y ago

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.