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."

Comments

Obiwan iPhonebi

[bobdotorg]

I felt a great disturbance in the Smug, as if millions of fanboys suddenly cried out in terror and were suddenly silenced.

Re:Obiwan iPhonebi

[JohnBailey]

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:Obiwan iPhonebi

[Pieroxy]

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:Obiwan iPhonebi

[6Yankee]

*quietly reloads*

Re:Obiwan iPhonebi

[farlukar]

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:Obiwan iPhonebi

[L4t3r4lu5]

Yeah there is. Try saying to one "Actually, you have a point..."

Re:Obiwan iPhonebi

[Anonymous Coward]

Don't you mean the Shiny side of the force?

Re:Obiwan iPhonebi

[Anonymous Coward]

Malware on Unix? Nooo, can't be! :rolleyes:

Re:Obiwan iPhonebi

[Anonymous Coward]

That'll have to wait until they do :3

This isn't any different from any other computer.

[Anonymous Coward]

This isn't any different from any other computer. Users can run software that has access to their personal files.

Interesting sources...

[SuperKendall]

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:Interesting sources...

[SanityInAnarchy]

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:Interesting sources...

[Serious Callers Only]

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 point of access, not scanning for possible violations at one point in the process (apps may not access files when tested for example).

Also I do think apps that need access to address book records should be forced to ask for permission first (as with location), as often users will not want to provide that information and games etc have no business knowing it.

Re:Interesting sources...

[TheRaven64]

Scanning for strings is pretty easy to circumvent. You can just concatenate the path components in code. 'var' and 'mobile' are quite innocuous strings. The same is true for private APIs, by the way, because Objective-C lets you look up both classes and methods by name.

Re:Interesting sources...

[Santana]

That is what SuperKendall said ("Even if you obsfucated the string ...")

Re:This isn't any different from any other compute

[timmarhy]

so apple products aren't secure. could have fooled me with the mind set around here.

Spreading awareness

[CharlyFoxtrot]

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 restrictive but safer. The alternatives here are complete sandboxing of applications or some Microsoft UAS style dialogs all over the place.

Re:Spreading awareness

[netsharc]

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 change the security answers under Settings.

Captcha: paranoia . how apt.

Re:This isn't any different from any other compute

[SJ]

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...

iPhone security doesn't rely on APIs

[iamacat]

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

[Mr2001]

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 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:iPhone security doesn't rely on APIs

[0ld_d0g]

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:iPhone security doesn't rely on APIs

[Rakshasa Taisab]

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:iPhone security doesn't rely on APIs

[iamacat]

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 will ask for permissions.

Re:iPhone security doesn't rely on APIs

[Mr2001]

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 look like someone else's -- but it's hard to see how this would be exploited in practice. Users will (hopefully) be suspicious if they see their favorite app suddenly appear, unrequested, and ask them for a password they've already entered. The malicious app would still need internet permission in order to send that password anywhere, and it may need other permissions to get itself in a position to (e.g. start at boot) mimic another app.

Unless a comprehensive solution is implemented, this is just a security theater in that only legit apps will ask for permissions.

The designers weren't stupid. I suggest you read up on Android security, starting with the link I gave earlier. An app that doesn't request permission for a sensitive operation will be unable to perform that operation.

Re:iPhone security doesn't rely on APIs

[yttrstein]

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. 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.

All of that said, I prefer the iphone. It's an aesthetic choice and has nothing to do with security or functionality, since they're both really pretty much the same logical device.

Re:iPhone security doesn't rely on APIs

[Dog-Cow]

Probably for the same reason 0ld d0g hasn't embraced intelligence. It's not relevant.

Re:iPhone security doesn't rely on APIs

[Anonymous Coward]

Sounds a lot like what the blackberry does.

Re:iPhone security doesn't rely on APIs

[sbeckstead]

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.

Re:iPhone security doesn't rely on APIs

[IamTheRealMike]

MMU based app sandboxing has been adopted on the mobile platform. That's how Android works (and iphone too actually - it just sucks at it).

Re:iPhone security doesn't rely on APIs

[Mr2001]

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 only assume it has access to everything on your phone.

All of that said, I prefer the iphone. It's an aesthetic choice and has nothing to do with security or functionality, since they're both really pretty much the same logical device.

That's fine. You can use whatever device you want. You can even pretend there's no difference in security or functionality if you want, but please don't mislead others into thinking there's no difference.

Re:iPhone security doesn't rely on APIs

