Malware Could Grab Data From Stock iPhones 127
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."
This isn't any different from any other computer. (Score:2, Informative)
This isn't any different from any other computer. Users can run software that has access to their personal files.
Interesting sources... (Score:5, Informative)
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.
Re:This isn't any different from any other compute (Score:5, Informative)
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.
Re:iPhone security doesn't rely on APIs (Score:5, Informative)
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
It's already here, and it's called Android. When you install an app, it tells you what permissions [android.com] the app is requesting, and you can cancel if you're suspicious. Most operations that you'd consider potentially harmful or privacy-violating (reading various types of personal data, accessing the internet, making phone calls, preventing the phone from sleeping, etc.) can only be performed if the app listed the relevant permissions in its manifest.
It's not perfect... you know what the app is capable of doing, but not what it actually will do. Without looking at the code, you can't tell if the app that requests "read GPS position" and "access the internet" is going to send your GPS position to someone over the internet, or if the two features are unrelated. But it does prevent surprises like the ones in TFA.
Closed system (Score:4, Informative)
Re:This isn't any different from any other compute (Score:5, Informative)
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.
No, no, no. This is English. (Score:4, Informative)
No, Nicolas Seriot did not present a talk to "last night". Nor was was his talk about "iPhone Privacy in Geneva".
Try this: "Last night in Geneva, noted Swiss iPhone developer Nicolas Seriot presented a talk on iPhone Privacy".
There. Fixed that for you.
This is news? (Score:4, Informative)
You install an application on your computer. That application has access to stuff stored on your computer. This is news?
Wake us up when you have a remote exploit.
Re:Interesting sources... (Score:3, Informative)
Re:This isn't any different from any other compute (Score:4, Informative)
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.
Way to make my point for me... (Score:3, Informative)
My post has links to security models of all 3 smart phone platforms.
You obviously didn't read any of them. For one example, here's the data security model for Symbian:
This is exactly the same as on a desktop, and even MORE open than what's being complained about in this story.