At the very best, Android security is so difficult and runs into so many interactions that it may not be solvable, according to Tim Vidas, who looked at the question at AusCERT.
Vidas’ presentation won’t have been welcome news to any partisan of Android – nor to IT departments trying to tackle the risk BYOD poses.
The problems are legion – malicious applications that assume too many privileges; developers who gravitate to mobile platforms because development is relatively easy (and therefore permit the unschooled and unskilled to create new insecurities); users who, in their desire to have a particular application, will fall prey to spoofed applications and then give them excessive privileges; to the burgeoning world of malicious markets whose only purpose is to distribute malware; to devices which ship their own vulnerabilities.
And even on the official Android market, a malicious application might not last long – but two or three days is sufficient, Vidas said, to achieve thousands of downloads before the app is removed.
Vidas noted that it’s quite feasible for a malware writer to craft an application that won’t be noticed by scanners even in a well-managed market, because the app doesn’t contain the dangerous payload; rather, after installation, it will fetch the payload separately.
Device rooting is yet another serious risk. “If you have rootsmart now, and you connect to other corporate resources, then the malware has more privileged access to your device than any of your security software. The device can be used as a proxy into your network,” he said.
“And who is the device administrator?” In almost any circumstances, Vidas’ said, it’s not the business’s IT administrator: “the real device admin might be some collection of hackers sitting somewhere.”
Android’s slow update cycle – an almost inevitable outcome of a software upgrade having to flow through a large number of participants (Google, telecommunications carriers, and device makers) can mean that the gap between an upgrade being prepared and actually shipping can be as long as 12 months, he noted. In other words, the software upgrade cycle to fix (for example) a browser vulnerability could easily be longer than the end-user’s “buy new telephone” cycle.
The worst news: Vidas – currently awaiting his doctorate from Carnegie Mellon University – could not see any imminent solution to this host of security problems that confront both the individual and the enterprise.
#auscert2012
Follow @CSO_Australia and sign up to the CSO Australia newsletter.