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's a feature, not a bug. But who was the intended beneficiary?
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.
What does this have to do with code signing? Sounds like the entire security model is busted on these devices. I don't care if an application is 'signed' or not -- what I want is a security model that absolutely forbids all permissions unless specifically granted.
This is not rocket science.
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
You're programming it wrong!
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!
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.
When it happens to a Windows device it's called a "security vulnerability" and when it happens to an iOS device it's a "feature"?
Seven puppies were harmed during the making of this post.
FTA:
”Android has been like the Wild West,” says Miller. “And this bug basically reduces the security of iOS to that of Android.”
Lolz.
https://www.accountkiller.com/removal-requested
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.
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
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?
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.
There is no such thing as perfect software, only inadequate testing.
Using a program called Rootstrap, [John Oberheide] showed how an innocent-looking Android app could download and run malicious code after making its way onto a user’s phone. (He used a fake Twilight-themed application to demonstrate the potential attack.)
That isn't fair; why only target the unintelligent demographic for your proof-of-concept?
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
That would be like saying that since you aren't actually slewing the wheels round yourself, but instead having to go through the linkages of the steering wheel and train, that the car's wheel has more control of your car than you do.
Anyhow, with trusted computing, the program that implements the control has more control over the device than you. So no change there. However, you have ceded the control of that controlling program over to another party.
Think Sony CDs. Think NSA backdoors.
Will it keep the doctor away?
Weird. I was on some dotcom or other website the other day and people were pissing and moaning about nannying software . . . what a bunch of dumbasses those guys were at any rate. The responses over here are MUCH smarter . . . app review, app follow-up, "walled garden" in quotes all being a bad idea; why aren't you guys running corporations?
One question: why did the dev that violated ToS, now trying to profit by talking to Forbes and give a talk on it getting kicked out only get an 'update'? This is slashdot, we're running low on apple stories, it should be it's own article. The EFF should take this to the supreme court. He paid for his membership fees, if you pay to eat at IHOP, you should damn well be allowed to crap on the table when you're done.
Apple is obviously the problem here.