The perennial problem of bug disclosure has provoked a new squabble between Microsoft and Google. On Sunday, Google disclosed the existence of a Windows elevation of privilege flaw that the company reported privately in October. That flaw hasn't been patched yet. It will be very soon—the update is due to land on Patch Tuesday, tomorrow—but Google's publication of the flaw means that, for a couple of days, Windows users are vulnerable to an unfixed flaw.

In response, Chris Betz, senior director of the Microsoft Security Response Center, published a lengthy complaint calling for "better coordinated vulnerability disclosure."

Microsoft has been promoting "coordinated vulnerability disclosure" since 2010, but the security community has long been split on how best to disclose security flaws. On one extreme is the full disclosure crowd; security flaws are documented and described in full, in public, typically onto a mailing list. In the early days, that disclosure was typically the first time the software developer responsible even heard of the flaw, though some researchers promised to disclose to vendors first.

Vendors such as Microsoft tended to favor a different approach, traditionally known as "responsible disclosure." Under this policy, flaws would be disclosed in private to the developer, and details would not be published until the bug was fixed and a patch distributed.

The name "responsible disclosure" was problematic (not least for its implication that any other kind of disclosure is intrinsically "irresponsible"), so Microsoft attempted to rebrand the concept as "coordinated vulnerability disclosure" (CVD). CVD works in much the same way as responsible disclosure, though it opens the door to public disclosure before patch availability if in-the-wild attacks are making use of a privately disclosed flaw, or if the software vendor is completely uncommunicative.

Google's policy—at least for widely used software—leans toward the full disclosure side of things. The company gives developers 90 days to release a fix, after which Google will go public with the flaw. That's what Google did here, and it happens that the 90-day window fell just short of Microsoft's patch release, hence the complaints.

Google's hard-line stance is, however, arguably justified by history. HP TippingPoint's Zero Day Initiative lists reported flaws that have been known for many hundreds of days, including some in Microsoft's software. Vendors can, and do, sit on reported bug reports for a long time, and these delayed vendor responses put end users at risk.

That's because even without a fix, knowing details of a bug can often permit various kinds of mitigation to be implemented, allowing for some kind of protection against exploitation. With the risk that the bug is known to malicious parties (a group that may well include governments and those working on their behalf), even this limited protection can be valuable.

As such, Google's deadline provides a balance between allowing the vendor to produce a fix and enabling end users to protect themselves. Google stuck to that deadline even after being informed that Microsoft developed a fix, and even after being told that the fix would be published a couple of days after the expiration of the deadline.

Neither side seems to come out of this looking good. On the one hand, Google is being inflexible over something that is an entirely arbitrary deadline. While the need for a deadline is plain, there's no essential difference between waiting 90 days for public disclosure and waiting 92 days for public disclosure. There's no good reason why Google couldn't have waited a couple of days; it's simply policy not to.

On the other hand, Microsoft too is being inflexible. In this case, Microsoft has the patch, fully developed and tested, ready to go. The company has elected not to publish it, however, just so that it can stick to its Patch Tuesday schedule. The Patch Tuesday policy is popular among IT departments, as it makes their maintenance and reboot schedules much more predictable, but it too has a degree of arbitrariness. Redmond does occasionally release security updates off-schedule (generally when there's widespread in-the-wild exploitation of a flaw), and there's no good reason why it could not have done so this time around. It's simply policy not to.

This isn't a new fight, and the positions taken by Microsoft and Google are entrenched. Microsoft's complaint is unlikely to sway anyone at Google, and Google's behavior is unlikely to cause any rapid shift at Microsoft. Both sides have acted stubbornly, and neither side can really be argued to have put users' interests first.

But longer term, the argument perhaps remains worth having. It's all but inevitable that this will happen again, and if both companies stick to their guns, users will once again be put in a difficult position. Google doesn't have any responsibility to Microsoft's users, but Microsoft does. Redmond may need to show greater flexibility when dealing with Google-reported flaws, even if this adds inconvenience to IT departments. Users surely have to be more important than arbitrary policy.

As awareness of state-sponsored hacking and government usage of zero-day attacks grows, even the Patch Tuesday policy itself may come under fire. The working assumption of Patch Tuesdays is that if Microsoft isn't seeing evidence that an attack is being used, then it's probably unknown to malicious agents. Hence, delaying publication until a reasonable time is safe to do. But this presumes that Microsoft knows when flaws are being exploited: victims of advanced, state-sponsored attacks may not know that they're under attack in the first place, and they may never report the problems (automatically or otherwise) to Redmond.

As such, a case could be made that the assumption should shift and that flaws should be assumed to be under attack—at which point patching as soon as possible, rather than waiting for a convenient Tuesday, should be preferred.

Listing image by CyberHades