Some ad..
A security researcher who is part of Google's "Project Zero" team tasked with hunting down zero-day vulnerabilities, has gone public with an exploitable Windows vulnerability that Microsoft is still in the process of fixing.
Tavis Ormandy has tweeted that he had uncovered a security issue with the core cryptographic library for Windows, revealing that, "Microsoft committed to fixing it in 90 days, then didn't." As a result of not meeting the Project Zero deadline to fix such issues, which is partly designed to encourage more resources to be applied to software security, Ormandy went on to state, "Today is day 91, so the issue is now public."
What is the vulnerability in question?
It's actually a bug within SymCrypt, the core cryptographic library responsible for implementing asymmetric crypto algorithms in Windows 10 and symmetric crypto algorithms in Windows 8. What Ormandy found was that by using a malformed digital certificate he could force the SymCrypt calculations into an infinite loop. This will effectively perform a denial-of-service (DoS) attack on Windows servers such as those running the IPsec protocols that are required when using a VPN or the Microsoft Exchange Server for email and calendaring for example.
Ormandy also notes that, "lots of software that processes untrusted content (like antivirus) call these routines on untrusted data, and this will cause them to deadlock." Despite this, he rated it a low severity vulnerability while adding, "you could take down an entire Windows fleet relatively easily, so it's worth being aware of." The advisory that Ormandy has published gives details of the vulnerability as well as proof-of-concept in the form of an example malformed certificate that would cause the denial of service.
Why has the vulnerability been published now?
As already mentioned, Project Zero has a 90 day disclosure deadline and this was applied to this vulnerability. It was first reported by Ormandy on March 13, then on March 26 Microsoft confirmed it would issue a security bulletin and fix for this in the June 11 Patch Tuesday run. Ormandy noted that, "I count that as 91 days, but within the extension period so it's acceptable." The extension period being one that allows for companies that have fixed patching schedules such as Microsoft.
On June 11, Ormandy stated that the Microsoft Security Response Center (MSRC) had, "reached out and noted that the patch won't ship today and wouldn't be ready until the July release due to issues found in testing." As that meant the 91 days were up, Ormandy made the vulnerability public.
What does the wider security community think?
I approached The Beer Farmers, a well-respected group of information security professionals which was last seen on stage at the recent BSides London conference for their take on this. John Opdenakker says, "in general if you privately disclose a vulnerability to a company and the company agrees to fix it within a reasonable period of time I think it's fair to publicly disclose it if they then don't fix it on time." Whereas Mike Thompson disagrees, telling me, "if the vendor has acknowledged the bug and committed to fixing it with a plan, but requires more time, then going full disclosure wouldn't be a move I'd make." Ian Thornton-Trump agrees and says, "this is the kind of activity which Google Project Zero has lost a lot of credibility with Adobe and Microsoft in the past."
I'll leave the final word to Sean Wright who points out this is a denial of service vulnerability and there are many other ways to achieve this, which makes it a low severity issue. "Personally I think it's a bit harsh," Wright says, "every fix is different and they should allow for some flexibility in their deadline."
What do I think?
I can see the value in having a disclosure deadline that brings pressure on organizations to take fixing security vulnerabilities quickly. After all, there are far too many cases of vulnerabilities being left out there years after researchers have disclosed them. Google, it has to be said, cannot escape some criticism for falling into this category itself.
While products like Chrome are updated on a continuous "as required" basis when vulnerabilities are found and fixed, the same cannot be said for all Google products. The Gmail and Google Calendar security issue I wrote about just yesterday is a good example. This was first reported to Google in 2017 but still remains a security issue today.
However, returning to this Microsoft Windows problem, the argument can be made that the Project Zero 90 day deadline is plenty of time for a well-resourced organization of this size to both effect a fix and apply all the testing that is required to ensure it works without impacting users in other ways. Need I remind you that Microsoft has had plenty of well-deserved bad press recently courtesy of updates and patches causing Windows 10 to freeze or even break other Windows security features?
In this context, it is understandable that Microsoft would want to get this right before releasing the fix. So yes, I do think that there was plenty of time to get the issue sorted and tested, but if Microsoft needed a little more to deal with issues that arose during that testing process then I don't think it altogether unreasonable, in this particular instance, to be slightly more flexible.
Ultimately though, where does all this leave the user? Sean Wright explains that to exploit this an attacker would need to get the victim machine to connect to the attack system. So either get the server to connect out to the attack system somehow, which is extremely difficult in practice. Or perform a man-in-the-middle attack, which again is pretty difficult in practice. "It's not something I would lose any sleep over," Wright concludes.
Both Tavis Ormandy and Microsoft have been contacted for additional comment regarding this story.
Update June 13 04:00 ET
A Microsoft spokesperson has provided the following statement:
Microsoft has a customer commitment to investigate reported security issues and provide updates as soon as possible. We worked to meet the researcher's deadline for disclosure; however, a customer-impacting regression was discovered that prevented the update from being released on schedule. We advised the researcher of the delay as soon as we were able. Developing a security update is a delicate balance between timeliness and quality, and our ultimate goal is to help ensure maximum customer protection with minimal customer disruption.
