Filed under: Bugs/Recalls, iPhone
iPhone bug a potential threat?
There's a lot of "could" and "might" in this story, folks, so keep that in mind. MacNN is reporting that a group of iPhone developers has identified a bug in the current iPhone firmware that could lead to an exploit of the Default.png file.
Default.png is what's displayed when an application is launched in the iPhone. Typically it's a static image, but some of Apple's applications use a dynamic file, which could be fooled into granting access to third party code.
This sounds like conjecture to us, and MacNN's sources are not known, so keep that in mind. Plus, iPhone firmware 2.2 is rumored to be released on the 21st. Perhaps it will lock this down.
![TUAW [Cafepress]](http://www.blogsmithmedia.com/www.tuaw.com/media/tuaw-cafepress-promo.png)
Reader Comments (Page 1 of 1)
Richard said 11:48AM on 11-12-2008
I hope this doesn't turn into to much of a problem.
http://twitter.com/richanomix
Reply
hsl said 11:53AM on 11-12-2008
Totally not true,.. For a dutch explanation:
http://pliep.nl/blog/2008/11/iphone_lek_ondermijnt_veiligheid_app_store
and the update:
http://pliep.nl/blog/2008/11/iphone_lek_ondermijnt_veiligheid_app_store_2
simple,.. an iPhone app can't have new files (prefs/cookies) inside the app itself. so every file has a /library and a /temp directory (sandbox) and can only touch the files that belong to the app itself. you can't touch files made by another app because those files are outside the app's sandbox.
It's nog a security flaw, it's not a bug,.. it's normal behaviour, whithout this app's could not save application data/cookies/prefs.
A little more research next time please!
Reply
ars_workerbee said 1:27PM on 11-12-2008
I'm sorry, but you're wrong.
The directory structure includes a Application and Documents folder. The actual app bundle is signed and will not function if it has been modified. However, the "exploit" is to build the app with a symlink in place of the Default.png, that points to a location inside the (changeable) Documents folder.
Theoretically, an app could download files into that folder, and use (probably another) symlink into the Documents folder to then execute the code.
Its a pretty clear violation of the SDK and App Store agreements, though, so I don't expect it to turn into a real issue.
punkassjim said 12:11PM on 11-12-2008
Honestly, I'm not worried about it. Nothing of the sort is likely to get into the AppStore anyway, and honestly, even without the default.png simlink workaround, it's silly to think that programmers don't have a million other ways to launch malicious code from within the app sandbox.
Reply
marcus said 1:04PM on 11-12-2008
with the doubts you have yourself, why run this story.
Reply
KA said 1:17PM on 11-12-2008
So what *is* the bug?
Reply
brian said 1:43PM on 11-12-2008
Although its sounds real, but somehow I am not convinced. I personally dont think it to be a bug at all...and will not an issue for the developers.
http://www.livbit.com
Reply
oz_paulb said 2:38PM on 11-12-2008
Unless I'm blind, this article didn't include a link to the original MacNN article. So, for anyone interested, here's the link:
http://www.macnn.com/articles/08/11/11/app.bug..iphone.security/
The MacNN article doesn't have many more details, but does include another link to the 'original' article at techcrunch.com:
http://www.techcrunch.com/2008/11/11/iphone-exploit-undermines-app-store-security-lets-devs-update-and-run-arbitrary-code/
- Paulb
Reply
Jools said 3:09PM on 11-12-2008
@Paulb
The word "Source" at the bottom of the article links to the original MacNN story.
Opticians?
oz_paulb said 3:14PM on 11-12-2008
@Jools -
Ah, OK, I see it now (but, even after you pointed it out, I had to really look for it).
I've always ignored those 'buttons' (quick glance made me think they were just 'generic' buttons for sharing/printing/emailing an article (nothing specific to a particular article)).
- Paulb
Reply
Kevin Ballard said 3:28PM on 11-12-2008
This is hardly a bug. Basically, the whole thing boils down to you can have symlinks in your app and the codesigning doesn't sign the target of the symlink, it signs the symlink itself. That's not a bug, just a design decision. And it does not allow the app to do anything it couldn't do before - it's always been possible to execute arbitrary code, it's just disallowed by the SDK agreement. This "bug" does not change a thing.
Reply
drunknbass said 5:10PM on 11-12-2008
are all these commenters new to iphone dev? you all realize apple apps dont run in the same sandbox as 3rd party apps and can write to their own bundles and do things YOU cant. im guessing symlinks is one of them, if thats even the "exploit".
hkiphone said 6:12PM on 11-12-2008
Am I right in thinking that this would only be of real concern to those on Jailbroken iPhones downloading/installing apps via Installer, Cydia, or directly via SSH?
Seems that Apple won't vet any apps that act in this way.... or at least I hope they won't let it slip through!!!
Reply
webterractive said 6:17PM on 11-12-2008
who cares!
Reply