[yttrstein]

I didnt say that android made all the same data available, I said they both cache the same things in comparable places. 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. And no, java isn't anything like it. (you'll probably think here that since they have similar syntax I don't know what I'm talking about, but I challenge you to think it through for five seconds)

If your programming is anything like your reasoning, it's become pretty clear why you've ultimately chosen java over C. (++/Obj)

Re:iPhone security doesn't rely on APIs

[Mr2001]

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, then you have no obligation to check it out. But you're doing us all a disservice by pretending to know things about it that aren't actually true.

(you'll probably think here that since they have similar syntax I don't know what I'm talking about, but I challenge you to think it through for five seconds)

You're right, I do think you don't know what you're talking about, but that's because of the falsehoods you've actually written in this thread.

If your programming is anything like your reasoning, it's become pretty clear why you've ultimately chosen java over C. (++/Obj)

There you go again, making a fool out of yourself with your fanboy assumptions. I've been writing C code for 15 years -- but of course that has no relevance to Apple's security holes, now, does it? I don't work for them.

(On the other hand, if you work for Apple, that might explain why they have these security holes...)

Re:This isn't any different from any other compute

[Mr2001]

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:This isn't any different from any other compute

[CharlyFoxtrot]

That's interesting, it's basically using RBAC ?

Closed system

[Anubis IV]

The security the iPhone uses is called a "closed system" and an "approval process," both of which I believe we've heard about here before in great detail, and the attack they're talking about is nothing more than a trojan, essentially. There have already been a few such apps that have sprung up over the years on the iPhone (I recall hearing reports of one that harvested your contacts), but Apple has been quick to squash them so far. Whether that will continue or is even a viable strategy as things scale up remains to be seen, however.

Re:Closed system

[IamTheRealMike]

The problem is that nobody knows if it's really just "a few apps that have sprung up" or if there is actually a systematic problem with apps harvesting your personal details. The companies you're thinking of were busted because they actually phoned the users up themselves en-masse rather than simply (eg) selling the data. The Android approach is far more trustable because it doesn't rely on (very) fallible humans trying to inspect binary blobs.

NSA will love that

[AHuxley]

In the wild Apple product that is as easy as MS.

Re:NSA will love that

[agnosticnixie]

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"

Re:This isn't any different from any other compute

[Serious Callers Only]

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

[mjwx]

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.

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.

No, no, no. This is English.

[Jane Q. Public]

""Swiss iPhone developer Nicolas Seriot presented last night a talk on iPhone Privacy in Geneva"

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:No, no, no. This is English.

[Anonymous Coward]

Nobody cares. English is a terrible language to begin with.

--

I find the streams of 1s and 0s very comforting.... It smells like.. Porn.

Re:No, no, no. This is English.

[Anonymous Coward]

Try this: "Last night in Geneva, noted Swiss iPhone developer Nicolas Seriot presented a talk on iPhone Privacy".

The iPhone was Swiss, and he developed it?
Why was he on iPhone Privacy when he presented this talk?

Worst part: The guy is suddenly "noted". In the original text, he wasn't. You're not just rephrasing - you're editing. You sneaky bastard ;)

I'll just join my fellow anonymous commenter and say that English is a relatively iffy language anyway and although the title was a mess, you'd have to be pretty daft to not understand what was meant (i.e. the ambiguities introduced by the phrasing leads only to alternatives that make no sense).

But if you -have- to rephrase, try:

"Swiss developer Nicolas Seriot presented a talk in Geneva last night about iPhone Privacy"

That still has issues as it leaves out that Nicolas Seriot develops for the iPhone platform; something the original text did indicate. Adding that back in would make the sentence rather convoluted, however.

Better yet... information should be presented from most important to least important, with an interlude:

"An iPhone Privacy talk was presented last night by Swiss developer Nicolas Seriot in Geneva"

Re:No, no, no. This is English.

[intheshelter]

Forest vs Trees? Maybe you could focus on the forest a little more and quit worry about anal grammar corrections?

Re:No, no, no. This is English.

[Phroggy]

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:No, no, no. This is English.

[Anonymous Coward]

Bugger off

Re:No, no, no. This is English.

[Anonymous Coward]

Did you seriously just tell someone not to be unkind in the same breath as suggesting with little evidence that they've never left their country of origin?

How's that glass house doing for you? Any cracks yet?

Re:No, no, no. This is English.

[Phroggy]

The Internet is fun. :-)

