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.

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.

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.

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?

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.

"3) Users should be able to trust everything in a curated app store, or else there's not much point to those 30% fees."

Isn't the appeal of Google's app store that it isn't curated? Anyone can sign up and submit anything.

And Apple has never let a "(benign) root exploit" through approval.

Isn't the appeal of Google's app store that it isn't curated?

Yes and no. As a developer, I certainly love the relative ease and freedom of Google's Market. But as user, I don't want to fear clicking "Download" or "Buy". Apple succeeds, in part, because their App Store provides a certain measure of trust, and users are willing to open their wallets.

At a minimum, Google needs to respond quickly to malware reports, and to enforce anti-piracy rules vigorously. Allowing attackers to pirate and republish apps allows them to attack many more users than they could reach by developing malicious-but-popular applications from scratch.

And Apple has never let a "(benign) root exploit" through approval.

Yeah, I think that was an incorrect statement on my part. Apple has passed major, hidden functionality that violates their policies, but I was mistaken in thinking a root exploit was involved. For a mea culpa, see the thread at http://news.ycombinator.com/item?id=2279823

>Isn't the appeal of Google's app store that it isn't curated? Anyone can sign up and submit anything.

Android allows installing apps from sources other than the Market, so this isn't that big a deal. A free-for-all app store does have disadvantages, like app spam, rampant copyright infringement, and apparently malware.

Isn't the appeal of Google's app store that it isn't curated?

That's the appeal for some developers, but probably not for most users.

> Isn't the appeal of Google's app store that it isn't curated? Anyone can sign up and submit anything.

If you're a "I like to let anyone install anything in my phone" kind of person, I suppose so.

The root exploit appears almost incidental here - without it the application could do everything it was doing merely by requesting those permissions at install time. The vast majority of people would install it without checking.

Here's some examples of iOS apps doing similar things without requiring a root exploit:

The threat is not theoretical. Several iPhone apps have been pulled from the App Store after being found to be harvesting user data, intentionally or unintentionally. A game called Aurora Feint was uploading all the user contacts to the developer's server, and salespeople from Swiss road traffic information app MogoRoad were calling customers who downloaded the app. Game app Storm8 was sued last fall for allegedly harvesting customer phone numbers without permission, but it later stopped that practice. And users also complained that Pinch Media, an analytics framework used by developers, was collecting data about customer phones.

http://news.cnet.com/8301-27080_3-10446402-245.html

" 3) Users should be able to trust everything in a curated app store, or else there's not much point to those 30% fees."

Exactly. Google is trying to clone the Mac App store without doing the legwork to justify their cut.

• Curation should include safety

• Curation should include some sort of fair promotion

I'm skeptical of the benefits of these "curated" app stores and their high fees but at least Apple does the work to back up taking their cut.

And they've jacked up their cut of the take by 6% over Apple. Apple's 30% is quite enough but an increase of 6% added on top of 30% is just ridiculous.

A higher percentage for far less value.

> Apparently, Google has an unofficial policy of ignoring copyright and trademark complaints

I have no personal experience with this, but Google makes it very clear that a DMCA notice is the appropriate action in this situation:

http://www.google.com/support/bin/request.py?contact_type=lr...

I've read a bunch of sob stories lately from iOS and Android app developers, and they never say they've sent a DMCA takedown notice that's gone unanswered. Under US law, this is the way to respond to copyright violations. Sending a generic complaint means very little.

He said in his comment that he sent a DMCA notice.

Just to be clear, the guy on Reddit also said that Google responded to the DMCA notice, which counters the claim the GP was responding to, specifically the the claim that Google ignores copyright complaints.

That said, it's true that they won't respond to anything except a valid DMCA notice. Anyone who sends anything else is provided with instructions on how to file a valid DMCA notice last I knew.

3) Users should be able to trust everything in a curated app store, or else there's not much point to those 30% fees.

Wait a second - does Google curate the Android market or charge 30% fees?

I don't know about the curation, but the fees are real, according to this:

http://market.android.com/support/bin/answer.py?answer=11262...

Does Google take that fee, or does it go to the mobile carrier?