The Google Android Update Dilemma

Updates

The problem we see with the Android update process is that there is no granularity when patching vulnerabilites in core components of the system. For example you can not only patch the browser’s rendering engine or one Core Service. Instead a full over the air update is required.

Let’s consider that a security researcher finds a vulnerability in a core component of the Android platform and chooses to report it responsibly to Google. The process will now be something like the following:

1. Google investigates the vulnerability and starts working on a patch.
2. The vulnerability will be patched and the updated Android packages will be provided by Google to the device vendors. It is hard to guess how many phone and tablet vendors there are, so we will go with an optimistic estimate of just 20.
3. Each vendor adapts the updated packages for each of the phones. Again let’s go with an optimistic estimate of just 20 devices per vendor. However this will grow (at least) linearly over the years.
4. The carriers receive the updated packages for each of their branded phones and adapt these packages. Final functionality and hopefully security testing will precede the release of the packages to the users. I would not even dare to make an estimate on the number of mobile carriers operating world-wide.
5. Finally the users will receive an update notification and install the update, given enough bandwidth is available at that time.

The main problem is, that a lot of parties and different device configurations (Google x 20 × 20 x Carriers == a lot) are involved in this process and there is no central way of releasing fixes for core problems to every Android user. Each of these steps might be delayed or fail for some configurations, leaving a large number of end-users with vulnerable phones.

Now consider the case that the “researcher” did not decide to go with responsible disclosure, but instead has written a worm which spreads through emails or text messages to every contact on an infected Android phone. The update process will still stay the same. By the time a patch is available to most users the damage is done. In this worst case scenario we are likely to see huge bills for the affected end-users and maybe even carrier network outages due to the large amount of malicious messages send through these networks.

Situation with Applications and Recommendations

The situation for third party applications on Android is much better. An application vendor can release security updates through the market places. These updates are then offered for download to every user of the application, regardless of which phone they use. Users can even opt-in to automatic installation of updates for specific applications.

This update mechanism can even be leveraged for some of the preinstalled applications. Let’s consider the example of Adobe’s Flash Player for Android. The preinstalled Flash Player found on most recent phones will not be updated automatically through updates in the Android market. However a user can decide to install Adobe Flash Player from the market on top of the preinstalled Flash Player. The newly installed application will get precedence over the preinstalled application and from now on receive updates through the market place. Unfortunately this cannot be done for all preinstalled application, such as the browser, the Contacts or Calendar service and many more. In these cases the end-user still relies on operating system updates from Google, the device vendors and finally the carrier.

However following commonly preinstalled applications have been found to be available through the market place and thus can benefit from automatic updates:

• Adobe Flash Player
• Adobe Reader
• Google Maps
• Google Reader
• GMail
• YouTube

Other applications might be preinstalled on your device and can be replaced with the Market versions. In some cases the users might decide to replace an application with frequent vulnerabilities (such as the WebKit-based browser application) with an automatically updated market alternative. In the case of the browser a good alternative might be Firefox for Android. Despite other browser alternatives it will not use the preinstalled webkit libraries for rendering of websites, but instead will use its own rendering libraries, which are also updated automatically.

Google’s Plan for Device Updates

Recently Google announced an improvement to Android updates. Effectively they are attempting to make carriers and device vendors responsible for releasing updates for any newly released Android devices. Vendors and Carries are then asked by Google to update devices to the newest Android version for “up to 18 months” after the devices initial release.

There are a few obvious problems with this approach:

• The foremost problem of the long update chain is not removed. And delays in this update are still as likely as before.
• The vendors and carriers are only required to provide updates for the first 18 months after the initial release. There are still a lot of devices on offer through carriers which are older than 18 months. Thus even if you buy, what appears to be a new phone, it might not receive any updates.
• Not all vendors and carriers are currently part of this initiative and a lot of users will miss out on updates.
• Will there be any consequence for vendors and carriers which are not complying with Google’s rules?

In our opinion the future will tell whether Google’s “updates only for the rich” (who can afford the newest phones) approach will improve the security of Android users at all. One point is obvious; it is not a perfect solution.