Google throws nearly a billion Android users under the bus, refuses to patch OS vulnerability

Google throws nearly a billion Android users under the bus, refuses to patch OS vulnerability

Google Android Logo

When it comes to providing security updates for previous products, various manufacturers have pursued different strategies. Some, like Microsoft, tend to provide security updates long after they’ve stopped selling an operating system (Microsoft only stopped providing Windows XP support last year). Others, like Google and Apple, have pursued tighter timelines for security updates. Google is now doubling down on that schedule, refusing to patch bugs in Android 4.3 or prior, even when those bugs could expose critical vulnerabilities on nearly a billion devices.

The flaws in this case affect Android 4.1 to 4.3, aka Jelly Bean, which began shipping in mid-2012 and was the primary version of Android through late 2013, or roughly 14 months ago. Up until quite recently, Google has aggressively patched problems in Android’s WebView rendering engine. Before KitKat (Android 4.4), all versions of Android used the version of WebView found within the Android Browser for rendering HTML webpages. With KitKat and Lollipop, Google updated the operating system to use a WebView plugin derived from its Chromium project.

When Security firm Rapid7 discovered a new exploit in the Android Browser version of WebView, it contacted Google to inform the company that Android 4.3 and below were vulnerable. Google’s response and policy change are raising major eyebrows. Specifically, the company states that:

If the affected version [of WebView] is before 4.4, we generally do not develop the patches ourselves, but welcome patches with the report for consideration. Other than notifying OEMs, we will not be able to take action on any report that is affecting versions before 4.4 that are not accompanied with a patch.

This isn’t a minor issue. 60% of Android users are on pre-KitKit versions. No one uses Lollipop yet.

In other words, security staff are now expected to submit a patch to fix an issue when they report it. If they do, Google will “consider” the patch to see if it resolves the problem. If they don’t, Google now says the only thing it can do is inform various OEMs of the problem.

What Google is doing, in essence, is telling its user community “Sorry, you have to tell Samsung, LG, and Motorola to provide you with an updated version of our operating system.” This is hilariously impossible. It would never fly in the PC world — imagine Microsoft telling customers “Sorry, you have to make HP, Dell, and Lenovo provide you with a free update for our operating system.” The disparity is even larger if you consider that, in most cases, a computer running a previous version of Windows can be upgraded by the end user to run the next version. That upgrade may be a headache, but system requirements on Windows haven’t budged in nine years.

The average phone or tablet buyer has no way to upgrade their operating system unless the carrier provides an OTA update, and two-year upgrade cycles means that plenty of people are going to be stuck on broken devices with known exploits that Google isn’t going to fix. Granted, the fact that Google fixes an exploit doesn’t mean that carriers will deploy it, and fragmentation has been a major problem in Android’s ecosystem over the years — but there’s a difference between acknowledging the difficulty of maintaining security updates for the entirety of one’s user base and flatly refusing to do them.

Pushing OEMs off open-source Android

One obvious reason for Google to stop fixing Android Browser problems is that the company is aggressively moving to get OEMs to stop using Android’s open-source features and to replace them with features licensed directly from Google. Ars Technica has done an extensive write-up on this trend here, and getting rid of the Android Browser is a key facet of moving away from an Android that’s actually maintained and useful.
No, Google isn’t killing Android — it’s just ensuring that the only parts of the program that get feature updates, capability improvements, and performance enhancements are the parts that require licensing agreements and promises not to develop competing products. The reason Amazon’s Kindle Fire has its own app store, and Samsung’s continued interest in Tizen are both the result of Google’s push to embed itself into the center of mobile business while paying lip service to the idea of open source.

By throwing all of the responsibility for security updates back on carriers and security researchers, Google is telling OEMs that they can either agree to its licensing terms and fall in line, or take on the responsibility of performing security updates that they’re typically not qualified or funded to do. It’s a trick worthy of Microsoft in the Bad Old Days, and it’s particularly funny to see the company doing this, given that it threw Microsoft under the bus in December when it published the full details of a security flaw two days before Redmond patched it, on the grounds that the desktop and laptop OS company wasn’t moving fast enough.