Tony Dyhouse, director at the Trustworthy Software Initiative, a government-backed initiative working with the Centre for Protection of National Infrastructure to create safer software in the UK, has condemned Google for its early disclosure of unpatched Windows vulnerabilities, saying it is: “needlessly putting Microsoft users at risk.”
Google disclosed a Windows elevation of privilege flaw on Sunday, having reported the flaw to Microsoft 90 days earlier, a period it said was enough time to patch the flaw. Microsoft had produced a patch to be released yesterday as part of its Patch Tuesday programme of fixes.
From Google's perspective, it stuck to its 90 day warning period as part of a programme of open disclosure to encourage vendors to come up with fixes to known flaws within a set time frame – as vendors often simply sat on known flaws in the past. Of course they could have added two days as their deadline is an arbitrary one.
Similarly, Microsoft stuck to its Patch Tuesday release day, and could have released it earlier as it too has an arbitrary date for patching, and has had immediate release of some critical patches on flaws known to be exploited in the wild.
So both giants expected the other to move, and the consumer suffered.
Talking to SCMagazineUK.com, Dyhouse came down squarely on the side of Microsoft, saying, “I don't believe it was appropriate (for Microsoft to release the patch ahead of Patch Tuesday, or disclose the flaw with other forms of mitigation offered) because there is no evidence it was being exploited.” He adds, “Vulnerabilities should never be disclosed before a patch has been issued. It is understandable that not everyone can be ready each day to assess whether a patch affects their business, or be able to implement the many that may come out, so it is best practice for Microsoft to issue them as a batch.
“I understand the rationale for Google's 90 day limit, and if a software manufacturer is refusing to patch an existing vulnerability, then the threat of full disclosure can be an effective tool to encourage compliance. On this occasion, however, Google was fully aware that a patch was due to come out in line with Microsoft's well-known and accepted patching strategy, and needlessly put users at risk by making it public. This is a case where the vendors have lost sight of the general aim to minimise impact on the users.
It needs better coordination between vendors, and while it is acceptable to have a time limit, it should be open to negotiation. It is proven that open disclosure results in more (zero days) being exploited. (As a result) Google doesn't look good in the industry.
“There are cases where disclosure by one vendor can hurt another and they need to work together or the consumer will continue to suffer.”
Of course the primary message from Dyhouse is that software developers need to apply better design at the outset in accordance with the TSI's guidelines on how to produce and procure trustworthy systems, to minimise the need for patching. He told SC: “Speed to market is the wrong approach. It costs ten times as much to rectify flaws than to prevent them at the start of the process, and then there is reputational damage too.” The Trustworthy Software Initiative (TSI) supports a policy of Coordinated Vulnerability Disclosure, where companies agree to synchronise their activities in order to help the end-user.