Slashdot Mirror
Malware Could Grab Data From Stock iPhones
Ardisson writes "Swiss iPhone developer Nicolas Seriot presented last night a talk on iPhone Privacy in Geneva. He showed how a malicious application could harvest personal data on a non-jailbroken iPhone (PDF) and without using private APIs. It turns out that the email accounts, the keyboard cache content and the WiFi connection logs are fully accessible. The talk puts up several recommendations. There is also a demo project on github."
I felt a great disturbance in the Smug, as if millions of fanboys suddenly cried out in terror and were suddenly silenced.
__ Someday, but not this morning, I'll finally learn to use the preview button.
There's actually not much surprising here (at least for an iPhone developer) but two things were interesting:
1) It can read EXIF data from your image library (including GPS tags if any) by just reading the library directly. In theory you are not supposed to do that, and go through an API - which annoyingly gives you only raw image data with no EXIF.
2) Your "location" is reported, without the dialog that normally arises asking you if you want to reveal your location. Alarming at first, until you look and realize what it's really done is found the last location Maps knew about. Since you don't run Maps all the time this data really doesn't mean that much and is not real time as you get with real CoreLocation calls.
One other thing of note is that a great deal of this involves poking about in /var/mobile/... at preference and temporary files. Given that Apple is now scanning for strings in app review, I'm not sure if an app that included these techniques would actually make it to the app store. Even if you obsfucated the string the filesystem could simply report if anything under that directory were being accessed and what the call stack was like, though I think it unlikely they would go to these lengths.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
so apple products aren't secure. could have fooled me with the mind set around here.
If you mod me down, I will become more powerful than you can imagine....
Isn't it more of a case that someone has found a bug, and now it's over to Apple to fix it?
Or is that just applying far to much logic to an Apple related topic...
It depends on manual app approval process and ability to ban/sue developers who abuse the system. There is probably also a kill switch to delete the app from existing devices that Apple hasn't yet had to activate for catastrophic malware. Runtime-enforced security has been tried with J2ME and nobody liked the app functionality. In fact people are not willing to live with Java's limitations on desktop either. Perhaps someday such a system will become viable with much more powerful mobile hardware and better thought out security system that allows more functional legitimate apps (for example, user will be able to give an app access to some or all e-mail as an intuitive option).
It is different from Android, actually. Android runs each app under a separate user ID, and one app can't access another app's data unless the other app explicitly allows it to. Typically this access will go through the standard Android permission system, so the user will see when they install the app that it's requesting permission to read their SMS logs or whatever.
Visual IRC: Fast. Powerful. Free.
No, it's a case of a binary with permissions being able to access public APIs (as intended). Most platforms currently have this problem in some form - if you run an authorised program you must trust the author to some extent, though I think Android has some better controls. So they really need a chance in policy rather than to fix a bug (though perhaps filesystem access to user prefs could be considered a bug).
Apple have sandboxed apps, so they can't access data from other apps or the main system (save user prefs) unless it's through public APIs.
What this article points out is that those public APIs provide access (because it is useful, and sometimes essential for apps tp function) to your address book, phone number etc. and also to the file system for your user, under 'var/private/mobile' which lets you see the system prefs (most of which are accessible via private apis anyway). The keyboard cache (though without passwords) is worrying though, so this is a hole that needs fixed.
What Apple could do is offer more fine grained control (as they do with location services for example) so that apps cannot access data like phone numbers without explicit permission from the user. Obviously this needs some thought, as the last thing you want is a forest of permission dialogs for each app when it starts up, but it's certainly doable without much trouble. The file system access to system preferences would probably need to be locked down too.
However this is not some new security breach or bug - it's been known about since day one, but it is something that needs to be pointed out repeatedly until Apple fixes it, because most users will not be aware of it, and it does have privacy implications.
Note that apps we run on our desktop systems (Mac, Windows, Linux) currently have few such controls and have access to a lot of data about us which we might prefer to keep private - similar sandboxing is required there too.
Whilst I'm not disagreeing with you, Android has a very good security model and enforcing separate UID's and permissions is essential towards that but... This still wont stop the less intellectually endowed users from just clicking yes and permitting malware to read their private data.
To paraphrase Ron White, there is no pill to fix stupid, you cant fix stupid and neither can Google.
In other words we'll still suffer from the stupid acts of moronic users, the good part is that more astute users will suffer from less attacks.
Calling someone a "hater" only means you can not rationally rebut their argument.
This baby is overclocked and water cooled, running at 2.3 Ghz!
It's so fast when talking on the phone, my friends sound like Alvin and the Chipmunks.
"Two things are infinite: the universe and human stupidity; and I'm not sure about the universe." Albert Einstein
Just like on Windows , your non techie user is just going to end up learning a pavlovian response to any such permissions dialog and just click OK no matter what. Yes , you can blame the user but ultimately these are supposed to be simple to use gadgets for people who have more important (to them) things in their life to worry about than application access permissions they probably don't even understand. So you can't really blame users for treating a gadget thats marketed as simple to use in a simple way.
No, it's a case of a binary with permissions being able to access public APIs (as intended). Most platforms currently have this problem in some form - if you run an authorised program you must trust the author to some extent, though I think Android has some better controls.
Blackberries have very granular access controls. When an application tries to do something it isn't authorized to do, the user is asked for permission (or these permissions can be allowed/denied at the server level).
Everything from access the gps, access email, sms, address book, http connections, https connections can be allowed/denied separately.
So google maps on my blackberry is configured to connect to google (to download maps), but nothing else. It can't connect to the internet at large. This greatly reduces security concerns.
Why is it that every time something like this is discovered for Microsoft, it's their fault because they should have provided a more secure operating system. When something like this happens for other companies, malware is a fact of life.