Google flushes 61% of Android users down the security toilet

The Google-versus-Microsoft bug patching bunfight just took an interesting new turn.

As of Sunday 11 January 2015, we had Google publishing details, including sample code, for an Elevation of Privilege (EoP) exploit in Windows.

We had Microsoft come out swinging, “Not fair! We were two days away from patching this, and we asked Google in plenty of time, but they told us to talk to the hand.”

Google’s stance was that the rules are the rules (and Google should know, because it made up those rules itself), and 90 days is how long you get.

Cynically put, here’s where we’ve ended up.

Microsoft’s viewpoint is that, sometimes, patching things take a bit longer than you thought.

Redmond: Humans aren’t machines, and it’s OK to keep that in mind.

Google, in contrast, has the opinion that a miss is as good as 1,609,344mm, and if you are aware that things may take longer than you thought, you ought to start earlier.

Mountain View: Humans aren’t machines, and there’s your problem.

The saga expands

At this point, Tod Beardsley of Metasploit weighed into the saga with a story of his own about Google.

Metasploit, if you’re unaware of it, is a computer break-and-enter automation toolkit, equipped with pre-packaged exploits.

Metasploit makes it possible for people who don’t understand vulnerabilities and hacking to break into your computer across the internet by typing a few simple commands.

With permission, of course!

→ Metasploit bills itself as a penetration testing toolkit, and it’s a very useful one, even though there isn’t an awful lot to stop you using it as a plain old penetration toolkit.

If you’re into lock picking, which is a surprisingly popular and relaxing hobby amongst penetration testers, Metasploit is your snap gun.

So, the Metasploit guys know a lot about finding and documenting vulnerabilities, weaponising them into exploits, and coming up with patches and other mitigations to block the types of attack they know about.

All of this vulnerability and exploit finding means that they’re regularly in contact with software vendors to tell them about bugs they’ve found.

Indeed, as Beardsley tells it, the Metasploit team have found a number of exploitable holes in Android’s web browser code over the past year, but most of them only affect older versions of Android, prior to KitKat (version 4.4).

That’s a good sign, because it suggests that Android is becoming more secure and more resistant even to determined and skilful attack.

But pre-4.4 versions of Android are still in widespread use by Google’s customers, as the company’s own usage figures show:

Astonishingly, the latest release of Android, Lollipop, now two months old, doesn’t show up at all, presumably because fewer than 1 in 1000 Android users (0.1%) have received it so far.

In other words, you’d expect that exploitable bugs in Android Jelly Bean, at least, would be of special importance to Google.

After all, if you ignore Lollipop (and the statistics suggest that you ought to), Jelly Bean is pretty much the previous version of Android.

If Android were OS X, Jelly Bean would be Mavericks; if Windows, Jelly Bean would be Windows 7, or even Windows 8.

You’d expect it to be supported with timely security fixes, particularly given the infamous “90-day automatic full disclosure, no exceptions” rule of Google’s own Project Zero team.

Indeed, on the way to the office this morning, I popped into a High Street electronics shop for an unscientific test.

I headed for the budget-conscious section, where you can pick up perfectly decent but not state-of-the-art laptops, phones and tablets in the $200-$300 range.

The first three Androids I picked up were all running pre-KitKat versions, in an interesting contrast to the budget laptops, which all came with Windows 8.1.

That’s why Beardsley was surprised at a recent message from the Google Android security team:

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 con­sider­ation. 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.

Beardsley called this "eyebrow raising news," which it is.

He even followed up to make sure he wasn't missing something, and got this:

If the affected version [of WebView] is before 4.4, we generally do not develop the patches ourselves but do notify partners of the issue[...] If patches are provided with the report or put into AOSP we are happy to provide them to partners as well.

So, there you have it.

The bottom line

If you report a vulnerability in your Android Jelly Bean web browser, Google will provide you with a patch, provided that you send the patch along with your report.

At least that’s what it sounds like.

Google should probably reconsider its decision, for the greater good of the Android ecosystem.

Image of toilet icon courtesy of Shutterstock.