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 applicationsWhile 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 capabilitiesThe 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 GoogleThis 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.