Understanding WebView and Android security patches
A recent revelation that Google is no longer developing security patches for the "WebView" component of Android in Jelly Bean and earlier has once again put a spotlight on Android security, and the challenges involved with securing the one billion or so active devices. First revealed by Metasploit on Jan. 12, Google's stance on updating this central Android component has been widely reported in the following days.
So what exactly is WebView, and what does Google's stance on WebView updates mean for Android device owners? And if you're still running Jelly Bean, what can you do to mimimize the risk? We'll take a detailed look after the break.
First things first: What is WebView?
WebView is the part of the Android OS responsible for rendering web pages in most Android apps. If you see web content in an Android app, chances are you're looking at a WebView. The major exception to this rule is Google Chrome for Android, which instead uses its own rendering engine, built into the app. (The same goes for some third-party Android browsers like Firefox.)
In older versions of Android (4.3 and below), WebView uses code based on Apple's Webkit — the same tech behind the Safari browser. In Android 4.4 and above, WebView is based on Chromium, the open-source base of Google Chrome (which uses Google's Blink engine.). In Android 5.0, WebView was broken out as a separate app, presumably to allow timely updates through Google Play without requiring firmware updates to be issued.
Security researchers from Metasploit, after discovering several security exploits in Android 4.3's WebView component and submitting them to Google, have published an email from security@android.com revealing that Google generally doesn't develop patches for pre-Android 4.4 versions of WebView.
The email excerpts published by the outlet read:
Why is it bad?
As Metasploit points out, more than 60 percent of active Android devices are currently running Jelly Bean (Android 4.1-4.3) or earlier, potentially leaving them open to web-based nasties when browsing through a WebView. This is particularly worrisome for those on Android 4.3 and below using built-in web browsers from manufacturers like HTC, Samsung and LG (to name but three), which use WebViews to display content from the web.
The fact that Google isn't actively developing fixes for older WebView implementations means it's up to OEMs to patch this stuff on their own.
Android 4.0-4.3 owners using non-WebView browsers like Chrome or Firefox won't be exposed to these vulnerabilities when using their web browser of choice. However they could still be at risk if a third-party app's WebView directs them to a malicious site. This is less likely than running into malware in the course of regular web browsing, however given that high-profile apps like Feedly and Facebook use WebViews to display third-party content, it's far from impossible.
Android platform version numbers for month ending Jan. 5, 2015.
Why it sort of makes sense (or: the reality of updating Android)
The real problem isn't that Google won't update WebView, but that so many devices are still running Android 4.3 and below.
It's easy to confuse the symptom — WebView vulnerabilities — with the root cause. The real problem isn't that Google won't update Jelly Bean's WebView, but that so many devices are still running Android 4.3 and below with little prospect of being updated, regardless of whatever action Google might take. Even if Google were to issue patches for Jelly Bean's WebView code (and Ice Cream Sandwich's, and Gingerbread's), users would still be waiting on OEMs (and carriers) to push out firmware updates, just as they're waiting on Android 4.4 today. And if the manufacturers of these devices were inclined to push out updates at all, chances are they wouldn't be stuck on Android 4.3 or earlier to begin with.
From Google's perspective, the fix for this issue was released more than a year ago with the arrival of Android 4.4 KitKat. In an ideal world, that would be the patch OEMs applied to their Jelly Bean phones, and as a result nobody would be running Android 4.3 or below more than a year after 4.4 became available. Unfortunately, despite efforts on multiple fronts, Android updates remain something of a crapshoot.
But there is a silver lining — Google's taking steps to ensure WebView is easier to patch in Android 5.0 and beyond.
What now?
Because Google won't be developing patches to Jelly Bean's WebView, it's up to OEMs to develop and roll out their own fixes on affected phones and tablets. Given that these devices are already running a fairly old version of the OS, we're not holding our breath for manufacturers and carriers to deploy anything in a timely manner. And to be clear, that would likely be the case regardless of whether Google developed its own Jelly Bean WebView patches or not.
Google's already taken steps to make sure WebView can stay up to date in Lollipop.
If you're running Android 4.3 or below, we'd recommend switching to a browser that doesn't use WebView, such as Google Chrome or Mozilla Firefox. As for protecting yourself in other apps that use WebViews, it's always a good idea to only install apps you trust, and to take basic precautions when browsing the web. Facebook, for instance, lets you disable its built-in browser and open web links in your browser of choice.
As a web-facing part of the Android OS that's difficult to update, WebView is an obvious target for anyone wanting to find Android exploits that affect a large number of people, and that can't be immediately nullified by an app update. That's surely why Google has made it possible to update WebView independently of the OS in Android 5.0 and beyond. If similar vulnerabilities were discovered in Lollipop's WebView, Google would simply push out an update through the Play Store and be done with it. However, due to the nature of Android, it's going to take time for Lollipop to become anywhere near as widespread as Jelly Bean. And that means it could be years before the majority of Android users benefit from the new, modular WebView implementation.
Comments