Hacker News Reader

Comment by illumin8 | Hacker News Reader

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

View on HN

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

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.

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

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?

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.

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.

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.

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.

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

>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?

Reply on news.ycombinator.com