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."
Obiwan iPhonebi (Score:4, Funny)
I felt a great disturbance in the Smug, as if millions of fanboys suddenly cried out in terror and were suddenly silenced.
Re: (Score:3, Insightful)
I felt a great disturbance in the Smug, as if millions of fanboys suddenly cried out in terror and were suddenly silenced.
Don't be daft.. Nothing can silence fanboys.
Re: (Score:2)
I felt a great disturbance in the Smug, as if millions of fanboys suddenly cried out in terror and were suddenly silenced.
Don't be daft.. Nothing can silence fanboys.
You are right, for the bright side of the force shall prevail !
Re: (Score:2)
Re:Obiwan iPhonebi (Score:5, Funny)
I felt a great disturbance in the Smug, as if millions of fanboys suddenly cried out in terror and were suddenly silenced.
Don't be daft.. Nothing can silence fanboys.
Even the exploits just work!
Re: (Score:2)
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.
Re:This isn't any different from any other compute (Score:4, Funny)
Re:This isn't any different from any other compute (Score:5, Insightful)
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...
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.
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.
Re: (Score:2)
Re: (Score:2)
Um you actually need access to the keyboard cache for some programs.
Of course, but I wonder if it should be a per-application cache rather than storing all sorts of strings from all apps (I think it is global). That would make more sense, and remove any possibility of malicious use.
There is very little difference between what happens here and in any other OS using standard APIs I can really screw up a windows box if you will just run my program.
Agreed, but that doesn't mean we shouldn't look for something better. I would welcome the chance to restrict desktop apps with policies I decide myself as to which data etc they can access on my computer - default to a locked down configuration and let me allow them access if I wish. The vast maj
Re: (Score:2)
Re: (Score:2)
Wow, sounds like exactly what Vista did and everybody immediately turned off because it was annoying as hell.
Re:This isn't any different from any other compute (Score:4, Insightful)
When you consider what Jailbreak *is* (root-level exploit) I thought this was already fairly well established? Especially when you consider how quickly each successive jailbreak has been released, and how little effort some have required. Say what you will about their histories, but Apple still hasn't gotten the wake-up call regarding how paranoid you really have to be for software security - something MS had thoroughly bashed into its head over the last decade.
Keyboard cache is a good example - turns out that the keystrokes entered during bootup (such as to enter a hard drive decryption passpharse/PIN) remain in memory and can be retrieved after the system has booted. Obviously, this is a problem for things like TrueCrypt, and Microsoft's BitLocker. Except, by the time the vulnerability was revealed, Microsoft had already fixed it. That kind of twisty thinking is what Apple has yet to show any particular knack for.
Re: (Score:2)
And yet they are still by far the most exploited and exploitable OS in the world. Simply knowing about the fact that you need to be secure does nothing to protect any users.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
And how paranoid do you have to be? It's silly. Any lock can be opened, there is no such thing as complete security.
Apple is still making money hand over fist and there's yet to be an iPhone malware released that actually compromised a large number of users' data.
I bet their security team is really paranoid, but have to deal with their usability and other teams to make sure that the paranoia d
Re: (Score:2)
so apple products aren't secure
"Secure" is a relative term. My house is reasonably secure from burglars, but compared to my bank it's not secure at all. Compared to a lean-to in the woods my house is incredibly secure.
There is no such thing as absolute security, but Mac users don't have to worry about picking up a virues just by surfing the internet. Neither do Linux users. Apparently, iPhone users do in fact have to wory about having info stolen; at least until they fix this design flaw.
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: (Score:2)
That's interesting, it's basically using RBAC ?
Re: (Score:2)
It's more like PPBA in reality.
Re:This isn't any different from any other compute (Score:5, Insightful)
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.
Re: (Score:2)
Re: (Score:2)
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.
Which to me is a missing feature in Android -- the ability to enable/disable each permission individually.
As it stands now, you're presented with a laundry list of permissions which the app requests upon installation, and you either accept it wholesale, or cancel the installation.
I think Java ME does it correctly. You can look at the app's properties and enable/disable each policy, and even set it to ask once, or everytime that feature runs.
Sure, this would break the business model of most of those advertis
Re: (Score:2)
Until you make the whole app useless and you might as well not install it. If you are in fact knowledgeable enough to know what all those things are anyway.
Re: (Score:2)
I guess the app would install normally with full access, but you'd have an advanced preferences screen where you could set these options.
I don't agree with the idea of limiting important functionality because of novice users.
Re: (Score:2)
Can you, as an astute user, claim that you've never hit OK to a dialog by mistake? Maybe you were expecting one dialog, but received another.
Re: (Score:2)
We've all done that, which was your point.
Android lacks a centralised place to enable/disable permissions, to be fair Android is less then 2 years old and I'm certain there would be a third party program that could do this.
However the permission system in Android works when you install an application Android checks which API's it access
Re: (Score:2)
Re:This isn't any different from any other compute (Score:2)
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: (Score:2)
the filesystem could simply report if anything under that directory were being accessed and what the call stack was like,
...only if they managed to exercise all of the code. So, you couldn't actually download and execute code remotely, but I bet you could trigger something based on a date, or on some web service.
Based on how randomly they seem to accept and reject apps these days, I wouldn't be surprised if a few made it through.
Re: (Score:3, Interesting)
One other thing of note is that a great deal of this involves poking about in /var/mobile/... at preference and temporary files....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.
They'd be better just to lock down access to the files which apps have no business accessing directly - get system apps to save their preferences elsewhere for example, or restrict permissions artificially for sandboxed apps via the filesystem apis and refuse access to all files except the sandbox. That way even if someone gets past the filters (that's a game of whack-a-mole really, and the current controls are easy to defeat) they cannot access the files.
They need to move to restricting access fully at the
Re: (Score:3, Informative)
Re: (Score:2)
That is what SuperKendall said ("Even if you obsfucated the string ...")
Spreading awareness (Score:2)
It's great that there are those making people aware of what data might be accessed by malicious apps on any platform. The question is can this be avoided ? Restricting the data this app was able to access would also stop applications from doing some pretty useful things: accessing the address book, reading files on the filesystem, autocomplete (this is the keyboard cache mentioned), accessing pictures, etc. This is a balancing act between allowing enough freedom to produce good software and being too restri
Re: (Score:2)
Actually the dialogs-way is the way BlackBerry does it, usually with an option to "Don't show this again", i.e. "always say yes" or "always say no". It does this for many features like contacts reading, access to the messages (apps can hook and get a notification each time a new message arrives), and even telephony (yes the API actually lets you send DTMF tones). There's an extra layer, apps accessing protected APIs must be digitally signed, so they have your identity (just like Apple does). And you can cha
iPhone security doesn't rely on APIs (Score:5, Insightful)
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).
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.
Re: (Score:2)
When you install an app, it tells you what permissions [android.com] the app is requesting, and you can cancel if you're suspicious.
I thought 'security through user awareness' had been shown to be a fail paradigm.
Re: (Score:2)
When you install an app, it tells you what permissions [android.com] the app is requesting, and you can cancel if you're suspicious.
I thought 'security through user awareness' had been shown to be a fail paradigm.
It is because most users don't know what those permissions mean to them.
Nice idea , but too much hassle for Joe Schmoe (Score:5, Insightful)
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.
Re: (Score:2)
I prefer an Apple controlled approach. Why don't they authorize apps with certain access levels, so if an app is submitted and indicates it needs ACL access to the FS, and the Internet, then I would prefer that Apple runs some Apple owned and signed script that blesses that app with access to those areas, specific files, and so on. I don't want to see UAC popups on my iPhone. Seems like if these apps were given controlled acl access only to those items that they submitted and were granted, that even later a
Re: (Score:2)
Re: (Score:2)
Disappointing. If the infrastructure is already built in, you would think it would be somewhat trivial to enable and enforce those policies.
Odd that they haven't done so already.
Re: (Score:3, Interesting)
Re: (Score:2)
In fact this is one of the fundamental reasons why *nix applications run nicely with user privileges and the Windows applications barf if root privileges are not available. The *nix was originally deploy
Re: (Score:2)
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.
Sorry, but these are not simple gadgets any more so than a motor vehicle is a 'simple gadget'. ANY complex computing and/or net-connected device deserves as much respect in use as driving a motor vehicle on the highway.
There is a minimum amount of understanding required to safely operate a motor vehicle, and there is considerable potential harm that can come to oneself or to others in both scenarios.
If people don't take the time to learn about the device and it's proper and safe operation, they de
Re: (Score:2)
Are you really suggesting that people should have to take classes to safely download and play games on their cell phone?
Re: (Score:2)
Well, there are a couple of things to note here.
The first is that yes, some users will not read what is in front of them no matter what you do. Such is life.
The second is that Androids implementation of this dialog is about as good as you'll ever get. I wrote an Android app and was very surprised at how many queries I got regarding permissions. There have been several cases whereby app devs shipped apps that listed permissions they clearly didn't need, and then uploaded fixed versions with minimized privile
Re: (Score:2)
How exactly are the permissions enforced? Did Google implement some kind of filesystem with application-specific ACLs? Was there a serious effort to close the backdoors, such as updating another apps shared libraries or reading GPS coordinates from system logs? Are applications prevented from taking over the whole screen and mimicking another app's interface to trick users into entering their passwords?
Unless a comprehensive solution is implemented, this is just a security theater in that only legit apps wi
Re: (Score:2)
How exactly are the permissions enforced? Did Google implement some kind of filesystem with application-specific ACLs?
Each app gets its own user ID and has no read access to files owned by other apps. To obtain data from another app, you have to go through the system-wide content provider interface. The other app has to actively support that, and it can enforce permission checks on the caller in code and/or in its manifest.
Was there a serious effort to close the backdoors, such as updating another apps shared libraries or reading GPS coordinates from system logs?
Yes. One app can't overwrite files belonging to another app, and system logs aren't world readable.
Are applications prevented from taking over the whole screen and mimicking another app's interface to trick users into entering their passwords?
Not exactly -- apps always take up the whole screen, and the system can't stop you from making your app
J2ME (Score:2)
J2ME which Android was based on had that concept for years. It is a J2ME concept, you know, the VM which trendy developers ignore for years while it is well beyond 700M installed base.
Re: (Score:2)
It is a fact that "Little-Linux-Variation" (android) is precisely as insecure and for all the same reasons as "Little-BSD-Variation" (iphoneos). They both cache all the same things and in comparable places, and data in both is protected either by virtue of being in a binary database, or by virtue of POSIX style permissions.
That's an interesting theory, but maybe instead of speculating based on how you think the two systems work, you should learn how they actually do work. Android does not make all the same data available to every application that the iPhone OS does.
Apple does its best to scrub the malware out of the app store, and the open source community does its best to scrub the malware out of the android lexicon. Traditionally, both approaches have just about the same affect: the vast majority of binaries for both platforms are safe, but a few arent.
The difference is that as soon as you install an Android application, you know which potentially harmful features it has access to: if it doesn't request permission to read your contacts, then you know it won't read your contacts.
With an iPhone application, you can
Re: (Score:2)
I didnt say that android made all the same data available, I said they both cache the same things in comparable places.
You said they were both equally insecure because of that. What you ignored, and what you're still dancing around, is the fact that iPhone grants access to that data, without notifying the user, and Android doesn't. That has real security implications.
And yes, I did break open android for as long as it took to realize that you can't write for it in C or anything like it.
Actually, these days, you can. The NDK was released months ago, and people were unofficially writing native code even before then. (You still need to write some Java code, but e.g. emulators can do all the heavy lifting in C.)
If you're not interested in Android
Re: (Score:1)
What happened to MMU based security? User & Kernel address space division seems to work for desktop OSs. Why hasn't it been adopted for the mobile platform?
Re: (Score:2)
Probably for the same reason 0ld d0g hasn't embraced intelligence. It's not relevant.
Re: (Score:2)
Closed system (Score:4, Informative)
Re: (Score:2)
NSA will love that (Score:2)
Re: (Score:2)
I'm sure they'll be enchanted to switch to it on such a vague, misleading report : "if it's as insecure as the windows we use, surely we can trust it with the security of the nation"
Which MS product? Mobile? (Score:2)
Trust me, it won't be that easy on Windows Mobile. Windows Mobile has a security model similar to Symbian and J2ME.
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.
Re: (Score:2)
If you'd step outside your own borders once in awhile, you'd recognize this sentence structure as something that works in a foreign language, but has been translated into English by a non-native speaker. Constructive criticism is useful, but please don't be unkind.
Re: (Score:2)
If you'd step outside your own borders once in awhile, you'd recognize this sentence structure as something that works in a foreign language, but has been translated into English by a non-native speaker.
Yes, hence the subject line.
Constructive criticism is useful, but please don't be unkind.
What part of that post was "unkind?" It was a fairly straightforward, if blunt, explanation of why the sentence structure makes its meaning ambiguous and how it could be clarified.
Re: (Score:2)
The Internet is fun. :-)
Re: (Score:2)
Re: (Score:2)
And from you, we should take advice?
Re: (Score:2)
> There. Fixed that for you.
Hmm, I'm looking for the joke, but either I'm not seeing it or it wasn't funny.
Oh, wait, you actually fixed it for him. Gotcha. Nice work. :-)
Ummmm... (Score:2)
Theres an App for that?
Re: (Score:2)
HAHAHAHA, this gets funnier with every story about the iphone or Apple. Please kill yourself.
Who uses Stock iPhones anymore? (Score:4, Funny)
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.
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: (Score:2)
Re: (Score:2)
Viruses and trojans have existed since the days of the original Apple, Commodore and Atari home computers. The days you allude to never existed.
Re: (Score:2)
Re: (Score:2)
Actually, you described exactly what a trojan is - an app that performs (or claims to perform) a desirable function, but surreptitiously also performs an undesirable one.
Re: (Score:2)
.. with the added bonus of getting money for that installation too, allow me to omit the obligatory Microsoft joke in this context.
I think the primary -dangerous- underlying assumption is that an app you pay for is somehow safer..
Security is like sex. (Score:2)
The days when you can trust all application developers to play nice are gone.
They were gone before the Internet was called the Internet.
If you install every application that shows up on your computer without paying any attention to what you're getting... you're going to be sorry. I've cleaned up enough malware from people's computers over the past twenty years to know that.
If an application has the ability to do useful things, it has the ability to do dangerous things. Sandboxing applications while still le
Re: (Score:2)
It is not a desktop computer (Score:2)
It is news on smart phones which started with lessons learned from Desktop and mobile trojans themselves. Apple ignored those lessons and now paying for it.
http://wiki.forum.nokia.com/index.php/Symbian_Platform_Security_Model [nokia.com]
http://developers.sun.com/mobility/midp/articles/permissions/ [sun.com]
http://technet.microsoft.com/en-us/library/cc512651.aspx [microsoft.com]
In fact, security scene kind of gave up on iPhone&iPod. Let whoever buys makes his/her own mind.
Re: (Score:2)
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.
Re: (Score:2)
No worries, you will hear about it (Score:2)
One day, one dirty rival of Apple or a psychopath will use one of these "theoretical" exploits which Apple keeps ignoring for years. You won't need to check news that day, your newspaper won't simply arrive since the Quark/Indesign Machine they use won't function.
I don't hope for it but Apple is really inviting it...
Re: (Score:2)
You won't need to check news that day, your newspaper won't simply arrive since the Quark/Indesign Machine they use won't function.
What's a newspaper?
Re: (Score:2)
Re: (Score:2)
Shouldn't Apple be showing the rest of the industry how it's done?
You want to mind meld Steve Jobs and Theo Deraadt?
Re: (Score:2)
Microsoft vs Apple? (Score:4, Insightful)
run, scream, panic! not. (Score:2)
Apple may not have the best approval process based on how engineers review apps for functionality, but this is NOT the only process apps go through...
Apple has a whole series of programs that crawl the source code of each app (which is how apps are submitted, not in compiled form). First of all, they look for apps that touch unapproved APIs, and summarily reject them (with thus far 1 exception noted recently, and they were told not to include that function in their next release...) next, any app that acce
Re: (Score:2)
No, what you say is wrong.
Firstly, Apple examine binaries not source code. Secondly, they're looking for non-malicious usage of private APIs. It's quite easy to build dynamic/obfuscated code that their simple symbol dump process can't detect. Thirdly, as the presentation notes, nothing stops an app from changing its behavior after it was reviewed based on an internet fetch, or date. Fourthly, I don't know how you can think data transfers are "monitored". It's easy to hide data such that it looks boring (lik
Coulda, Shoulda, Woulda (Score:2)
Yes, malware could grab data from stock iPhones in much the same way that I could be President of the United States. Wikipedia has the scoop, plus a lot of other juicy details, here: http://en.wikipedia.org/wiki/United_States_Constitution [wikipedia.org]
Granted, the probability of my becoming Prez is likely lower; particularly if my opponents find out that I hang out around here.
Re: (Score:2)
Uhhh, because yeah, no-one would /ever/ think of embedding such code in a legitimate application, would they?
Oh, wait...
Re: (Score:2)
You can actually do the same thing with every operating system out there. So suck it non Apple fan boys! There are even demo apps for android and windows mobile.
Actually your statement is only true for proprietary operating systems and proprietary applications on proprietary hardware.
If you use Linux or Unix and have "root" access (sudo, su or acutal root, with a strong password of course) then you have the ability to go in and figure out what piece of garbage code has opened you up to the world. Not saying everyone could do this, only that you have a shot at it.
This is also why you NEVER auto update, auto install ANYTHING, without adequate testing in a sandbo
Re: (Score:2)