We have stumbled across a flaw in iPhone security that allows third party developers to update and execute arbitrary code from their applications at will, totally circumventing Apple’s App Store approval process. Normally, applications (and all of their updates) have to go through a lengthy review process before they’re posted to the App Store, as Apple combs through them to ensure they don’t do anything malicious or otherwise violate its Terms of Service. This exploit may give developers free rein.
The exploit stems from a benign trick that would otherwise seem trivial to most iPhone users. Whenever you launch an iPhone application, an image called ‘Default.png’ is briefly displayed while the app loads in the background. Applications developed in-house by Apple are able to use dynamic ‘Default.png’ images, which can be modified to do a number of things, like show the current date or display the contents of the app before it’s done loading. Until now third party developers have been stuck with static ‘Default.png’ images that could not be changed after the app had been installed. To get around the restriction, developer Patrick Collison figured out a workaround that tricks the iPhone’s code signing mechanisms into giving devs access to these dynamic launch images (for a full description of the trick, read his blog post).
But after digging deeper into this trick and consulting with a few iPhone developers, we believe that this could have much more significant (and potentially harmful) applications. Typically the iPhone’s API prevents developers from loading code in unsigned areas, but this image hack (which manipulates symlinks) makes the iPhone believe that the code it is loading came from a “trusted” (i.e. permitted) source. Using the same technique with arbitrary code would likely allow a developer to update and execute whatever code they’d like at will.
We should note that developers generally have the freedom to arbitrarily update and execute code on other platforms that don’t have an approval process, including desktop Windows and Mac machines. But consumers have long been trained to be wary when downloading new software to these platforms – on the App Store, everything has Apple’s stamp of approval, so this discretion is often thrown to the wind as users get promiscuous and try out every app they can get their hands on.
Fortunately, it’s unlikely that any apps currently on the store have already implemented this exploit, so if Apple can fix things quickly before accepting any more applications, your iPhone shouldn’t be at risk.
Update: We’ve gotten a number of comments stating that this may not be as serious an issue as we thought – while it is a legitimate bug, there are other ways to bypass Apple’s screening process to later invoke malicious code, and none of them have been an issue thus far. We did verify the exploit with a number of experienced iPhone developers, but may have overstated its significance.
Apple should hop on this quick. There’s even more problems living out there though, like Apps getting cracked. Check this out:
http://tinycomb...ers-fight-back/
Uh, this isn’t an exploit, and doesn’t really change anything. There’s nothing stopping a developer today from building a “time-bomb” type app, with code paths changing at some date in the future (for example) and doing some malicious thing. Doing essentially the same thing by way of fancy symlink tricks is unnecessarily complicated. Either way, no app is capable of running “rm -rf /”. Apps are jailed, they have limited access to phone resources.
Yeah I took the rm -rf thing out, not sure how many people would get it anyway. The apps would still be sandboxed but there are definitely still issues, especially with private data.
So, the security risk you “believe” is that a signed application, reviewed and posted on the store, might specifically choose to make itself vulnerable by loading unsigned code from its own bundle. Assuming code loading follows symlinks.
Then Apple’s review process that everyone’s complaining is too restrictive might decide to overlook this little trick and forgive the clear violation of terms.
Then an attacking app would find a way to write to that unsigned code.
This gets a skull-and-crossbones and “rm -rf /” graphic? Really?
No, the risk is more likely that someone would create an apparently benign app that they could later update with malicious unsigned code.
Let’s step out of the “vague hypotheticals” cocoon for a minute. Be specific: what sort of malicous code? What would it do?
More to the point: why would anyone do this, considering it could be traced back to the offending app?
iPhones are the new Windows 95. Good luck Apple!
Funny how this lame ass story got burried…. I think after reading the comments of people Mike noticed that he’s a bit off…
http://www.tech...e-ads/#comments
It sounds like a potential risk in principle, but has anyone actually demonstrated it with a real piece of exploit code? Generally, an exploit is considered to be just speculation until someone has actually demonstrated it with a running proof of concept.
Another point is that from your description, the only people in the position to exploit the weakness are people who Apple has performed some vetting and identity verification on – at least to the point of having bank details.
A seriously malicious use of this weakness if it really does exist would be likely to have an easier starting point for prosecution than most, and that is likely to deter anybody but well organized criminals.
Apple LOVES to lock stuff down this bug in the codesign binary won’t go long without with being patched.
Big deal.
Apple doesn’t do source reviews. They just run the app, make sure there is nothing against the ToS (as far as they can see), and make sure it doesn’t crash for the most part. They ran my NameTag application for 9 minutes, which consists of exactly two screens. They ran another more complex application of mine for 7 minutes.
Make it past that and the developer is able to do anything they’d like to do. Apple can’t really check and enforce malicious activity, unless it’s discovered through general usage. Putting it on a timer, or after X number of application open/closes, and you can basically run whatever malicious code you’d like.
The only catch, of course, is that each application is sandboxed and can only harm itself.
exec*() returns ENOPERM in the jail. It’s very easy to copy an unsigned binary to the phone without this “exploit”, but that doesn’t mean you’ll be able to easily run it.
Applications can always embed a script interpreter, and it may be possible to load and jump into arbitrary code, but there’s very little Apple can do about that.
The fact is, as Jonathan George noted, you don’t need to load code at a later time to do something evil. Simply delay activation of Evil Feature until some later time.
Additionally, the sandbox protects other applications on the phone from Evil App, but it doesn’t protect the local network. What’s to stop an Evil App from providing access to an external party to your home network?
Apple attempts to identify software authors before permitting their applications in the store, but this is not foolproof.
The correct spelling is “rein” not “reign.”
Melodrama mashed into “news” is funny. One could create an exploit that bricks the phone and the reason for doing this would be?
And the profit from all that work would be? Sound a bit stoopid.
I’m still waiting for ExploitCrunch to demonstrate the iTools/.Mac/MobileMe email address harvesting exploit… who would have expected you would move on to other made up risks?
Not really a risk. How many iPhone users are smart enough to implement this hack anyway? Like 2% of all iPhone users. The rest are snotty nosed kids from Orange County who can’t tell the difference between a tree and a lead pencil.
Dwayne.
http://probablysucks.com
This article is so wrong it boggles the mind.
Every app had already been able to load files from outside the signed bundle, and for instance download files and store them outside the signed bundle.
Every app has its own little piece of file system, including a /Library, /tmp and other directories that are not inside the bundle and can be written, read and deleted at will by the app.
That is not a security issue, that is intended design. Applications MUST store prefs, downloads and other data outside the signed app bundle or else the signature would no longer be valid.
About the Default.png trick: being able to open an image from outside the app bundle is nothing new and it is not scary and not a risk.
I have developed several iPhone apps an call bullshit and FUD on this “article”.
I even tried to, get access to Safari’s cookies from within an app that way and it does not work: the app CANNOT access anything from outside its sandbox.
The points you raise are red herrings.
The issue is executing unsigned code, and this bug allows you to do that.
This article is a fail. Unless there’s a hole in the sandbox, there’s no issue.
“…while it is a legitimate bug, there are other ways to bypass Apple’s screening process to later invoke malicious code….”
It is NOT a legitimate bug. It is normal functionality to access files outside of the signed bundle. This is intended behaviour.
STOP spreading FUD and STOP lying.
It is a legitimate bug in the sense that it would allow you to bypass Apple’s approval process. You can debate whether or not that’s a security problem (as opposed to merely subverting Apple’s rules), but it’s certainly a bug that will be fixed.
Other easy ways to bypass Apple’s security screening:
- Have your app ping your web server when it starts. If the ping returns “0″, display a game with happy little elves. If the ping returns “1″, eat the user alive. Ensure that the server always returns “0″ while your app is being reviewed by Apple.
- Read the current date. For one month, display the happy little elves. After a month has gone by, eat the user alive.
Apple’s vetting is not nearly as thorough as people seem to think it is. You don’t need to pull off clever security hacks to run unsigned code. Just hide the evil functionality, and Apple will sign it for you!
OMG, I’d better go remove that happy little elves game!
actually, the reason it will not “rm -rf /” is because /dev/disk0s2, which is the place that AppStore apps run, is mounted as nosuid. that means any code running on it will not be able to get root access.