Re:No, no, no. This is English.

[ThrowAwaySociety]

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:No, no, no. This is English.

[Anonymous Coward]

Shouldn't the editors on an English-language site be native English speakers?

(what?)

Re:No, no, no. This is English.

[sbeckstead]

"There." Is not a sentence, I though you were using English...

Re:No, no, no. This is English.

[Jay L]

No, Nicolas Seriot did not present a talk to "last night". Nor was was his talk about "iPhone Privacy in Geneva".

And from you, we should take advice?

Re:No, no, no. This is English.

[sootman]

> 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. :-)

Re:This isn't any different from any other compute

[BrokenHalo]

Isn't it more of a case that someone has found a bug, and now it's over to Apple to fix it?

It's not a bug, it's an undocumented feature. ;-)

The simple fact is that people trust phones with far too much information, given their inherent lack of security.

Ummmm...

[ArcadeNut]

Theres an App for that?

Re:Ummmm...

[mgblst]

HAHAHAHA, this gets funnier with every story about the iphone or Apple. Please kill yourself.

Re:This isn't any different from any other compute

[cbhacking]

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.

Who uses Stock iPhones anymore?

[redstar427]

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?

[argent]

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:This is news?

[140Mandak262Jamuna]

You wake up and smell the coffee. The days when you can trust all application developers to play nice are gone. Even when you install an application yourself on your own computer, you have to assume the application is not trusted and set up privileges explicitly about what it can and can't do. The only question is how to specify these privileges in an easy to use and enforceable manner.

Re:This is news?

[Dog-Cow]

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:This is news?

[140Mandak262Jamuna]

The parent was not talking about viruses and trojans. He is talking about knowingly installing an application. Some of the functions of the applications are beneficial and actually desired by the user. So much so that he went to the app store and paid money for it. Then once installed, in addition to doing what it should do, it is snooping around and phoning home personal details. That is more recent.

Re:This is news?

[Triela]

Wake us up when you have a remote exploit.

There's a nap for that.

Re:This is news?

[Tim C]

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:This is news?

[cheros]

.. 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..

Re:This is news?

[sbeckstead]

Ya know I'd rather just use my computer instead of running around trying to make every last bit secure. Privacy is an illusion for a useful member of society and the time i spend not being overly paranoid is more time spent with my family.

Re:This is news?

[sbeckstead]

But you have to pay Verizon a buck for that nap.

Re:This is news?

[IamTheRealMike]

Why are your goals so low? Shouldn't Apple be showing the rest of the industry how it's done?

Re:This is news?

[argent]

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:w00t!

[isama]

Yeah right! macfags and sexual intercourse.. not gonna happen.

Nice idea , but too much hassle for Joe Schmoe

[Viol8]

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:Nice idea , but too much hassle for Joe Schmoe

[DJRumpy]

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 add-on/back door additions to the code would still only have access to those approved functions/files. This is where a closed system is actually a benefit to joe user.

I suspect that when it comes to my phone, I'm a typical iPhone user. I have zero interest in jailbreaking my phone. There are far too many apps out there to do what you need. I don't want to mess with jailbreaking it, permission levels, UAC prompts, or anything else. I just want my phone to work, my browser to browse, and my e-mail/im clients to communicate properly when needed.

As to this article, I don't know why people are surprised. This is no different than any computer, where the user can access their own data, and rightfully so. Unfortunately, since the apps installed are not user created and owned, they are basically trusting a third party with their data just like you and I do on your computer every day. The iPhone, much like most smart phones these days, are arguably more like a PC than a simple phone. They are PC's in your pocket, and all that that entails.

The difference here is that almost EVERY app on the iPhone has some sort of tie to the internet, be that high score publishing, sharing on facebook or whatever. I don't know why that is, but simply restricting or prompting for internet access on each app doesn't seem as viable on a phone as it does on a PC. They obviously need to think a little different for the platform.

Re:Nice idea , but too much hassle for Joe Schmoe

[140Mandak262Jamuna]

True to some extent, and it can be mitigated to some extent by making all default values to "deny" privilege. Unless you convince Mr Joe Schmoe to grant privilege the app wont get anything. Since Joe Schmoe is unlikely to do it, the apps will be developed without assuming such privilege will be available.

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 deployed in large univ environments and corporate environments. Where if a user wants to install an app that needs to be root, he/she has to convince the large IT department why it needs to be root. Since it is difficult to obtain, most apps were developed making sure it would run nicely without being root.

