Hacker News Reader

Comment by mikeash | Hacker News Reader

This hardly qualifies as an exploit. While it allows the app to do something it's not supposed to do, the ability to download and execute additional executable code doesn't actually violate security. The new code is still restricted to the app's sandbox and can't do anything that the original app couldn't potentially have done directly.

View on HN

It easily qualifies as an exploit, given that Apple's app store model is based on the fact that each app is reviewed beforehand to ensure various properties, including the property that the app does not contain spyware, etc. If Apple approved a harmless app, and then said app downloaded code that snooped on the user's calls or asked for their credit card number, that's an exploit.

First - I think just general manners, as well as established protocol, would have the security researcher let Apple know ahead of time what he would be doing. A simple email sent prior to uploading this code would have been sufficient to cover his bases - I'm surprised he didn't do that.

Second - Unless I'm mistaken - his proof of concept was more a violation of Apples TOU, it didn't really attempt to copy credit card numbers, or snoop on users calls - so, in that sense, it wasn't an exploit.

Net-Net - nobody comes out of this looking good, but Apple makes it clear that they are prepared to back up the language of their Developer TOU with actions.

Part of the security of the app store is the review process. "It's possible to download and execute code" is neat, "it's possible to download and execute code and the app store reviewers don't catch that" is much more impressive.

Nothing in the App Store review process will allow them to catch a zero-day exploit. Coming up with a zero-day exploit in IOS is very impressive - but, by definition, once you have it, the App Store review process isn't going to catch it.

App review ensures no such thing. Put in your spyware with a timer so it doesnt activate for a week. Boom, reviewers don't see it, and users do.

lol...timer!!....really?

Yep. There's no deep check of what your code contains, only a fairly superficial check of what it actually does. You can include nearly anything in your app (perhaps lightly obfuscated) as long as it doesn't show its face during the review.

yes that is indeed true...but why a timer?....you can just query your own web server and figure out what to do.

But yeah if you dont have time to make a small web server the timer idea could also work.

Depends on your level of paranoia and willingness to rely on the network. The server has the advantage of letting you turn it on and off at will, but a timer will work even if the user has no internet connection or your server gets confiscated by the FBI.

I think it qualifies as a great exploit. You totally go around the Private API checks that Apple does. And there is a lot you can do with those APIs that is potentially evil. Even in the sandbox.

It's trivial to bypass those checks anyway.

Running unsigned code is an exploit, my friend.

Why? What can you accomplish by running unsigned code that you can't accomplish by embedding a (e.g.) Python interpreter?

Code signining is a control that is intended to restrict the software that can run to only those apps which have been granted the right to run.

Your second question is a good one, but given is context, it is unrelated. If apple signs a python interpreter, they do so at their peril, for obvious reasons.

Yes, and it's still only running an app which was granted the right to run, it's just that this app now has some extra code in it. Since Apple doesn't really inspect the contents of the apps it signs anyway, this grants no extra capabilities.

Reply on news.ycombinator.com