Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Malware Could Grab Data From Stock iPhones

timothy posted more than 4 years ago | from the swamp-of-bog-standard dept.

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

cancel ×

127 comments

Sorry! There are no comments related to the filter you selected.

FROSTY P1SS!!1! (-1, Flamebait)

Anonymous Coward | more than 4 years ago | (#30321366)

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.

Apple made a shit security decision. Suck it, Apple fanboys!

w00t! (-1, Troll)

Anonymous Coward | more than 4 years ago | (#30321622)

Fuck Steve Jobz! Fuck all Macfags!

XD

Re:w00t! (1, Flamebait)

isama (1537121) | more than 4 years ago | (#30322326)

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

Re:FROSTY P1SS!!1! (0)

sbeckstead (555647) | more than 4 years ago | (#30326004)

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.

Obiwan iPhonebi (4, Funny)

bobdotorg (598873) | more than 4 years ago | (#30321398)

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 (3, Insightful)

JohnBailey (1092697) | more than 4 years ago | (#30321448)

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 (1)

Pieroxy (222434) | more than 4 years ago | (#30322018)

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 (1, Funny)

Anonymous Coward | more than 4 years ago | (#30322966)

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

Re:Obiwan iPhonebi (1)

6Yankee (597075) | more than 4 years ago | (#30322472)

*quietly reloads*

Re:Obiwan iPhonebi (5, Funny)

farlukar (225243) | more than 4 years ago | (#30322474)

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 (1)

L4t3r4lu5 (1216702) | more than 4 years ago | (#30322502)

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

Re:Obiwan iPhonebi (0)

Anonymous Coward | more than 4 years ago | (#30325592)

That'll have to wait until they do :3

Re:Obiwan iPhonebi (0)

Anonymous Coward | more than 4 years ago | (#30323192)

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

This isn't any different from any other computer. (2, Informative)

Anonymous Coward | more than 4 years ago | (#30321416)

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 (4, Funny)

timmarhy (659436) | more than 4 years ago | (#30321456)

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

Re:This isn't any different from any other compute (4, Insightful)

SJ (13711) | more than 4 years ago | (#30321474)

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 (5, Informative)

Serious Callers Only (1022605) | more than 4 years ago | (#30321720)

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 (4, Informative)

Anonymous Coward | more than 4 years ago | (#30323288)

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

Anonymous Coward | more than 4 years ago | (#30324284)

Amazing comment. Thanks for the explanation!

Re:This isn't any different from any other compute (1)

sbeckstead (555647) | more than 4 years ago | (#30326070)

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 (1)

BrokenHalo (565198) | more than 4 years ago | (#30322060)

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.

Re:This isn't any different from any other compute (3, Insightful)

cbhacking (979169) | more than 4 years ago | (#30322094)

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

sbeckstead (555647) | more than 4 years ago | (#30326106)

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 (1)

rsborg (111459) | more than 4 years ago | (#30326402)

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

mcgrew (92797) | more than 4 years ago | (#30323240)

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 (5, Informative)

Mr2001 (90979) | more than 4 years ago | (#30321496)

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 (1)

CharlyFoxtrot (1607527) | more than 4 years ago | (#30321558)

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

Re:This isn't any different from any other compute (1)

binarylarry (1338699) | more than 4 years ago | (#30322904)

It's more like PPBA in reality.

Re:This isn't any different from any other compute (4, Insightful)

mjwx (966435) | more than 4 years ago | (#30321752)

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.

Re:This isn't any different from any other compute (1)

dbcad7 (771464) | more than 4 years ago | (#30322766)

a cyanide pill should do the trick.

Re:This isn't any different from any other compute (1)

Zebedeu (739988) | more than 4 years ago | (#30323910)

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.

Re:This isn't any different from any other compute (1)

sbeckstead (555647) | more than 4 years ago | (#30326164)

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 (1)

Inda (580031) | more than 4 years ago | (#30324430)

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.

Re:This isn't any different from any other compute (1)

TheRaven64 (641858) | more than 4 years ago | (#30323138)

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.

Interesting sources... (5, Informative)

SuperKendall (25149) | more than 4 years ago | (#30321440)

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... (1)

SanityInAnarchy (655584) | more than 4 years ago | (#30321726)

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... (2, Interesting)

Serious Callers Only (1022605) | more than 4 years ago | (#30321762)

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... (2, Informative)

TheRaven64 (641858) | more than 4 years ago | (#30323204)

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.

Spreading awareness (1)

CharlyFoxtrot (1607527) | more than 4 years ago | (#30321466)

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 (1)

netsharc (195805) | more than 4 years ago | (#30322128)

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.

iPhone security doesn't rely on APIs (4, Insightful)

iamacat (583406) | more than 4 years ago | (#30321490)

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 (5, Informative)

Mr2001 (90979) | more than 4 years ago | (#30321620)

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

Rakshasa Taisab (244699) | more than 4 years ago | (#30322070)

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 (1)

sbeckstead (555647) | more than 4 years ago | (#30326280)

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 (4, Insightful)

Viol8 (599362) | more than 4 years ago | (#30322382)

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 (1)

DJRumpy (1345787) | more than 4 years ago | (#30323102)

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 (1)

TheRaven64 (641858) | more than 4 years ago | (#30323256)

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 (1)

DJRumpy (1345787) | more than 4 years ago | (#30323304)

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 (2, Interesting)

TheRaven64 (641858) | more than 4 years ago | (#30323400)

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 (1)

140Mandak262Jamuna (970587) | more than 4 years ago | (#30323132)

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 (1)

FrankieBaby1986 (1035596) | more than 4 years ago | (#30325240)

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 (1)

IamTheRealMike (537420) | more than 4 years ago | (#30326812)

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

iamacat (583406) | more than 4 years ago | (#30322640)

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 (1)

Mr2001 (90979) | more than 4 years ago | (#30322884)

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 (1)

yttrstein (891553) | more than 4 years ago | (#30323108)

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.

J2ME (1)

Ilgaz (86384) | more than 4 years ago | (#30325294)

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

Anonymous Coward | more than 4 years ago | (#30325710)

Sounds a lot like what the blackberry does.

Re:iPhone security doesn't rely on APIs (1)

0ld_d0g (923931) | more than 4 years ago | (#30321640)

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 (1)

Dog-Cow (21281) | more than 4 years ago | (#30323374)

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

Closed system (3, Informative)

Anubis IV (1279820) | more than 4 years ago | (#30321646)

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 (1)

IamTheRealMike (537420) | more than 4 years ago | (#30326850)

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 (1)

AHuxley (892839) | more than 4 years ago | (#30321668)

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

Re:NSA will love that (1)

agnosticnixie (1481609) | more than 4 years ago | (#30322096)

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? (1)

Ilgaz (86384) | more than 4 years ago | (#30325380)

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. (3, Informative)

Jane Q. Public (1010737) | more than 4 years ago | (#30321926)

""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. (0)

Anonymous Coward | more than 4 years ago | (#30322026)

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. (0)

Anonymous Coward | more than 4 years ago | (#30323528)

Bugger off

Re:No, no, no. This is English. (0)

Anonymous Coward | more than 4 years ago | (#30323008)

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. (1)

intheshelter (906917) | more than 4 years ago | (#30323060)

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. (1)

Phroggy (441) | more than 4 years ago | (#30323242)

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. (1, Insightful)

Anonymous Coward | more than 4 years ago | (#30323816)

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. (1)

Phroggy (441) | more than 4 years ago | (#30324194)

The Internet is fun. :-)

Re:No, no, no. This is English. (1)

ThrowAwaySociety (1351793) | more than 4 years ago | (#30325026)

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. (0)

Anonymous Coward | more than 4 years ago | (#30326114)

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

(what?)

Re:No, no, no. This is English. (1)

sbeckstead (555647) | more than 4 years ago | (#30326328)

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

Re:No, no, no. This is English. (1)

Jay L (74152) | more than 4 years ago | (#30326676)

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?

Ummmm... (1)

ArcadeNut (85398) | more than 4 years ago | (#30322082)

Theres an App for that?

Who uses Stock iPhones anymore? (4, Funny)

redstar427 (81679) | more than 4 years ago | (#30322216)

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? (3, Informative)

argent (18001) | more than 4 years ago | (#30322294)

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? (1)

140Mandak262Jamuna (970587) | more than 4 years ago | (#30323172)

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? (1)

Dog-Cow (21281) | more than 4 years ago | (#30323402)

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? (1)

140Mandak262Jamuna (970587) | more than 4 years ago | (#30324012)

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? (1)

Tim C (15259) | more than 4 years ago | (#30325172)

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? (1)

cheros (223479) | more than 4 years ago | (#30325276)

.. 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. (1)

argent (18001) | more than 4 years ago | (#30323846)

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 is news? (1)

sbeckstead (555647) | more than 4 years ago | (#30326398)

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? (1)

Triela (773061) | more than 4 years ago | (#30324438)

Wake us up when you have a remote exploit.

There's a nap for that.

Re:This is news? (1)

sbeckstead (555647) | more than 4 years ago | (#30326422)

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

It is not a desktop computer (1)

Ilgaz (86384) | more than 4 years ago | (#30325228)

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:It is not a desktop computer (1)

sbeckstead (555647) | more than 4 years ago | (#30326452)

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.

No worries, you will hear about it (1)

Ilgaz (86384) | more than 4 years ago | (#30325340)

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

Who Cares (1)

wzinc (612701) | more than 4 years ago | (#30323394)

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 (1)

Achromatic1978 (916097) | more than 4 years ago | (#30325884)

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

Oh no! The computer has my data! (1)

VeryVito (807017) | more than 4 years ago | (#30323418)

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? (4, Insightful)

dawilcox (1409483) | more than 4 years ago | (#30323420)

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? (0)

Anonymous Coward | more than 4 years ago | (#30323906)

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? (1)

middlemen (765373) | more than 4 years ago | (#30325008)

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

Nobody likes pissing in their own pool.

And this would be why... (0)

Anonymous Coward | more than 4 years ago | (#30324172)

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!

Worth the read (0, Offtopic)

mindspring (1693214) | more than 4 years ago | (#30325424)

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

run, scream, panic! not. (1)

Sandbags (964742) | more than 4 years ago | (#30325982)

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.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>