Skip to content
Naked Security Naked Security

Microsoft swings punch at Google – accuses Project Zero of a “Gotcha!”

Two days! Two measly days! Google is back in the firing line, this time directly from Microsoft, over its "Project Zero" full-disclosure process...

Google came under fire right at the start of 2015 for openly publishing source code showing how to exploit a vulnerability in Windows 8.1.

Under the unilateral “terms” of Google’s Project Zero bug-finding programme, you get 90 days after Google tells you about a vulnerability in your software to publish a broadly available patch.

If you don’t shape up, and miss the non-negotiable deadline, Google names-and-shames you, all in the public interest.

If there’s a Proof of Concept (PoC) that demonstrates that the vulnerability is, indeed, exploitable, that goes public too.

We discussed Google’s New Year’s disclosure in a recent Chet Chat podcast, and we were willing to see both sides of the story. [Segment starts at 0’46”.]

(Audio player above not working? Download the MP3, or listen on Soundcloud.)

Yes, we understand the idea of pulling the trigger algorithmically on vulnerability disclosures, because it means there’s one rule for everyone, so that politics and horse-trading to buy extra time are avoided.

But we had our reservations about Google’s attitude [2’08”]:

Duck: It takes [...] subjectivity out of the equation, so I [...] get it. I just wish they hadn't shipped a PoC, [in] source *and* executable form, to go along with it. So anybody, even if they don't understand how the vulnerability works, can now go and pound on people's doors.

Chet: Yes, I agree. I think [Google is] finding an interesting happy medium on the whole "full disclosure versus coordinated disclosure." But the PoC code is certainly what I got hung up on as well.

Once more into the breach

Well, it’s happened all over again.

Project Zero’s Issue #123, published on 11 January 2015, explains, and gives sample code for, a security hole in how Windows handles user profiles when you log on.

The big difference this time is that Microsoft claims to have a fix that will be published on Tuesday 13 January 2015, and Google, apparently, was perfectly well aware of this.

Two days late! Two measly days!

But once that 90-day disclosure clock has started, it stops for no man, not even for Chris Betz, Senior Director of the Microsoft Security Research Center.

So Chris leapt onto his keyboard with an article entitled A Call for Better Coordinated Vulnerability Disclosure.

Despite the even-handedness in the title, Betz lands a few solid blows on Google’s chin, saying, suggesting, amongst other things, that:

Although following through keeps to Google's announced timeline for disclosure, the decision feels less like principles and more like a "gotcha", with customers the ones who may suffer as a result. What's right for Google is not always right for customers. We urge Google to make protection of customers our collective primary goal.

Betz concludes by reminding us all that:

Let's face it, no software is perfect. It is, after all, made by human beings.

The implication is clear: it really would have been the human thing to do for Google to back off in this case. (If this were a Turing test, Google would have failed.)

Indeed, Google’s bug-report pages openly report correspondence with Microsoft showing that the latter told the former in November 2014 that it would be ready with a fix in February 2015, and would that be OK?

No, it would not, replied Google, because the 90 day deadline is fixed for all vendors and bug classes and so cannot be extended.

So Microsoft replied in December 2014 that it would be ready in January, instead, and would that perhaps be OK?

When Google tells you something, it seems that you stay told, because the next reply from Mountain View wasn’t until Sunday, 11 January 2015 to say, simply:

Deadline exceeded - automatically derestricting.

“Boom,” just like the Noon Gun.

Who’s right?

This is a tricky one to call, because there are some interesting hypocrisies on both sides.

As far as we can see, Google’s high horse about 90 days being enough for a “broadly available patch” isn’t really borne out in its own Android ecosystem.

Security patches may make it into Google’s Android Open Source Project in just a few days, which sort-of makes them “broadly available,” yet those same patches often can’t be deployed by Android users for weeks, months, years, perhaps even ever.

That’s because handset vendors in the Android ecosystem are allowed to lock down their devices so that only official vendor-supplied firmware versions can be installed.

That means you have to wait until the vendor creates, tests and publishes an update, and even then wait until it’s your turn to have it pushed to your phone.

Even owners of some of Google’s own, recent-model, Nexus devices are still waiting for Android 5, better known as Lollipop, which supposedly reached GA, or General Availability, more than two months ago.

The out-in-the-cold devices are specific Nexus models with mobile network capability (3G or LTE), that are presumably lagging behind their Wi-Fi only cousin devices for some mobile phone related reason.

We can accept that.

Writing compliant software is hard – let’s face it, no software is perfect, because it is, after all, made by human beings.

On the other hand, Microsoft’s complaint that it was about to release a patch anyway rings hollow right now.

After all, Chris Betz himself only last week announced that Microsoft was no longer going to tell us what fixes were coming up on Update Tuesdays.

He even called the end of advance notifications an “evolution,” in the same sort of euphemistic way that you might talk of a “job opportunity” if you’d just got the sack.

