Slashdot Mirror
Charlie Miller Circumvents Code Signing For iOS Apps
Sparrowvsrevolution writes "At the SysCan conference in Taiwan next week, Charlie Miller plans to present a method that exploits a flaw in Apple's restrictions on code signing on iOS devices, the security measure that allows only Apple-approved commands to run in an iPhone's or iPad's memory. Using his method, an app can phone home to a remote computer that downloads new unapproved commands onto the device and executes them at will, including stealing the user's photos, reading contacts, making the phone vibrate or play sounds, or otherwise using iOS app functions for malicious ends. Miller created a proof-of-concept app called Instastock that appears to show stock tickers but actually runs commands from his server, and even got it approved by Apple's App Store."
Update: 11/08 02:54 GMT by U L : Not unexpectedly, Apple revoked Miller's developer license.
It could also lead to people deveoping unapproved apps and selling them to people on the black market - and thus, with the wall breached, the Apple hegemony fell and there was much rejoicing!
"Yea!"
A feeling of having made the same mistake before: Deja Foobar
Most of the article was quite puzzling, as this is nothing new or remarkable. It's really quite simple to have your application execute stuff it downloads.
If I can reverse-engineer the uninformative article a little, I would hazard a guess to say that he's found a way of bypassing the NX bit protection using Safari as an attack vector. This means that he would be able to inject arbitrary ARM code that wasn't present on the device at review time, meaning that he could execute code against APIs that the application wasn't originally using (but which are available for applications to use legitimately).
As an attack, it sounds real enough, however in real-world terms, Apple's review process is leaky enough to avoid getting caught anyway. Their review consists of some trivial automated checks and everything else is handled by a human reviewer who just looks at the application from an end-user's point of view. During the submission process you have to include instructions on how to trigger any Easter eggs in your application because they wouldn't otherwise find them.
Bogtha Bogtha Bogtha
So long as iOS apps are developed using a language that allows pointer access, including function pointers, people are going to find and exploit bugs like this. It's actually a really interesting parallel to homebrew development on Windows Phone (yes, I have one, in addition to a few Linux devices - no iOS ones though): you can do native code on WP7, but you have to use COM to access it. Microsoft prohibits ISVs from using the COM import API from C#/VB in marketplace apps, so they can very easily block this kind of thing by just checking for references to a few specific APIs (they also block the use of C# "unsafe" pointers).
Now, I'm not exactly advocating that Apple needs to re-design their entire applicaiton model. However, the fact remains that the way they do it, it's almost impossible to really verify that any given app isn't doing something like this, short of code-reviewing the source of every submission and rejecting any that are too hard to understand (completely impractical). It means they *are* vulnerable to malware, though - even from the "trustworthy" marketplace.
There's no place I could be, since I've found Serenity...
> This isn't really news
Actually it is. The way these things get fixed are by making people aware of the problem. No software is absolutely bug free. As much as some people would like to stick their fingers in their ears and say "la-la-la not a problem...", there are just as many us who would like to fix the issue. So, yes this is news.
Join the Slashcott! Feb 10 thru Feb 17!
Except, it gives a false sense of security. With Android (or PC) apps, I know that there's a risk of malware, so I'm cautious. With iOS - well, I don't have one, but I imagine there are lot of people who think "it *can't* have malware, Apple checks everything!" and therefore completley trust anything in the app store.
The purpose of work like this is to demonstrate that Apple has misled those people; you can't simply trust everything. The only thing worse than an obviously untrustworthy app source is an untrustworthy app source that *appears* to be trustworthy.
There's no place I could be, since I've found Serenity...
Did or did you not notice that the whole point of what Charlie Miller did was that the sandbox was breached, despite ASLR, and he was able to do it from an app allowed into the walled "solution"?
Please explain how an app store that is unable to detect malware but *claims* to be inherently secure is actually more secure? If anything, I see it as the opposite - it will delude people (like yourself) into thinking it's safe, when it's actually not. Android, by comparison, is acknowledged to have malware - meaning people need to be more cautious about the apps they install.
I think the numbers of actual malware on the two platforms speak for themselves. And in iOS' case, Apple-haters certainly can't claim "security through obscurity" or "lack-of-marketshare" excuses.
And I, for one, would rather have a guard who repels 99.99999999999999% of enemies, than me having to stay up every night with a shotgun in my hand, protecting my home and my loved ones.
Window screens don't stop all insects; but take them away, and pretty soon, all you'll have time to do all day, every day (and every night) is swat flies. Which would you prefer: The occasional gnat in your beer, or having flies crawling all over your dinner, every single day?