Android has a great security feature, Permissions, where apps can typically only do what they are permitted to do before installation. This can potentially reduce scenarios like IOS, where data was being sent back to the app developers without the knowledge of the users.
But an investigation by New York Times, and covered by Ars technica, has shown that there are some important things for which permissions are not required. And this includes access to extremely personal things like photos.
Permissions for accessing images
The problem is due to the way Android permissions work. Android has no special permission to access images, so any app can access them. This becomes more dangerous as Android apps do not auto close and can continuously send data in the background. So, a rogue app, with internet access permission – which most apps want – can copy all your personal photos and send it to cyberspace without you even being aware of it.
This was tested by Ralph Gootee, an Android developer and CTO of Loupe, who put together a simple timer app with a permission to access the internet. When the user starts the app and sees the timer, the app instead goes directly to the photo library. Considering that almost every app wants Internet access, irrespective of whether it requires or not, this could lead to serious breaches.
A Google spokesman confirmed it and said “We originally designed the Android photos file system similar to those of other computing platforms like Windows and Mac OS. At the time, images were stored on a SD card, making it easy for someone to remove the SD card from a phone and put it in a computer to view or transfer those images. As phones and tablets have evolved to rely more on built-in, nonremovable memory. we’re taking another look at this and considering adding a permission for apps to access images. We’ve always had policies in place to remove any apps on Android Market that improperly access your data.”
Google had previously removed rogue apps from the market and also uninstalled them from the user’s device.
Google Bouncer - a step in the right direction...
Google had recently added a new layer of security for Android apps, Bouncer, which provides automated scanning of apps in the Android Market for potentially malicious software.
According to Google, Bouncer analyzes all apps for known malware, spyware and trojans as well as scans them for misbehaviour and potentially red flags them. Google also claims that each and every app is run in Google's cloud infrastructure, to simulate how it will run on an Android device while looking for hidden and malicious behaviour.
... but not fool proof
While Bouncer is a good idea, the detection rate will only be as good as the AV signature used. Further there will be no protection from zero day vulnerabilities.
According to an article written by Dmitry Bestuzhev, Kaspersky Lab, while Bouncer is a good initiative, it will not be able to stop all malicious attacks. For one, simulation can be defeated by anti-emulation tricks, which Windows viruses are already known to do. So an app can behave differently based on the environment it is and become threatening only when it reaches the end user.
Reduction in malicious downloads — an improvement?
Google also claimed that 2H2011 saw a 40% reduction in the number of potentially malicious downloads from the Android market, though the base as well how malicious the downloaded programs were, is unknown.
Path forward — overhaul permissions
While Permissions on Android is a fantastic security method, the way the system works, leaves a lot to be desired.
For one, the current permissions are extremely broad. Take the case of READ_PHONE_STATE, which may looks innocent from its name but contains major things including phone number, IMEI number, IMSI number and whether you are on a call or getting one.
A simple way to tackle it would be to breakdown this permission into two, one exclusively to IMEI/IMSI/phone number and the other to actually know whether a call is going on or not.
Restructuring the permissions can be a good way forward, but will require a major overhaul of apps and could lead to incompatibilities.
Another way is to give the user a way to change permissions, with the explicit instruction that any app issue after changing permissions will be entirely his fault and not Google's. There are already ways to do this, if one has rooted phones (Read: Android Permissions Black Book), but some way to manage permissions for unrooted users could be good.
Another, and a much simpler way, is to provide in-built firewall, which can block internet access of programs. Since internet access is the most common way of breaches, potentially closing that avenue will significantly reduce the impact of rogue apps. (Note if you are rooted you can already do this: try Droidwall or Avast).
What will Google Do?
While Google could reform the permissions and work on the backend on programs like Bouncer, we do not think that there will be a major overhaul. Part of the reason is that, it will make things far too complex for most people and complexity will lead to more risky behaviours. Take, for ex, if there were 150 permissions, even experience users will find it difficult to control them.
Additionally, power users, those who would actually want to use these features, do already root and use the corresponding apps. On a cost/benefit analysis, adding these programs might not be worth for Google.
With that in mind, Google should be more aggressive in its approach to scan apps in the background to properly filter apps. This should also include a comprehensive analysis of permissions requirement versus asked, though we do not see Google will be able to handle this enormous task - scanning all apps for permissions is very time consuming.
All in all, we hope that initiatives like Bouncer and emulation do really work and malware threat, both real and perceived, reduces in Android.
(Note: Watch out for a comprehensive analysis of Android permissions in the future. We have already looked at it partly in Android Permissions Black Book, which we recommend all of you to read)
No comments:
Post a Comment