Freedom to Tinker readers are probably aware of the current controversy over Google’s handling of ongoing security vulnerabilities in its Android WebView component. What sounds at first like a routine security problem turns out to have some deep challenges. Let’s start by filling in some background and build up to the big problem they’re not talking about: Android advertising.
What is a WebView?
WebView is just a widget that any Android app can use as part of its on-screen layout. A WebView is really a full-blown web browser with all of the features you’d expect: JavaScript (disabled by default but available), images, etc. This sort of component is particularly attractive to developers who are trying to build apps that work on multiple platforms (Apple iOS, Google Android, etc.). There’s a popular developer’s library, PhoneGap, that’s all about taking advantage of this.
Up to Android 4.3, WebView was a component baked into the Android distribution. When an Android app wants to use a WebView inside the app, it gets the WebView provided by the platform, which is based on the WebKit browser framework, much like Chrome, Safari, and many other browsers out there.
How do Android security vulnerabilities get patched?
Like any complex software platform, Android has its share of security bugs. Generally speaking, Google would fix the bugs and ship a new release of Android. Phone vendors then pick up these new releases, add back in their proprietary features (e.g., Samsung’s TouchWiz or HTC’s SenseUI), and pass on the release… to whom? Typically, phone vendors are blocked by the carriers (AT&T, Verizon, etc.) from directly shipping patches to the phone. Instead, the carriers typically have to approve the changes. Apple famously forced the carriers to get out of the way and will push changes directly to its users.
The net result of this was that Apple could push security patches out quickly, while Google couldn’t. Google responded with a major refactoring of Android, moving many components out of the core distribution and into a new component called Google Play Services, which they could update frequently, allowing older Android phones access to newer features. (You can find additional background in a nice 2013 article from Ars Technica. This change also meant that large chunks of Android ceased being open source. That controversy is beyond the scope of this discussion.)
WebViews, which we remind you are really full-blown web browsers, were still baked into the core Android distribution until Android 4.4, when they too were broken out for more rapid updates. That’s good for Android 4.4 and newer phones, but it means that older Android platforms are using older versions of WebView. Why is that a problem?
The security of a modern web browser, and this includes WebView, is based on rapidly getting updates into the field, because there’s always yet another bug with yet another subtle but serious security consequence. Because WebView is built on WebKit, a popular open source browser, vulnerabilities in its older versions are well known and exploits are easy to come by. Google can push security fixes quickly for this to Android 4.4 and newer, but what about all those users stuck on Android 4.3? How are they supposed to get updates to the WebView component? How bad is it if they’re running an old WebView? According to a January 23 posting by Google engineer Adrian Ludwig:
WebKit alone is over 5 million lines of code and hundreds of developers are adding thousands of new commits every month, so in some instances applying vulnerability patches to a 2+ year old branch of WebKit required changes to significant portions of the code and was no longer practical to do safely. With the advances in Android 4.4, the number of users that are potentially affected by legacy WebKit security issues is shrinking every day as more and more people upgrade or get new devices.
AppBrain reports that, as of January 26, Android 4.4 has 36.6% of the Android market share and Android 5.0 has 0.7% market share. Android 4.1 through 4.3 combined have roughly half of the Android market, declining by 4% per month. Clearly, the sort of vulnerabilities we’re discussing impact a large fraction of the installed Android user base and will continue to do so for the next year or two, but perhaps not as much beyond that.
Even if Google were to produce a patched version of Android 4.3, as discussed above, it would require a laborious process to get it out the door, through the phone vendors and carriers, before it could hit users’ devices. Demonstrably, those vendors have already abandoned those older phones. They could have ported newer Android versions to their existing phones, but they didn’t. Would they be any more likely to adopt security patches Google gives them for Android 4.3? It’s hard to say, but probably not. Instead, Ludwig give app developers this advice:
developers should confirm that only trusted content (e.g. loaded from a local source or over HTTPS) is displayed within WebViews in their application. For maximum security when rendering content from the open web, consider providing your own renderer on Android 4.3 and earlier so that you can keep it up to date with the latest security patches.
 |