(Betz also continues to refer to Microsoft’s monthly update cycle as “Patch Tuesday,” although the rest of us are instructed not to call it that: it’s Update Tuesday, plain and simple.)

Indeed, Microsoft has provided no public-facing information about what’s coming up on 13 January 2015, except for its vocal claim to be patching Issue #123.

The bottom line

Maybe the combatants from Washington and California can both back down a little?

Microsoft, bring back those Advance Notifications, and prove that you care about keeping people informed!

Google, drop the boarding school rules-and-regulations attitude and allow a touch of humanity into your bug-handling process!

Oh, and have a nice day, everybody.

Image of KA-POW biffo cloud courtesy of Shutterstock.

Image of fight over remote courtesy of Shutterstock.

0 Comments

IMO Google’s goal for Project Zero was to start discussions like this from the very beginning. It looks like Google tries to become a counterweight.

Reply

In the interest of security Google should not be playing World Police and posting security holes and how to get past them. Not ever computer is patched with the latest security fix the day it is release. If you have been in IT long enough you know the that the latest fix can also mean the latest bug so you must test it before letting hundreds of computers install a patch that could cause other issues.

Reply

Just one thought as a Owner of a Dec. 2012 Nexus 7 I am still running Kit Kat. As of 14.19 on the 12/1/15. and it, apparently up to date.

Reply

If, like me, you have a 3G version (hardware name = tilapia, firmware name = nakasig), not the very similar Wi-Fi only model (hardware name = grouper, firmware name = nakasi), then there is no Lollipop yet [2015-01-12T14:45Z]. I just checked Google’s Nexus Firmware Image page.

The other Nexuses have acquired 5.0.x at various times in the last two months. The Nexus 7 2012 3G and Nexus 7 2013 LTE models are still out in the cold.

Reply

and the Nexus 7 WiFi bought July 2012 is still up to date (it thinks) on Android 4.4.4 and the kernel version is 3.1.10… and the tablet has never been very responsive since it was purchased (and has few apps on it).

Reply

I have sympathy for Microsoft over this – they have many more years of legacy and big corporation have whole systems and line of business systems that could be affected, and it takes time to make sure that a security patch (a) does not break things and (b) does not create new liabilities.

Inevitably Microsoft has a harder job of fixing things because of this, and it looks like Google is trying to take advantage of it. I still find it amusing the number of people who believe Apple devices are immune to viruses and security problems. As I explained to one customer, the history of how we ended up where we are today may mean that the Mac is less exposed, but on the other hand, Microsoft are doing more about managing security and because of the popularity of Windows, they are also targeted more.

This is a high stakes game for Google – it will backfire badly the first time something is found that they cannot fix as quickly.

Announcing there is a security issue is one thing; releasing details of how to take advantage of it is irresponsible.

Is it not time that there was a “united we stand, divided we fall” attitude and approach to security? This * contest is only good for the bad guys, and is a turn off to most real people.

Reply

did I miss a memo? who appointed Google to police the internet? sounds like Google is having a judge dredd complex (and let the puns begin…)

Reply

The Wall Street Journal ran an article yesterday about Google refusing to patch the stock android browser in Android 4.3 (and earlier?) which already has known vulnerabilities.

“The new policy applies to the default browser in Android version 4.3, released in mid-2013 and known as Jelly Bean, and earlier. That covers roughly two-thirds of the billion-plus Android devices in use, according to Google, but some users may have updated their browsers to newer versions.”

Reply

Indeed!

See:

https://nakedsecurity.sophos.com/2015/01/13/google-flushes-61-percent-android-users-down-security-toilet/

Reply

This is a tough one. Both parties have valid arguments. Google can’t wait forever, or they’ll have companies putting fixes off forever. On the other hand, some bugs simply require more time to fix (which includes testing).

I suspect we (the customers) need to have the security teams (Google) have some flexibility built in.

Security breaches should be categorized for this purpose. Some bugs are already exploited in the wild. In such cases, the 90-day window should be shorter.

But, if 90 days isn’t enough time, the vendor should know this well in advance of the cutoff. Provision should be made for filing for extension.

Perhaps a new model?: Initial statement is that bug will be revealed in 60 days.

Allow for a variance for essentially any reason, adding 30 days, IF (and only if) requested before 30 days are up. Now we’re back to the 90 days, but there has been contact.

To extend past the 90-day limit should require an statement making the request, to get perhaps another 30 days. Further, if the Microsoft in this case didn’t bother with the first 30-day extension, tough luck.

Key dates:
30 days: Cutoff for requesting 30-day extension.
60 days: Release date if not extended.
60 days: Cutoff date for requesting 2nd extension.
90 days: Release date if extended, but not double-extended.
120 days: Release date. Extension only possible with personal contact, probably at executive-level.

Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

Subscribe to get the latest updates in your inbox.
Which categories are you interested in?
You’re now subscribed!