OTOH Windows applications grew in the personal computer environment, and the only user was root. So many applications assumed they will have all the privileges. Of course there were other reasons too, ease-of-use trumping security. The mad scramble marketplace where every application vendor did everything possible to get entrenched. Grabbing all file associations, launching code at start up to give the appearance of fast response time, abuse, overuse and misuse of the registry etc. But without the assumption "all applications will have root privilege" in the early 1990s in the Windows universe, much of the problems would have mitigated.

Re:Nice idea , but too much hassle for Joe Schmoe

[TheRaven64]

If you want to be really depressed, type 'man sandbox' into an OS X system. Not only does the kernel (the same kernel used on the iPhone) have support for fine-grained sandboxing, Apple actually ships a set of five default policies for restricted apps. It would be trivial to provide profiles for games and so on for the iPhone, but for some reason Apple doesn't bother.

Re:Nice idea , but too much hassle for Joe Schmoe

[DJRumpy]

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:Nice idea , but too much hassle for Joe Schmoe

[TheRaven64]

They introduced this mechanism a few years ago, with 10.5. It's used to isolate the mDNS responder (which is why the security hole in that a couple of years ago was a DoS on 10.5 and a remote root hole on 10.4 and Windows), but not much else. It's a real shame that when you download a binary from the Internet they pop up a window when you run it saying giving the choice of running with full privileges or not at all, rather than in a couple of predefined sandbox configurations. I was expecting 10.6 to include this, but somehow they decided to introduce more bugs into the dock instead.

Re:Nice idea , but too much hassle for Joe Schmoe

[FrankieBaby1986]

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 deserve to have some problems happen.

If they wanted a simple device that there's little danger that they screw it up, they would have bought a simple phone, not a 'smartphone'.

So you can't really blame users for treating a gadget thats marketed as simple to use in a simple way.

Sure I can. Again, most cars are fairly simple to operate, but there are still safety procedures and driving practices and laws to learn until one can correctly and safely operate one.

There is no excuse for intentional ignorance. RTFM! :)

Re:Nice idea , but too much hassle for Joe Schmoe

[IamTheRealMike]

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 privileges (usually it was just a mistake). So social pressure from the people who do read the permissions dialog works surprisingly well.

Androids design is actually really clever. It seemed over complicated to me at first, but as time goes by I appreciate it more. The way intents and activities work makes it easy to build "power boxes", ie, re-usable components that are sandboxed differently to the app itself. For instance, maybe your app would like the ability to dial tech support if the user gets stuck and requests help. But you don't want to list "dial phone numbers (costs you money)" permission in your perms dialog. No problem. You can seamlessly invoke the dialer with your chosen phone number, so the user must confirm to dial. Meanwhile, replacement dialer apps can still be written.

In the case of the iPhone I think the dialer example holds too, except of course you can't replace the built in app. But it doesn't generalize, the iPhone security system is clearly full of holes, and Apples approval process is notorious for being bizarre and unpredictable. It has let through apps that violated users privacy unexpectedly before, several times. So all in all it seems like the Android approach is superior - security holes in the system can be OTA updated within days of being discovered, the OS enforces the declared permission set, and social pressure/market ratings are used by a sufficiently large number of users that devs feel pressure to minimize their requested permissions.

Re:Nice idea , but too much hassle for Joe Schmoe

[iamacat]

Are you really suggesting that people should have to take classes to safely download and play games on their cell phone?

Re:This isn't any different from any other compute

[dbcad7]

a cyanide pill should do the trick.

Re:This isn't any different from any other compute

[binarylarry]

It's more like PPBA in reality.

Re:This isn't any different from any other compute

[TheRaven64]

If they can access the keychain, then it is a flaw. The keychain is stored encrypted and controlled by a daemon (which sets the flag preventing debuggers from attaching when it starts). When an app requests data from the keychain, it must be authorised by the user to access that specific key. It is not able to access any other key and the authorisation is invalidated if the binary is modified.

Re:This isn't any different from any other compute

[mcgrew]

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

[Anonymous Coward]

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.

Who Cares

[wzinc]

You have to install the malicious app for it to do anything anyway. The "Send My Data to Hackers" app would not pass approval. Case closed; no big deal.

Re:Who Cares

[Achromatic1978]

Wow.... the Reality Distortion Field is strong with this one.

Uhhh, because yeah, no-one would /ever/ think of embedding such code in a legitimate application, would they?

