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.
App redacted in 3...2...1.
Yay jailbreak.
Enemy lawsuits detected in Sector 3-7!
This isn't really news...I imagine this 'flaw' will be found in every version of iOS until it dies. Not only that, but we should be suspicious of app producers...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.
Joy...oh joy...oh rapture.
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
It's not a flaw, it's a feature!
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...
It was only a matter of time. Since they only do blackbox testing, it should not have taken this long for an app to get approved that waits to do evil until after it is in the wild.
I bet he's recording some sick jams with his unsigned iOS apps.
Give me Classic Slashdot or give me death!
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 ;)
Obviously.
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.
Yeah, this isn't a security issue, it's just something that is possible. It also violates the developer agreement. All this 'news' is doing is pushing Apple to be even more restrictive with their already barbwire enclosed garden...
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.
I'm still torn about security in such appliances. Ideally the user should fully own the device as well as all code running on it, but in practice, users being what they are, having a central control instance may very well be the lesser evil.
With digital devices filling every part of my life now the very thought of being personally responsible for every bit of code running on every one of them makes me shudder. Life is just too short for that.
Do I trust Apple? Not very much. Do I trust Apple more than myself when I haven't got the time to spend more than a few minutes a day to care for each device (and its software) that I own and use? Probably, yes. Sad but true.
The summary says "Apple-approved commands to run in an iPhone's or iPad's memory."
I'm not sure if that's the normal slashdot misunderstanding/hyperbole, if it's another reporter ignorance/flamebait thing, or if that's actually in what cmiller posted.
Apps are Apple-approved. Apps can't use Apple's non-public frameworks. Saying you can't run non-Apple-approved commands is completely inaccurate.
The whole point is that there is a security hole in Apple's security model. What you say is that if there is a bug, it implies the model is inherently broken?
Wow, lots of things are broken down here, trust me on that one.
Write boring code, not shiny code!
It's not more secure (Charlie Miller keeps demonstrating that), but for the typical user (who doesn't know enough about security to judge an app), having a vetting/approval process such Apple's is still offers a safer environment than running completely unvetted apps (such as on the Android stores).
make imaginary.friends COUNT=100 VISIBLE=false
Ignoring ASLR, Sandboxing & the security that naturally comes from a more closed-off (walled) solution.
next time RTFA. it's not at all like what you said.
Some drink at the fountain of knowledge. Others just gargle.
What has been broken here is not the code-signing apparatus per se but another part of the Apple security regimen; it appears this doesn't affect the need to have a valid initial certification to begin with. If the signing mechanism were defeated, that would conceivably allow anyone and his dog to upload and sell apps on the store without registering as a developer. But it isn't. So, in fact, the only people who could leverage this issue for nefarious purposes are people who are already working in the marketplace trying to earn a legitimate dime.
The issue as presented is still as serious (or as not-serious) as outlined, as it allows me as a developer do some pretty wanky things at the expense of the user's trust in my app -- but how many legit developers will risk burning their karma with users (let alone Apple) in order to exercise this? And Apple will have it fixed before any new bad actors get themselves hoisted into place with dev credentials.Am I too optimistic about iOS developers being other than evil miscreants-in-waiting?
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.
There's no place I could be, since I've found Serenity...
Apple's iPhones and iPads have remained malware-free thanks mostly to the company's puritanical attitude toward its App Store: Nothing even vaguely sinful gets in, and nothing from outside the App Store gets downloaded to an iOS gadget.
WTF? Are you serious? Games and apps download data external to the App Store all the time. e.g.: The myFish3D app downloads new 3D models for fish and ornaments from its home site, uselessiphonestuff.com.
It's not more secure (Charlie Miller keeps demonstrating that), but for the typical user (who doesn't know enough about security to judge an app), having a vetting/approval process such Apple's is still offers a safer environment than running completely unvetted apps (such as on the Android stores).
Actually it's less safe.
Users in the "walled garden" have a false sense of security, the security is breached and the users still unquestioningly trust everything from a now untrustworthy source.
Apple has a vetting process that doesn't work. How is that different to an unvetted source?
So essentially, with Android you have unvetted applications, with Apple you have unvetted applications and a user base which is actively ignorant of security issues. Despite the rumours to the contrary, there has been no great Android outbreak precisely because Android users are aware of their own security.
Calling someone a "hater" only means you can not rationally rebut their argument.
So essentially, with Android you have unvetted applications, with Apple you have unvetted applications
Except that Apple do do vetting, and thus do have vetted apps.
You claim it doesn't work. The lesson of 4 years of the Apple App store is that it does work.
Despite the rumours to the contrary, there has been no great Android outbreak precisely because Android users are aware of their own security.
The average Android user is not like you. The average Android user is the average phone user. They're not geeks. They don't understand security. They are exactly the same people that load animated cursors, smily packages and screensavers on their Windows PCs.
There has been lots more malware on Android than iOS.
First, clearly you didn't read my reply to the previous commenter who used the "false sense of security" fallacy. Actually, the "false sense of security" argument can be many fallacies, linked below:
Appeal to belief. e.g. Many people claim it gives a false sense of security, therefore, it must. Show that it actually has that effect before you use it as your premise. A hypothetical premise only gives a hypothetical result.
Begging the question. e.g. Giving people "false sense of security" makes them less safe assumes that they have the knowledge and ability to do something useful to mitigate the risk AND that they would do something different if they didn't have that "false sense of security. However 95+% don't have that knowledge, and evidence is that most don't change their behavior even after they've been informed of the risks. The assumption is false, therefore, the conclusion is fallacious.
Composition. e.g. Because I/we/technical users possess the knowledge and ability to recognize security risks, all users would behave the way I/we would. Your/Our behavior (or theoretical behavior) does not represent what most users will actually do.
Ignoring a common cause. e.g. Users are careless when they think they're safe, therefore, they are careless because they think they're safe. In fact, most users are either always careful, or always careless, regardless of whether they think they're safe.
make imaginary.friends COUNT=100 VISIBLE=false
The Doctor Pwn's the OSX, he keeps his license. The Doctor Pwn's the iOS via Safari, he keeps his license. The Doctor Pwn's Apple's walled garden, and they take his license.
Miller announced the news on Twitter this afternoon, saying "OMG, Apple just kicked me out of the iOS Developer program. That's so rude!"
- cnet.com
Really? You've been around Apple and seen how they react for how many years and you were surprised by this?
'The tyrant will always find pretext for his tyranny.' - Aesop's Fables
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?
I have always thought that executing code on an iOS device in this way was possible I just never thought Apple would actually miss the fact that the app was downloading external code.
Charlie himself stated that he worked for months finding ONE corner-case that Apple didn't catch. It wasn't like this was right there in the open for all to see.
That's not a very good analogy. It only takes 1 armed attacker getting through to make the guard useless. Sitting outside with a shotgun? Is that not why Americans have the right to bear arms? And how would that apply to smartphones?
The same with the flies, I would argue that Google gives you a screen and its up to you to put it up while Apple comes to your house and puts screens on everything without your permission. Now putting a DIY screen might let a few more bugs though than one fitted by a pro, but I doubt you would be so incompetent that they would be crawling over your dinner every day.
After saying all of that I never got any malware on my phone just by not downloading anything that looks useless or dodgy. Also, please provide source for these numbers you speak of so we can all have a look, I'm genuinely curious.
Yep, people need to look at the apps they install and ask them whether they harbor malware. There, the security problem is now deemed solved, we can rest easily from here on out.
I would say that this COULD reduce security to an Android level on a case-by-case basic, but since it isn't nearly as widespread, it isn't the wild west yet.