Discussion on:
View:
Show:
It almost sounds like you may need an ACL (Access Control List) between App D (downloaded/installed) and App E (embeded/preinstalled) or even something between App E and outside the phone access.
I think William was going that way with individual digital signatures.
I don't know much about all this, but I try to read to keep up. Does the AVG Mobilation APP Scanner complete this function of making sure there aren't explicit/implicit leaks? I couldn't find it on their site. Thanks!
I'll ask William, but my thought is that the code is not considered malicious. Asking for permissions and using capabilities of other apps is how Android works.
That's exactly right, Michael. A security leak in itself is not actually considered malicious.
The third-party band-aid aproach like we've seen with add-on AV software probably isn't the way to go. It is taking yet more of the limited system resources to implement a detection method that is reactive at best and increasingly ineffective.
I like the idea of a manual scanner like the project team provided. It sits dormant and runs only when you click it to see if anything is leaky; maybe after a new app install. I just don't like the idea of adding more memory resident code.
Really, it seems like flaws in the OS and/or management of the software repositories. These are things that should be fixed at the problem source rather than by layering on more convelution. The risk of a malicious developer may come down to a per app vetting instead of a developer vetting. I think Google could provide far better oversight in the repositories without going to the extreme of Apple's broken submission process. As the article highlights though, the greater risk is exploiting a vulnerable app. That comes back to vetting of submitted apps and maybe a manual run scan utility if the vulns are common across programs. Based on this being a "how programs advertise available functions within the OS" it's back to Google yet again.
If I go Android with my next phone, it'll have to be a Nexus so I can flash the Google stock firmware and get future updates directly; no vendor child distribution, no vendor using software updates to drive future hardware sales.
I like the idea of a manual scanner like the project team provided. It sits dormant and runs only when you click it to see if anything is leaky; maybe after a new app install. I just don't like the idea of adding more memory resident code.
Really, it seems like flaws in the OS and/or management of the software repositories. These are things that should be fixed at the problem source rather than by layering on more convelution. The risk of a malicious developer may come down to a per app vetting instead of a developer vetting. I think Google could provide far better oversight in the repositories without going to the extreme of Apple's broken submission process. As the article highlights though, the greater risk is exploiting a vulnerable app. That comes back to vetting of submitted apps and maybe a manual run scan utility if the vulns are common across programs. Based on this being a "how programs advertise available functions within the OS" it's back to Google yet again.
If I go Android with my next phone, it'll have to be a Nexus so I can flash the Google stock firmware and get future updates directly; no vendor child distribution, no vendor using software updates to drive future hardware sales.
Would it not be simple if the calling activity must have at least all the permissions that a called intent has?
William thought using different digital signatures would work. The problem as I see it is that Android is so fragmented, how will a common fix work on all variants?
I don't know that fragmentation is that much of an issue in this case (though I am vocal about fragging the distro in general).
Something like this seems pretty low level and in place from an older version. Hopefully the same patch or module replacement can be implemented across the whole version history. With the nature of *nix it should just be a kernel mod replacement or similar commodity part. That's on the phone side.
Validating the app rather than app developer may be the way to go.
On the developer side, it adds some update workload but they should already be maintaining whatever apps they posted. Ship another update with the new certificate signing and your done. Part of what the dev is being paid for is maintaining the apps. Free apps that don't have the developer's attention should be culled out anyhow.
The biggest challenge is probably update delivery more than OS compatability with the update patch. Manufacturers are in the business of selling new phone hardware not shipping software updates for sold phone hardware.
Something like this seems pretty low level and in place from an older version. Hopefully the same patch or module replacement can be implemented across the whole version history. With the nature of *nix it should just be a kernel mod replacement or similar commodity part. That's on the phone side.
Validating the app rather than app developer may be the way to go.
On the developer side, it adds some update workload but they should already be maintaining whatever apps they posted. Ship another update with the new certificate signing and your done. Part of what the dev is being paid for is maintaining the apps. Free apps that don't have the developer's attention should be culled out anyhow.
The biggest challenge is probably update delivery more than OS compatability with the update patch. Manufacturers are in the business of selling new phone hardware not shipping software updates for sold phone hardware.
To make sure we are talking about the same thing, I am referring to all the OS variants that exist. Telcos are not sending out updates as you said, but it might be a breakage issue more so than financial.
The vendor specific variants are what I refer to as the child forks. When Mandriva creates a derivitive work based on Red Hat; that is a child fork. When HTC creates a derivitive work based on Android; that is a child fork. BlackXP, though not distributed legally, is a child fork of the WindowsXP distribution.
Breakage may be what I'm not fully understanding.
Variants within a major version
The vendor need only manage there variant and HTC should be perfectly capable of implementing a patch in HTC Android. If the patch affects something common to Google Android and HTC Android then there is no excuse for not inheriting that patch. Maybe the vendor should have stuck with the stock Android so they can benefit from Google's patching process.
Various major versions
So we're looking at something like Android 2.1 through 4.# no win public use. I'm not sure the exact issue but something came up recently and Nexus owners had the patch the day it was available. Not all the Nexus devices run version 4.# so that means Google did provide a patch for older major versions.
The broken part
Here we're talking the security settings for running programs. This should have been standardized early in the major versions and should be something low level enough that vendors are not mucking with it to somehow differentiate product. If vendors are mucking with something that far out of the user's view then they really need to rethink why they are doing so. A custom UI, sure. A custom driver for hardware only on this handset; sure. A custom security framework; wait.. why?
It is possible I'm missing the breakage angle or some other detail. With my current understanding of Android, carriers and business in general, I'm feeling the profit motive on this one. Even breakage points me back to profit; pay to maintain our one-off customization at patch parrity with the parent distro or tell the customer to give us money for a newer device.
Breakage may be what I'm not fully understanding.
Variants within a major version
The vendor need only manage there variant and HTC should be perfectly capable of implementing a patch in HTC Android. If the patch affects something common to Google Android and HTC Android then there is no excuse for not inheriting that patch. Maybe the vendor should have stuck with the stock Android so they can benefit from Google's patching process.
Various major versions
So we're looking at something like Android 2.1 through 4.# no win public use. I'm not sure the exact issue but something came up recently and Nexus owners had the patch the day it was available. Not all the Nexus devices run version 4.# so that means Google did provide a patch for older major versions.
The broken part
Here we're talking the security settings for running programs. This should have been standardized early in the major versions and should be something low level enough that vendors are not mucking with it to somehow differentiate product. If vendors are mucking with something that far out of the user's view then they really need to rethink why they are doing so. A custom UI, sure. A custom driver for hardware only on this handset; sure. A custom security framework; wait.. why?
It is possible I'm missing the breakage angle or some other detail. With my current understanding of Android, carriers and business in general, I'm feeling the profit motive on this one. Even breakage points me back to profit; pay to maintain our one-off customization at patch parrity with the parent distro or tell the customer to give us money for a newer device.
I think a permission group is a valid approach. It's just not how the system is designed at present. Hopefully as the platform matures we will see these types of precautions taken when an activity calls an intent. In the mean time however the model leaves it up to one app to police incoming requests from another and that just doesn't happen with any sort of consistency.
I think that's a great idea, and would definitely solve the problem for implicit and explicit permissions leaks.
I'll admit now that I don't understand the permissions system at an application level, so I may be wrong, but I do see a potential difficulty.
The difficulty would be that each intent would have to somehow indicate the permissions that it uses, or else a calling app would have to ask for extra permissions it might not need.
Consider this scenario: I have an app that scans barcodes and displays the decoded string. That's all it does, so my app would only need permission to access the camera. However, I want to use an intent from FancyCameraXYZ, because it has good low-light capability. Unfortunately, FancyCameraXYZ also has some permissions for features that I don't need: It tags photos with GPS coordinates, and it can send images as MMS to contacts. So FancyCameraXYZ quite validly asks for those permissions. If we force calling apps to have the same permissions as the called app, the I would need to ask for MMS, GPS and Contacts permissions, which would make my users (quite rightly) very nervous!
In order for this system to work, there would have to be a Take_Photo_Only intent on FancyCameraXYZ which only allows the Camera permission.
I imagine that this might be quite complex to implement, both from an Android system perspective, and from the perspective of the application that exposes the intent.
Also, in the example above, how does Android know that the Take_Photo_Only intent does in fact only take a photo? How do we know that the developer of FancyCameraXYZ doesn't use the GPS or MMS functionality when a calling app uses the Take_Photo_Only intent (either for its own purpose, or as a vector to deliberately allow other apps access to those permissions)?
I'll admit now that I don't understand the permissions system at an application level, so I may be wrong, but I do see a potential difficulty.
The difficulty would be that each intent would have to somehow indicate the permissions that it uses, or else a calling app would have to ask for extra permissions it might not need.
Consider this scenario: I have an app that scans barcodes and displays the decoded string. That's all it does, so my app would only need permission to access the camera. However, I want to use an intent from FancyCameraXYZ, because it has good low-light capability. Unfortunately, FancyCameraXYZ also has some permissions for features that I don't need: It tags photos with GPS coordinates, and it can send images as MMS to contacts. So FancyCameraXYZ quite validly asks for those permissions. If we force calling apps to have the same permissions as the called app, the I would need to ask for MMS, GPS and Contacts permissions, which would make my users (quite rightly) very nervous!
In order for this system to work, there would have to be a Take_Photo_Only intent on FancyCameraXYZ which only allows the Camera permission.
I imagine that this might be quite complex to implement, both from an Android system perspective, and from the perspective of the application that exposes the intent.
Also, in the example above, how does Android know that the Take_Photo_Only intent does in fact only take a photo? How do we know that the developer of FancyCameraXYZ doesn't use the GPS or MMS functionality when a calling app uses the Take_Photo_Only intent (either for its own purpose, or as a vector to deliberately allow other apps access to those permissions)?
These are all well thought out and valid concerns. The real solution as it exists now falls on the developer of an exposed intent. According to the Google documentation: "Arbitrarily fine-grained permissions can be enforced at any call into a service. This is accomplished with the Context.checkCallingPermission() method. Call with a desired permission string and it will return an integer indicating whether that permission has been granted to the current calling process." In other words if I expose a public interface I should be responsible for checking the permissions on the caller and throwing an exception if they are not there. Which is fine and dandy and I know a number of developers adhere to these docs myself among them but permission enforcement needs to happen at the OS level, not at the application level. As it exists now mistakes get made, programmers get lazy, or someone with less than honorable intentions takes advantage of this well known platform shortcoming.
I always enjoy your articles. This is well written, thoroughly researched, informative, and has excellent sources. And despite the nature of the content, it's not in the least sensationalist, nor does it cite platform wars. True journalism.
Things are always more complicated than it seems from the surface, but some of the design decisions here seem almost negligent. I think maybe I misunderstood the part about developer signatures... Is it really the case that you can write one "legit" app, and be awarded all sorts of access, then any future app shares the same permissions? It seems to make implicit exploits a moot point if App A can (e.g.) automatically access the contact list just because App B (by the same author) was previously given that permission. Or does the implicit exploit just get around having to ask the user first?
Things are always more complicated than it seems from the surface, but some of the design decisions here seem almost negligent. I think maybe I misunderstood the part about developer signatures... Is it really the case that you can write one "legit" app, and be awarded all sorts of access, then any future app shares the same permissions? It seems to make implicit exploits a moot point if App A can (e.g.) automatically access the contact list just because App B (by the same author) was previously given that permission. Or does the implicit exploit just get around having to ask the user first?
I do have excellent sources, Dr Jiang and his team are more than amazing when it comes to sorting out Android exploits. And William, what can I say? He hold my hand through each and every one of these articles.
I'm betting William will respond, but my take is that yes, once a developer has an app on board; all others have the same permissions.
I asked William the same question. Getting the app installed is not a for sure thing and all it takes is the user to remove it. I think bad guys want better odds than that.
I'm betting William will respond, but my take is that yes, once a developer has an app on board; all others have the same permissions.
I asked William the same question. Getting the app installed is not a for sure thing and all it takes is the user to remove it. I think bad guys want better odds than that.
Implicit permission leaks work because all apps signed with the same developer signature get the same permission set. It is designed that way because of the sand boxing model. It has definite legitimate uses. For example, if I am writing a modular mobile office suite, it's important that my word processor, spreadsheet, and presentation apps all can easily exchange info, files, preferences, etc. Part of the problem is simply how the permissions are presented to the user. In reality, when you agree to install an app I've written you are agreeing that I as the developer, not my app, warrants your trust. So any future apps you install of mine are granted that same level of trust. Honestly I think just wording some of the permission dialogs differently would go a long way to making the process more clear to users.
Reading through the article it would appear that part of the problem (not all) results from the software that is preinstalled on the various phones. Applications that the user installs can also create problems, but assuming the user takes the necessary care when accepting the permissions required, and ensures that the software is from a trusted source, these problems can be minimised.
The question is whether installing a "plain" or "vanilla" android version on your phone avoids the first problem, that is the one created by preinstalled apps. So, for example, would installing the Cyanogen Mod Rom avoid this problem or does this have its own associated "can of worms" ?
Would be interesting to hear whether this has the same or worse problems.
The question is whether installing a "plain" or "vanilla" android version on your phone avoids the first problem, that is the one created by preinstalled apps. So, for example, would installing the Cyanogen Mod Rom avoid this problem or does this have its own associated "can of worms" ?
Would be interesting to hear whether this has the same or worse problems.
And, it's best answered by William. I'm betting he will see it, but just in case; I will let him know.
It will be interesting to see if rooting the phone to avoid the preinstalled apps is less of a threat than not getting updates because the phone is rooted.
It will be interesting to see if rooting the phone to avoid the preinstalled apps is less of a threat than not getting updates because the phone is rooted.
First, it is important to note that there are a few phones available from carriers that come with "vanilla" Android installs. Nexus One, Nexus S, and Nexus Galaxy all fall into this category. When friends and family ask me what phones I recommend, I always point them toward phones that ship with stock Android.
That said, sometimes explicit security leaks will slip into even the base build of the platform. The power widget which leaked GPS, WIFI, SYNC, and LCD backlight permissions was a part of the base build. The difference is that when this issue was fixed, pure Google phones received an OTA update that patched the hole, while a number of high end phones are still shipping at this very moment with custom carrier builds that have not bothered to apply the patch.
I am a fan of custom ROMs and in particular Cyanogen Mod. These builds however are not immune to explicit security leaks either. The difference is that with a custom ROM, (and rooted phones in general), if any app is leaking permissions you can just remove it from the phone. Obviously there are some core apps that if removed the phone would cease to operate (I'm thinking of things like the dialer app). Luckily, to my knowledge anyhow we've yet to see any notable leaks in the phone's core components.
That said, sometimes explicit security leaks will slip into even the base build of the platform. The power widget which leaked GPS, WIFI, SYNC, and LCD backlight permissions was a part of the base build. The difference is that when this issue was fixed, pure Google phones received an OTA update that patched the hole, while a number of high end phones are still shipping at this very moment with custom carrier builds that have not bothered to apply the patch.
I am a fan of custom ROMs and in particular Cyanogen Mod. These builds however are not immune to explicit security leaks either. The difference is that with a custom ROM, (and rooted phones in general), if any app is leaking permissions you can just remove it from the phone. Obviously there are some core apps that if removed the phone would cease to operate (I'm thinking of things like the dialer app). Luckily, to my knowledge anyhow we've yet to see any notable leaks in the phone's core components.
Thanks Michael and William!
Unfortunately out here (Vietnam) there are no "vanilla" phones available. While we don't get phones with all the "bloatware" installed by typical network operators elsewhere, the phones here still come preinstalled with whatever HTC, Samsung or the like decided to put on the unit.
For now (besides being careful) it seems that a Cyanogen Mod ROM is a good option in addition to keeping my eyes and ears open (and making sure that I keep up to date with your articles!)
Unfortunately out here (Vietnam) there are no "vanilla" phones available. While we don't get phones with all the "bloatware" installed by typical network operators elsewhere, the phones here still come preinstalled with whatever HTC, Samsung or the like decided to put on the unit.
For now (besides being careful) it seems that a Cyanogen Mod ROM is a good option in addition to keeping my eyes and ears open (and making sure that I keep up to date with your articles!)
It sounds like you are well aware of what's going on.
We are working on one about QR codes. Stay tuned
We are working on one about QR codes. Stay tuned
I love that name! It likens it to the proverbial bird that pecks the wood to see what bug comes out; and if not, drills down until it finds the culprit! Another prescient article Michael!!
I love these articles because I don't support phones or tablets yet, and don't own any, so I need to keep up with the latest poop!!
I love these articles because I don't support phones or tablets yet, and don't own any, so I need to keep up with the latest poop!!
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
