Google pleasantly surprised the mobile malware research community yesterday by announcing that Android apps are transparently analysed for malicious functionality and behavior *before* being allowed onto the Android Market.
A blog post, written by Hiroshi Lockheimer, Android’s VP of Engineering, briefly discusses the functionality of an internal system, codenamed Bouncer. The system consists of both static analysis and dynamic analysis components with the high-level architecture fairly well known by any connoisseur of automated malware analysis.
The static analysis part is concerned with all application characteristics that can be extracted from the application code and the meta data. Analysis of the Android application code, for example, could extract class names, snippets of code, control flow graph (CFG), various checksums, entropy and function names.
For the meta data, it can include information from the AndroidManifest.xml file, with required Android permissions extracted as a minimum. The extracted information is then compared with sets of known clean and malicious files to find out if there are any similarities to the freshly uploaded application.
At the same time, the app is run in a controlled environment where a special, instrumented, build of the operating system, including a modified Dalvik virtual machine is used to observe the application’s behavior on the system, evaluating the behaviour against a set of fine-tuned rules to detect potentially malicious behavioural characteristics.
So far, nothing too controversial but I am actually surprised that it took this long for Google to realise that a system like Bouncer should be an essential part of the Android Market security. Was it perhaps naive to expect a group of human researchers to analyse each one of the thousand or so applications rushing to the Android Market?
The very welcome announcement about Bouncer is followed by corporate spiel about superior Android resilience to malware:
1. Sandboxing prevents malware from accessing information private to other applications
While sandboxing is a good security measure, users should not be lulled into a false sense of security. We shouldn’t forget that the main drive behind malware is pretty much the same as the drive behind developing other applications: making money for the developers. With mobile malware, the prevalent model so far – sending and receiving SMS messages to premium line numbers – is *not* prevented by the sandbox.
2. Permission system allows user to decline applications with potentially unwanted capabilities
The permission system is not usable for the majority of users that do not really understand the risks behind accepting the installation of an application.
If I personally hear that an application is popular, do I install it if it has “Full Internet Access”? My answer is that it depends, but then again I have a decent level of technical knowledge.
A less technical user than I would probably install the application without even glancing at the permissions involved. That is why so many apps with android.permissions.SEND_SMS permission are accepted.
3. Even if malware infects the device it is easily removable, even remotely, by Google
This is true in an ideal world. However the world is never ideal and if a malicious app launches a jailbreak exploit it will have an ability to install itself so that it is not easy to remove, not even by Google.
There are few things missing from these messages about Google malware protection greatness, even if we ignore the fact that the problem of malware in the Android Market was, until now, largely overlooked (if not denied).
The issue that hurts us as malware researchers is Google’s stubborn refusal to define a secure API that could be used by Android anti-malware software for better protection of users and their devices.
Let us not forget that Android is an open system, just like Windows and unlike iOS, which means that apps can be installed from alternative locations, markets, websites and memory sticks.
To truly protect devices, we need a local bouncer. Not one like today’s anti-malware apps, with poor stamina and no weapons. Only with Google anti-malware API Android protection products will be fully armed and prepared to fight.
So, come on, Google, the ball is in your court.
4 comments on “Is Google Bouncer going to bounce all malware from the Android Market?”
"Let us not forget that Android is an open system, just like Windows and unlike iOS,"
Define "open system" better, please. The only "open system"(s) which I am aware of are Unix-like systems, other than Apple and Oracle's offerings. Linux is open, Windows is closed. BSD is (arguably) less open than Linux, but far more open than Windows.
In relation to software, especially operating systems, "open" is used to denote that the source is open to the public.
Your use of the word open is meant to imply that 3rd parties are capable of installing and running software – but that is true of ALL operating systems that I have ever used. If it is not possible to run third party applications, then any operating system will have almost zero value to end users.
It's not like anti-malware apps are uncommon for Android. (I'm not saying anti-virus as I don't believe that's an accurate description.)
Not from Sophos though, which I have complained about, frequently, and at length. 😉
Good Article. Come on Sophos, where is your consumer level Android anti-malware app contribution please? Were all waiting… (Just make it cheaper than Norton's over-priced offering though!)
You're wasting your energy. I asked my partner representative and it was quite clear the the direction was for management rather than endpoint security.
I get it, though, it's a lot of effort for a product that most will want for free, and many corporate admins aren't sure they actually want.
I can recommend combining Sophos Mobile Control with something like F-Secure's mobile security, or even Kaspersky's offering.
Kaspersky's mobile product is really cheap on the market, too, David – since you're looking for a good consumer level product.