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”.]
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.