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 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.
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.
27 comments on “Google flushes 61% of Android users down the security toilet”
So how do you update Android?
My phone is on 2.3.6
My new Tablet is on 4.4.4
Depends on the device, MOST android phones if you go into settings then to the about phone section, or near that in main settings menu there is a system updates option, i know that some samsung devices, S2 on TMobile, had to be updated via Samsung Kies software. Also a lot of carriers are SUPER slow on pushing out OS updates, which is the main reason that google has switched to their current update scheme, where play services are separate from the main OS and can be forced to update when you go into the play store the next time
Until a significant majority of Google’s users have switched to the current update scheme, don’t you think Google should also support the old one, and maybe lean on its customers, the carriers, not to be SUPER slow? (Remember: more than two months after its much vaunted launch, *so few Google users have received Lollipop that Google omits it from its own official stats*, with an adoption rate below 1-in-1000. And it’s already had two official updates – currently at 5.0.2.)
If Google doesn’t want to issue patches for older versions of its operating system, then it ought to have an easy way to upgrade the operating system on existing devices. It’s not like there’s an “Upgrade To Lollipop” button. Microsoft supports its older operating systems with patches for years. Who’s more security-conscious here?
Maybe this is a clumsy attempt by Google at a cost reduction exercise in order to reduce the cost of maintaining the android ecosystem. Device manufacturers will be “forced” to issue upgrades for their devices or lose future sales to competitors who are already running 4.4 or higher.
Maybe Google is just a hypocrite.
Maybe Microsoft should start advertising Google flaws.
Seems like my prediction that Google had better be careful when starting a war of words on security has happened rather quickly (a couple of days ago on the previous story)..
In a nutshell, it looks like any Android OS older then 2 years is stuffed, and you are on your own for security. By contrast, Microsoft supported XP for 5 years full, then another 5 years in maintenance mode, and then a bit after that.
A lot of enterprises evaluate a new OS for at least a year, then port and test applications on it, and it will be 2-3 years old before they can start to deploy. I believe the UK’s NHS is paying for extra support from Microsoft on XP simply because migrating away complex systems is so time consuming.
This puts Google and Android clearly in the “throwaway” society, and I assume that this means Google have thrown in the towel on ever penetrating the enterprise business. I don’t see it doing much for Chromebook penetration in the enterprise either.
Perhaps the best practice advice about rooting your Android and installing stock or Cyanogenmod should change?
Not forgetting that there are still lots of people out there for whom no mod exists for their device.
Maybe if Android users started getting punished by black hats who exploited the holes, Google might have to sit up and take notice, but it seems pretty shabby that innocent folk with older Android devices would have to lose out before Google acted.
Then again, perhaps Google is just sick of the OEM’s who seem even more lackadaisical than Google themselves when it comes to updating users. Why should Google bother to write patches that will never make it to the end user device, because the likes of Samsung or HTC just don’t care enough?
Should we all be buying Windows Phones?
CyanogenMod is your friend. Manufacturer not providing updates? Root your device and install CyanogenMod with the latest Android OS. Don’t forget to install the latest Google Apps (Gapps) too.
Spell check: Metaspolit. “Metaspolit bills itself …” and “Metaspolit is your snap gun.”
Also, thankful to have Lollipop.
Thanks for the spell check. Now fixed 🙂
Man, I just cannot reliably type “metasploit.”
My fingers seem to produce “metaspolit”, no matter how carefully I type. I’ve even started *pronouncing* it “metas-spo-lit” in the hope of…not sure why.
Occasionally, if I try really hard, I come up with “metaspoilt”, which at least looks like some kind of pun.
When I read it back, I even see “metaspolit” as if it were “metasploit.” I’ll get over it. I used to type “proce” instead of “price,” always. One day, “proce” just went away. Same with “kernal,” which plagued me for a while but corrected itself.
Muscle memory, or something.
Google doesn’t want to support pre-Kit-Kat, Microsoft doesn’t want to support XP. For security’s sake, upgrade your device’s OS.
In the eyes of the industry: get a new device. This is unsat and can cost consumers a lot of money. I have an Android phone, Kindle, and a tablet. Many manufacturers and providers don’t push major versions (and sometimes minor), because they expect the lifetime of the device to be about a year. If they get on the bandwagon and allow users to upgrade their OS (it’s free, right?) just like their competitor, we wouldn’t have these issues.
This is unlike Apple, where they own both the device and the OS, which allows them to push the major versions out much quicker. This is why we still see older iPhones with iOS 8 on them.
One big difference, XP was released in 2001, Android 4.3 in June 2012…
Windows XP was generally available October 2001 and had security patches until April 2014.
Google released KitKat in October 2013.
There’s no comparison, this is an example of Google’s unwillingness to support their own releases.
There’s also the matter of Microsoft being completely clear (for years and years, in fact 🙂 about when support and security patches for XP would end, and providing advice about how to move off Windows XP in good time, albeit for a modest fee.
Another big difference: my Android OS upgrade choices are solely at the discretion of my device provider, Verizon Wireless. I can’t upgrade until VZW releases that upgrade to their customers. I know other phones don’t suffer this limitation, but most of the Android phones pitched by US cellular carriers do.
Except you don’t see i things with 8 on them.
You see a special version with features arbitrarily stripped from them to move sales. A voice assistant that relies heavily on server-side processing that could easily run on 2009 hardware? NOPE NONEFORYOUSORRY.
The funniest part is that i users tend to throw away perfectly good devices because a shiny new one came out, negating the need for older updates.
Those who live in glass houses shouldn’t throw stones. I really hope Google realizes how much credibility this is costing them.
I hope they learn to play nice. Releasing working details of an exploit only hurts criminals. A good-faith effort by a vendor to release a patch should be good enough to stop disclosure that a vulnerability exists.
Google itself needs to clearly outline the support cycle for their OS’s. Device OEMs should not have the power to stop users from updating their phone’s OS. Providing OS patches in not their business; it’s Google’s business. And if they want to stay in that business they need to take their responsibilities at least as seriously as the competitors they’re complaining about.
Does seem a mild irony that Google is saying, “If you send us a patch we’ll distribute it,” but they don’t mean back to end users.
They mean they’ll let the OEMs have it, who may or may not pass it on.
Woo hoo if the patch makes it into AOSP (the open source codebase) if that’s not what you’re running on your phone…especially if you aren’t running it because the handset vendor says, “No.”
Are they referring to the inbuilt AOSP browser that comes with every version of android or Chrome.
Generally most android phones I have ever used (as long as they have GAAPS) have chrome installed and set as default and chrome is always automatically updated to the latest version no matter the underlying version of android.
They’re talking about the browser called “Browser” that used to be the standard browser in Android, and still is the standard browser for the abovementioned 61% of users.
The one you may or may not be able to supersede, and that the Metasploit guys keep finding bugs in, e.g.
The default browser can easily be replaced. The biggest issue with these WebKit vulnerabilities are with 3rd-party apps like Twitter where users might click a link that opens an embedded webpage. Regardless of the default browser installed on your Android system, that embedded browser is going to be powered by the AOSP WebKit.
Windows and Android are not the same thing. Most of that 61% of affected users will never get an update from Google, even if they published it. Updates come from the manufacturer and telco unless you: 1) use a Nexus/GPE device or 2) root and update yourself (or install something like CM). It’s hard blame Google for not investing resources to develop an update most of that 61% would never see anyway. After all, if the manufacturer didn’t update to KitKat (which had similar hw requirements to JB) what makes you think they’d incorporate the WebKit update?
Going forward the Android team has managed separate functions like WebKit (which is now Chrome-based) from that core, manufacturer-controlled piece so they can be updated through the Play Store/Play Services. Unfortunately that’s necessarily an iterative process and WebKit hasn’t been updated that way until the advent of Lollipop.
The funniest thing that most people, even security researchers fail to notice is that all Samsung and HTC devices come with their own browsers as default and most are updated independently of OS version at this point.
The only people could be using the stock Android browser are people with Nexus devices, and those come with Chrome pre-installed… and most are updated even 2-3 years down the road unless there’s an extenuating reason.
tl;dr: The only ones that will be affected to a large degree are… nobody. LOL
If you are referring to the Samsung browser called “Internet”, I think, though admittedly I am not 100% sure, that you will find it is pretty close, code wise, to the Android Browser called “Browser” – one reason it has a very similar icon, I guess. In particular, I think it is based on the same underlying WebView code in which the Metasploit chaps keep finding security holes.
And Google is saying that it will only tell its OEM partners about vulnerabilities you might report in that code (without fixing them in its own code base) *if you also provide a patch when you report the vulnerability*.
I’m not sure I’d describe this situation as “the funniest thing,” as you do. Not even sure I’d crack a smile, let alone LOL.
See, for example: