Dirty USSDs and the Android Update Problem
Last week, it was reported that some Android devices could be wiped remotely if the user unwittingly clicked on a link. Since then, Samsung has announced that for the Galaxy S III the issue was already fixed in the last update and urged customers to update their devices accordingly.
While the speed of Samsung’s response was commendable, what was left unsaid highlights the complicated environment of Android updates – and why it hurts the security of ordinary users.
Simply put, it is very difficult to push updates for Android devices. Three parties are involved: Google, the phone manufacturer, and the carrier. In theory, the Android Update Alliance (an initiative of Google and its Android partners) is supposed to ensure that Android phones and tablets get updates for at least 18 months after they are introduced.
The actual situation can vary wildly: some carriers and manufacturers, for example, are notorious for being slow to roll out updates. Other devices – particularly low-range devices – are neglected and rarely, if ever updated. “Fragmentation” is not just a problem for app developers; it could lead to serious security risks as well.
Consider this issue at hand. This was two features (calling a phone number via the tel:// protocol, and the ability to wipe a phone via a USSD code) that collided in an unfortunate way. Looking at Android’s source code history, it was fixed at least three months ago by somebody working for Google. What about phones running older Android versions such as Gingerbread (Android 2.3)? It was last updated in September 2011, and yet accounts for more than half of all Android devices in use today. Some of them may not be vulnerable for other reasons (such as custom dialers), but many users are still at risk.
The danger isn’t so much this particular vulnerability. There are other ways to mitigate it aside from an Android patch. (An aside: ignoring tel:// and other unusual protocols would have been a good way to secure users from this threat, and it would have been a perfectly sensible feature to include.)
The real danger is when Android is hit by a widespread zero-day, execute-arbitrary-code vulnerability – similar to what hit Internet Explorer and Java in September. Users would then be left with two unpalatable alternatives: risk using a vulnerable device until it’s patched (if ever), or spend money on a new, secure device. Either way, it would be a disaster both for users and Android as a whole.
Google needs to find a way to ensure that security updates can be delivered to as many Android devices as possible in a timely manner. It sounds like a simple task, but it isn’t: it would involve coordination with both carriers and device manufacturers. Serious re-engineering of Android itself may even be necessary. However, it’s something that is necessary: sooner or later, people will wish that it was easy to patch vulnerabilities in Android. Better that it’s done now, before there’s a significant threat – rather than in the middle of a security disaster for millions of users around the world.
Post from: TrendLabs | Malware Blog – by Trend Micro