Oh, wait...

Re:Who Cares

[wzinc]

Ok, then maybe like the "Some app wants to access your location; is that ok?" dialog, they could have a comprehensive dialog that tells you, "This app wants to access your location, contacts, and web history; is that ok?"

At the same time, that moves a lot closer to Vista / Win7 UAC.

Oh no! The computer has my data!

[VeryVito]

The other day I downloaded a contact manager to my iphone, and was shocked and dismayed to realize it had access to all my contacts. Something tells me the personal finance apps I sometimes used might actually have access to some of my financial data! In other words... what a dumb presentation. Of course trusted applications running on a computer will have access to some of the data on that same computer. Otherwise, what's the point? Would saving all this data on your desktop be any safer? How can I live in a world where computers can do things?!!

Microsoft vs Apple?

[dawilcox]

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.

Re:Microsoft vs Apple?

[Anonymous Coward]

Cus when it happens to Microsoft it's because they're lazy corner cutters and when it happens to Apple it's "despite their best efforts".

The day MS come out with something as cool as the iPhone is the day people might start to forgive them for poor security. As it is, it's outrageous that MS release ugly code running on ugly devices AND they don't bother to secure it.

Re:Microsoft vs Apple?

[middlemen]

When something like this happens for other companies, malware is a fact of life.

Nobody likes pissing in their own pool.

Security is like sex.

[argent]

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 letting them be useful is no more than rough mitigation, and no alternative to common sense. The soft chewy center will always be with us on any system containing non-volatile state... even the minimal state associated with web applets has been exploited.

Security is like sex. Once you're penetrated you're fucked.

Re:This isn't any different from any other compute

