2 days leeway is not uncalled for. Bad form Google.
It seems far more likely they sat on the disclosure and did not prioritize it appropriately, after google continued to push for an estimated release date (which they never got). Then when the clock was running out, MSFT asked for extension, and Google being tired of getting put off, said no and stuck to their 90-day policy.
all of the above is speculation, and I don't necessarily agree it was the right thing to do. However, I could see folks @ googles sec group being a bit pissed MSFT wasnt taking it seriously, and then decided to stand on their policy just to make an example (surely, MSFT wont drag feet on future disclosures after this, right?).
Plus there's also the small matter of Christmas, and for many countries, significant developer unavailability falling into that period.
What's more likely, Microsoft can produce, test and deploy a patch in a few days, but chose not to until they had to. Or that they did get a patch ready and tested, but not in time for the patch Tuesday the previous month (so actually got it done in ~62 days) but it didn't warrant an out of band release?
It can sound crazy to you (certainly, it sounded crazy to me at first), but taking 90 days to turn around a fix to a piece of software like Windows is not implausible.
First you have to understand the vulnerability: under what circumstances does it occur? Can we build some reliable tests so that we are convinced that we will know when we have fixed it?
Looking at the report of the vulnerability, are there other instances of problems that will lead to similar bugs? Because if you release a patch and then a week later somebody realizes a similar vulnerability, you're going to have to do all of this over again, and not with the luxury of 90 days before the announcement.
Then you have to identify what versions of the software are affected. This is where you start sweating, because were you working on the product seven years ago? If you were, do you remember anything about it? Well, you're going to have to learn fast and hope that the architecture hasn't changed too much.
Then you fix the bug, probably only in one of the affected versions at first, which is probably the version of the software that you have on your dev box. As you're fixing it, poke around in the code to think about similar vulnerabilities that the report didn't find. Recall that Windows is not a small piece of software and building it on your dev box and being able to test your fix may take several hours.
Now you port that bug fix over to all the other versions of this software that are affected and that you still support. For a piece of software like Windows, this is a long list. Hope that the architecture and the code you're fixing hasn't changed much or else you're digging in to remember how Windows 2008 worked and how to fix this problem there. Recall again that building each of these versions takes time.
Now you hand off your fixes to some other people who will independently verify your fixes on some of the supported versions. I say some, not all, because there's going to be another round of testing on the actual deliverables, which is the patch to the operating system.
Which another group is going to make. Most products at Microsoft have a build lab that will take a branch and create either the actual installer disk image or a patch to a previous version. In this case, they're going to create a patch to the latest supported version, for each supported version.
Fortunately, this can probably be done in parallel with the first round of testing if you're pretty sure that you nailed it. If you think that the testing (above) is likely to reveal some problem, then you should hold off handing it over to the build lab because these folks are some of the least appreciated parts of the development team. They're the ones who integrate all the various development teams feature branches into master, resolve the easy conflicts and find the people who need to resolve the hard ones. They have a full time job (and not a trivial one) before you're bringing your high priority build to them, and when you ask them to dust off the build machines for a seven year old version of the product, they're going to graciously accept. But to tell them you didn't get it right and request they start over on a new version is when you start bringing six packs with your request.
Once the patch is created, it goes through the real testing. Because somebody's going to install this patch on all the supported versions, and the SKUs within those versions, to make sure that it works. When I say "it works", I don't just mean that the patch fixes the bug in question (though of course it has to do that), I mean that it also has to not regress any functionality. And that the patch is able to be installed and uninstalled cleanly. This is some annoying work and the longer this bug has been around, the more annoying it is. Remember "Windows Essentials Business Server 2008"? Me neither, but somebody's going to be installing it on a VM and ensuring that your patch works there.
Let's assume that everything has gone well up to this point and you're ready to release it. Most product updates want to get included in Windows Update, of course, because you want your security fixes to just show up to the customer without them having to learn about them, download it and install it because so few people do.
If you're going to miss a patch tuesday, then you need to start asking yourself whether you want to a) try to buy yourself some more time, b) put up several KBs with the patch and ask people to install them manually or c) wait it out until the next patch tuesday. What you decide will probably be some combination of those depending on the severity of the bug. There's a possible fourth option, which is to convince somebody that your patch needs to go out before patch tuesday and while I'm sure that happens, I'm not sure how it happens. I suspect when you're dealing with a bug so critical as to warrant that level of pain for the organization, it will happen.
All of these steps take time. And a big organization like Microsoft moves slowly sometimes - it takes time to find the right people for all of these steps. This is especially difficult over the holidays where many of the "right people" here are out of the office.
Now you could argue that it's ridiculous that it took Microsoft 92 days to get a fix out the door, and maybe you'd be right. But that's another thing entirely. What's clear to me that Microsoft did not simply wait until day 89 to start working on this.
(In relating this story, I would be remiss if I didn't thank Junio Hamano of Google, the maintainer of git, who was kind enough to provide Microsoft with additional time to research and prepare patches for the range of our products that were affected by CVE 2014-9390.)
Let's take a stab in the dark and say it takes 4 weeks to fully test. That means from day one, MSFT would have 8+ weeks of time for developers to attack the problem (yes blah blah patch tuesday, call it 7 weeks if you wish). I don't know their code, and I don't know how pervasive the problem was, but 7 weeks seems pretty generous when you are handed the problem (and not required to fish it out of "user" complaints).
For CVE 2014-9390, we had a fix roughly 30 days after we were notified of the vulnerability. In that time, we released patches for the third-party libraries that we use for Git repository management (libgit2 and LibGit2Sharp), we released patches to three versions of Visual Studio and Team Foundation Server, and we worked with the Git for Windows team to ensure that our fixes were nice and compatible. In order to get the VS and TFS patches out the door, we needed all of this time.
(In fact, we discovered additional vulnerabilities on Mac OS very late in the process. Had these problems affected Windows, too, we would have needed to throw our patches away and start over with the build / test validation process.)
And compared to Windows, Visual Studio is not nearly as big or complex, and can turn these changes around faster.
Their tens of millions of customers who plan internal deployment, overtime, and other things around those specific dates?
> it's Microsoft internal schedule
It's their external schedule actually.
If some companies want to wait 2 days then let them make their own choice. It seems like a pretty stupid policy that nothing (except extreme cases) should get patched except when it's convenient.
They already do via WSUS. Companies get to plan this work to start on the second Tuesday of every month because that's the day Microsoft publishes them. Nobody puts a gun to company's heads and forces them to deploy internally.
> If some companies want to wait 2 days then let them make their own choice. It seems like a pretty stupid policy that nothing (except extreme cases) should get patched except when it's convenient.
This seems to be a complaint about a "policy" which doesn't exist and has no relationship to the topic at hand. I don't even really entirely understand the above.
If you plan your internal deployment updates based on the belief that the schedule will never change, then I'm really sorry for you and your users. In real world, not all issues are reported in advance - some are observed in the wild, and in that case you have to fast-track the fix. If you have no way to do that (e.g. because the vendor only releases fixes on Tuesdays once per month, or because you decided to choose such schedule on your own), then good luck. That might have been appropriate in 1995, not in 2015.
There are many projects and/or companies publishing fixes continuously, and leaving it up to the users when/how to apply them in production. That's essentially what all the linux distributions (RH, Suse, ...) and smaller projects do.
Not entirely true now. Users of MS software have built up their own testing processes around patch Tuesday.
Patch Tuesday was one of the best things MS did when they decided to take security seriously. They realized that testing patches downstream takes time and giving their customers a consistent patch day let them also plan ahead.
They've lost sight of this noble objective with an inflexible policy; who anointed Project Zero guardians of the internet? Why not wait the two days? cui bono?
In this case, the bug was reported on 13 Oct, 15 working days before the first Tuesday of November. Assuming Microsoft couldn't fix and test a change to a core service running on millions of desktops in that time, their only remaining opportunity within the disclosure window was the patch day in December - allowing them only 50 calendar days to deal with the bug.
What's worse is that the bug isn't even all that severe. Effectively Google were trying to strong-arm Microsoft into releasing an out of band patch for a minor issue, which would have knock-on effects for thousands of IT departments. A completely dick move, and thankfully one that's being given recognition here.
Shit like this is why I have a hard time dealing with the infosec community in general – a strange mix of conformance to pointless minutia, a deeply ingrained sense of self-importance (only worsening over time with PR crap like APT), and a fatal attraction with some of the most puerile elements of society. The result is a unique melting pot of genius and dumb that I regularly can't stomach.