| Detail from Luma Partners’ “Mobile LUMAscape” illustration. |
And that’s where things get interesting because of the largest and most pervasive use of WebViews: advertising. We’ve been studying the Android advertising universe for several years, and it’s worth making some basic observations:
- Virtually all the advertising you see in Android apps is hosted inside a WebView. It’s all just HTML, JavaScript, and images, and it’s all generally loaded over HTTP. That means there’s no encryption and no authentication, violating Google’s security advice.
- Just like web advertising, mobile advertising uses HTTP redirects, so the content can come from a variety of different sources. Attackers may well be able to craft malicious content and use any of the many advertising services to deliver it directly into apps. TLS is not used for most advertising, so, if an attacker is in a position to mount a DNS poisoning attack or the attacker controls the network you’re connected to, the attacker can deliver malicious content directly into your apps’ advertising window. In short, if you run an app on Android 4.3 that has advertising within it, you’re vulnerable to WebView attacks under realistic conditions.
- A WebView runs with the same privileges as the app that’s hosting it. If malicious advertising content can break the browser’s security and run “natively”, it will still be constrained by Android’s permission system. Unfortunately, such malware can exercise all of the app’s privileges. It’s ubiquitous for Android apps to have full Internet privileges, and many apps have a variety of more sensitive permissions (e.g., your GPS location). Maliciously crafted advertising content will then inherit all these privileges. Even with full Internet privileges and nothing else, malicious ad content connected to the WiFi behind your firewall could use your phone as a launching pad for further attacks.
- Since we’re talking about Android 4.3, which was released in 2013, we’re also talking about a Linux-derived OS kernel of similar vintage, giving the attacker a vast array of previously known vulnerabilities (or homebrew zero-day vulnerabilities) in both Android and Linux. This could allow an attacker who can break the browser to escalate to full privileges over the phone, with all the attendant attack options. It’s not pretty.
- Older versions of the WebView have even bigger security holes. For example, webviews on Android 4.1 and earlier allow the execution of arbitrary native code by reflection on apps that have a custom JavaScript interface installed.
Google’s solution appears to be pushing this problem onto the shoulders of the huge Android developer community, but they’ve made no public statements about requiring these changes. There’s no clause threatening app authors to remove their apps from the store if they’re not compliant with Google’s new security guidelines. This is particularly a problem since most app authors probably aren’t using WebView themselves. They just include an advertising library, and may not even be aware that there’s a WebView being used within.
How can users protect themselves?
While it’s easy to advise users to uninstall all of their advertising-supported apps, this sort of advice seems unlikely to be taken widely. Users of many phones might look at upgrading their phones, on their own, to CyanogenMod 11, based on Android 4.4, which supports some 65 different devices. The process for doing this installation is sufficiently intricate that most users won’t be able to do it themselves, and in most cases it will require “wiping” the phone and reinstalling apps. Furthermore, there are thousands of different devices running Android 4.3 or earlier that CyanogenMod isn’t supporting.
Another tactic is to “root” your phone and install an advertising blocker. I use AdAway, a free and open-source tool which is most easily installed via the F-Droid app store. (Google removed it from the Play Store, presumably because money.) Not only does this make your phone more secure, it also speeds up the Internet in a huge way, since you’re not loading all of that advertising content.
What should Google do?
 |
| Detail from our 2012 AdSplit research. |
Advertising is the tail that wags the dog. It’s time for Android to have dedicated mechanisms to partition ad code from their host applications. At Rice, we built a system called AdSplit. A team at the University of Washington built another system called LayerCake. These systems demonstrate that it’s entirely possible for mobile advertising to be isolated from its hosting app in an analogous fashion to how web pages wall off their advertising within IFRAME tags. By building a wall between advertising and its host application, advertisements can be locked into a tighter box of restricted OS permissions and we wouldn’t have to worry as much about WebView’s security issues.
Google could potentially build a mechanism like this into its Google Play Services and deploy it widely, including to older Android 4.3 devices. Most ad libraries are really just a thin shim of Android native code that does little more than fire up a WebView and load content from the Internet. There’s no reason that shim couldn’t be standardized and we could remove the need for native advertising library code altogether.
Does that seem crazy? Apple is requiring all new apps submitted to have 64-bit native ARM code. Google could just as well make restrictions on new app submissions to follow the new rules, and they could eventually crack down on old apps (perhaps scanning for them in its app store and maybe even banning them after some grace period). Realistically, it would take Google several months to a year to develop a service like this, test it, and get it rolled out.
In the meantime, Google and the big advertising firms need to work together. The advertising firms need to update their libraries and Google needs to push developers to roll out apps with the new libraries. There should also be a threat here, such as advertisers refusing to pay money to app developers who put their users at risk by using unprotected libraries. Otherwise, very little will change for users of older Android platforms.
Trutth genuinely yields true competitive benefit.