[Zebedeu]

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 advertisements-supported apps (just disable internet access if it's not required for anything else), but the user would get much better control and security in return.

And this would be why...

[Anonymous Coward]

And this would be why there is an app approval process, controlled by Apple and why you can't just load any app you want onto a non-jailbroken phone...

Apple's review process would see and flag apps such as this and not allow them on the app store, and thus not allow them to be placed onto non-jailbroken phones - thus rendering this entire "exploit" a bunch of bunk.

Not much of an exploit if it can't ever get onto the phones in the first place!

Re:This isn't any different from any other compute

[Anonymous Coward]

Amazing comment. Thanks for the explanation!

Re:This isn't any different from any other compute

[Inda]

I hit my thumb with a hammer once. Make that twice, three times, four... I'll probably do it again in my lifetime.

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.

It is not a desktop computer

[Ilgaz]

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
http://developers.sun.com/mobility/midp/articles/permissions/
http://technet.microsoft.com/en-us/library/cc512651.aspx

In fact, security scene kind of gave up on iPhone&iPod. Let whoever buys makes his/her own mind.

Re:It is not a desktop computer

[sbeckstead]

I don't believe there was any actual content in your post. But I'm not sure. It's still not news and no one is paying for anything. What exactly are you talking about.

J2ME

[Ilgaz]

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.

No worries, you will hear about it

[Ilgaz]

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:No worries, you will hear about it

[argent]

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?

Which MS product? Mobile?

[Ilgaz]

Trust me, it won't be that easy on Windows Mobile. Windows Mobile has a security model similar to Symbian and J2ME.

Worth the read

[mindspring]

Well worth the read. Thanks for sharing this information. I got a chance to know about this.

run, scream, panic! not.

[Sandbags]

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 accesses contact information, account information, or sends and receives data from external sources is HIGHLY scrutinized, far more than other apps. Red flags are reised by scripts and programs analyzing code, and people read THE CODE to see what the app does, in addition to simply using it.

Further, all connectivity in and out of the devices used for app testing is monitored.

Any app entering the apple review process that attempt to copy and distribute user data will be quickly and easily spotted.

In the very early days of the app review process, many of these automated tools did not exist, and several apps that violated apple's policies did slip through. This has been resolved, in the favor of reject first, appeal and release second. Getting an app that violates user security, or steals data, through the app store at this time can basically be considdered a non-existant threat. Even if they could, you still have to convince people to download the app, and run the app, for it to do anything... which means the apps going to actually have to be a developed program with a hidden tojan. Also, any app that accesses contact information or location information has a pop-up by the iPhone OS security subsystem requiring user authorixzation, so an app that does so better have a good reason for doing it the user will believe... ...and what's it going to get? contacts? e-mail addresses? It can't get passwords, it can't monitor your website activity through safari, you have no file system for it to read files in... even IF there was a realeased threat, what it can get is negligible and worthless.

Re:FROSTY P1SS!!1!

[sbeckstead]

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.

Re:This isn't any different from any other compute

[sbeckstead]

Um you actually need access to the keyboard cache for some programs. It's a very useful thing to have. 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. So given that, let's see how many other OSs we can screw up using standard APIs.

Re:This isn't any different from any other compute

[sbeckstead]

something MS had thoroughly bashed into its head over the last decade.

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:This isn't any different from any other compute

[sbeckstead]

You can look at the app's properties and enable/disable each policy,
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:This isn't any different from any other compute

[rsborg]

...Apple still hasn't gotten the wake-up call regarding how paranoid you really have to be for software security...

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 doesn't lead to unusable software/interfaces.

Re:run, scream, panic! not.

[IamTheRealMike]

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 (like a database lookup) but is actually holding encrypted data.

If you really think overworked humans who review many apps every day can do a useful analysis of natively compiled code, I have a bridge I'd like to sell you ....

Re:This isn't any different from any other compute

[Pollardito]

So basically you're saying Android is doing as much as it can do about what it can control, and not much about things it can't control. None of that is good news for Apple who is not doing enough of the former and pissing off a lot of people with their attempts at the latter.

Re:This isn't any different from any other compute

[Zebedeu]

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:This isn't any different from any other compute

[toadlife]

If OSX was on 85% was of the worlds desktops it would be by far the most exploited and exploitable OS in the world.

Re:This isn't any different from any other compute

[sbeckstead]

No more than any other UNIX system is, this is true. Unix has also had the security thing pounded into them but they still make mistakes. What's your point.

Well ignore them, App store interns will save you

[Ilgaz]

My post has links to security models of all 3 smart phone platforms. Sorry if I have broken your "but everything has these problems" Apple apology. No, they don't. They don't trust to fresh idiot interns to run commands like monkeys from a chart, they put actual OS security frameworks/sandboxes and so far, they all work in HUNDREDS OF MILLIONS OF DEVICES from Bangladesh to Sweden.

Capiche?

Re:This isn't any different from any other compute

[mjwx]

I was talking in general.

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.

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 accesses and tells the user (Phone, Internet, GPS, Text messaging and so on), if you click no it will not install the application.

Way to make my point for me...

[argent]

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:

\all the rest

Access to all the other folders is free for all, for example, user's own photos, music, and documents.

This is exactly the same as on a desktop, and even MORE open than what's being complained about in this story.

Re:FROSTY P1SS!!1!

[lamapper]

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 sandbox first.

To be secure takes time (to secure your OS, network and apps), testing, and monitoring. Few people do any of those three, and they pay the price for it.

Its not about FREE, its about control and access. If you do not have control, you are always dependent on others. That is crazy!

Coulda, Shoulda, Woulda

[konohitowa]

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

Granted, the probability of my becoming Prez is likely lower; particularly if my opponents find out that I hang out around here.

Re:This isn't any different from any other compute

[Serious Callers Only]

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 majority of apps don't need the address book for example.

The iPhone is not configurable by the user enough in my opinion - they could do more, which is what this guy is pointing out. Why can't you decide which apps access your phone number or address book? Why can't you limit the access of apps to the file system.

I'd certainly like to, on Windows, OS X and Mobile OS X, but at present the iPhone has some controls but not quite enough in this respect, and the desktop OS's have pitiful access control for normal users (as you point out).

Re:FROSTY P1SS!!1!

[sbeckstead]

I'm not sure exactly what it is you are talking about. You didn't read the summary or the article? If you run a program that you just legitimately installed it can harvest any data in your personal space. Regardless of the OS or security settings. I have no idea what it is you just said.

Re:This isn't any different from any other compute

[sbeckstead]

If it were global it would have made a great way to cut and paste but obviously since that wasn't possible via standard APIs I doubt it was global.

Re:This isn't any different from any other compute

[sbeckstead]

default to a locked down configuration and let me allow them access if I wish.
Wow, sounds like exactly what Vista did and everybody immediately turned off because it was annoying as hell.

Re:Well ignore them, App store interns will save y

[sbeckstead]

Wow, still no actual content that is relevant to the article. Argent here is correct you don't even understand what it is you are defending or why you are bashing me for defending what it is I'm defending, which I wasn't actually defending, I was merely pointing out a small fact that escaped your attention.