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
...they say "only install apps from trusted publishers"...yeah...ok...so, no one? If I did that, I'd have only the pre-loaded apps.
And I'd have zero.
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
Somebody hacked one of Michael Kristopeit's accounts and used it to post a useful comment! The world is at an end.
The external sources are probably web pages. The web page can be javascript-free right up until the app is approved, so I don't see how this can prevent it.
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!
Yes it is actually. How do you implement an API that guarantees that you go through that API to get access to something. It doesn't matter if you build your lovely "you don't get permission to anything unless the gatekeeper agrees" system, if you can simply go "we'll I'm ignoring the gatekeeper and jumping through this hole in the wall". That's what a security flaw actually is ;)
That's the definition of trusted computing - it trusts someone else, and not the owner. So that someone else, or anyone who compromises them, gets to control your device before you do.
The app in question has already been pulled from the App Store. And I'm quite sure the flaw that allows executing code via some hole in Safari will be fixed very soon. iOS 5 supports delta updates now, so Apple can (and will) come with small updates much more often than in the past.
Unless he's figured out how to sign apps such that the OS thinks they are from Apple, and aren't. Then Apple would have to revamp their code signing system.
I don't know, but it works for me.
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...
App redacted in 3...2...1.
But one has to think, if this application was approved, how many other approved applications in the App Store have some form of malicious code or other surreptitious data collection?
It seems the only reason Apple noticed this is because Charlie Miller published it.
This is why Apple's security model is fundamentally flawed. It provides a single point of failure for security. Those of us who work with networks understand that gateway only security doesn't work, so trusting the gateway to get everything and pretending you are secure behind your gateway is foolhardy in the extreme.
Calling someone a "hater" only means you can not rationally rebut their argument.
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?