If Google insists on exactly 90 days without any consideration for patch Tuesdays, this means that, if unlucky, MS will only get 60 days (if they got the announcement right after a patch Tuesday)
The reason for giving 90 days is not that some issues are so complicated that they require 90 days to fix, but that bureaucracies can be slow and need a lot of extra time. In your case, that is 30 days of bureaucratic overhead, leaving them 60 days of actual work. This seems reasonable, as bussiness deadlines are 30 days.
So, who forces Microsoft to stick to (so called) patch Tuesdays? No one, actually - it's Microsoft internal schedule, and clearly there are cases when it's absolutely unreasonable - e.g. when there's a 0day in the wild. So there has to be a way to fast track a fix - if there's not, there's something seriously wrong IMNSHO. Apparently, they thought Google won't stick to the 90-day limit.
Why do all these customers need to be on Microsoft's schedule though? Microsoft should release the patches and give each IT team their own ability to assess patches at their own speed.
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.
> Microsoft should release the patches and give each IT team their own ability to assess patches at their own speed.
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.
I don't really see how that matters. This only shows how utterly broken the concept of "patch Tuesdays" is ...
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.
If you define a limit for disclosure, and then not stick to it, why to define a limit in the first place? 90 days is more than enough - if MS has a lot of internal overhead, you should probably complain to them, not to google.
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?
If contacted by the other party and they give a good reason (in this case: "We have a fix, it's slated for release in line with other things on tuesday"), I think a responsible security researcher should give that time. If patch day rolls around and no production, go ahead and shame. This is not a case of overhead, MS world functions a bit differently from package management in Linux.
As another comment points out, unlike Google updates, Microsoft's occur on a particular day of every month. This allows end user IT departments to coordinate the updates as part of a predictable change management policy.
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.
unlikely we will know the true internal discussion, but it seems unlikely it realistically took MSFT 92 days to put together a patch.
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?).
Alternatively, and without your unsubstantiated knocking of Microsoft, perhaps they were needing to conduct serious regression testing. This isn't the "unit tests pass, whack it into production" leagues after all.
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?
The run tests over every single supported version of Windows, on every platform and with every combination of patches installed. Or so I read in an article by a MS employee who deals with security reports, someone sent in a nonsense 'vulnerability' with some C# POC involving MessageBox.Show and returning from main. It was obviously not in any way a issue, but he still ran it across all versions and patch-levels of windows to be sure. It doesn't say how long this took but I expect it wasn't fast.
Arguably, the fact that Google was going to reveal the vulnerability two days before the next patch Tuesday could have been considered sufficient reason to warrant an out of band realease.
I very much doubt that this was simply "sat on". Not knowing the full breadth of this vulnerability, I can only speculate, but I'm making an educated guess based on several years of working at Microsoft and recently managing a fix for a security vulnerability in several versions of two products.
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 f...
Despite the long wall of text I just posted, I forgot to mention: some clever person is inevitably going to come at the end of this whole process and say "oh hey guys? I figured out another way to trigger this bug" and you start over from the beginning.
start over? the 90 days is not spent attacking the code.. it's split across testing/packaging/etc. The developers can continue to pour over the code in PARALLEL to the testing to check for similar avenues/triggers, and at any point, push an updated patch, which could move the release date back. Still, how long would it truly take to finish the full cycle? It seems hard to believe it would be months. 90 days is roughly 12+ WEEKS.
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).
Right. Like I said, it sounds crazy that anything would ever take this long. And I'm not saying that it should take 90 days to get a patch out the door. I'm saying that it plausibly take 90 days to get a patch out the door.
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.
This is crazy. By now the world really knows about Microsoft's second-tuesday-of-the-month policy for patches. If Google isn't willing to wait the two additional days such that the patch can be deployed within the regular update window, this means that Google effectively gives MS only 60 days to react and fix issues (because once they missed the second patch day, the vulnerability will be disclosed before the third).
MS is a huge company with an immense installed base and they have to be understandably careful with pushing updates. Working with them to disclose vulnerability on their regular patch day really wouldn't be such a bad thing for either Google nor the end users, even more so as we're talking about two days here and there even was a holiday week in the timespan.
This is about being an ass and I see no advantages for end users.
Even if Microsoft had not responded to Google at all, they could have waited for full three patch days (again, MS' patch deployment timeline is very much public knowledge by now) before publicly disclosing the issue.
> Does it really matter if it's 90 or 92 day disclosure?
Yes. Google designed Project Zero to "pressure firms into dealing with security problems more quickly." A firm policy with unambiguous enforcement has its advantages. Muddying the 90-day deadline with questions about when (and for whom) to make exceptions weakens it. For example, in the future, I expect Microsoft will not wait the extra two days in the event of a security disclosure from Google.
One may disagree with the 90-day policy to begin with. I, for one, think it should have had an exception process built in. But while these are Google policies, not laws, I respect them for adhering to published protocol. Even when it was difficult.
I feel certain if this vulnerability had a higher impact (like remote execution) then it would have been over-ridden - or at least responded to quicker.
What about the people hit by the breach in the following 48 hours after the vulnerability is announced? Especially when attackers know they have a short window of opportunity before patch Tuesday hits.
Microsoft do issue out of band updates but they are very rare and for very serious issues.
It isn't like Microsoft was stalling for time, they didn't ask for months, they asked for days to fir into their scheduled releases. It's also worth pointing out the enterprises time things on the patch Tuesday cycle. An earlier release causes all sorts of implementation problems, especially if only a day or two in advance. In all likelihood you wouldn't see many machines actually updated in that period, but cause significant extra grief.
Almost everyone was already enjoying 90 days of ignorance. And almost everyone could have enjoyed indefinite ignorance with the same relative safety if Google had waited for patch Tuesday.
Google gave them 90 days (by Google's policy). Microsoft had the fix, but asked for another 2 days in order to fit within their patching cycle. Google decided to take action outside of Microsoft's (well established) patch cycle.
Then again what does Google care, they don't use or support anything Microsoft, so it doesn't affect them.
As does Google Earth, Google Drive, the android development toolchain, and a handful of other desktop clients that I'm not going to bother to look up right now.
So you're saying Google should make an exception for Microsoft? Its bestest friend ever? What about Facebook? Apple? Oracle? Why not just stop throw the 90 day rule out the window at that point, to fit everyone's schedules?
It seems to me Microsoft is like that student who has 3 months to do a project, but waits until the last 2 days, and then asks the professor to give him some more time. It was Microsoft's responsibility to patch the bug at the last Patch Tuesday.
I agree with this completely. Even if Google didn't know about patch days they should have allowed them two more days to release the patch since they asked for it. I would even say they could have given them another week window if they needed it. Releasing an exploit into the wild when you know a patch is coming is a really awe-full thing to do. If the tables were turned I wonder what Microsoft would have done here.
And the next company that comes along will ask for 3 days, and then 5 days, etc. Pretty soon we're back to serious bugs not getting fixed until the vendor feels like it. The power of a set timeline is the fact that its not up to the vendor when things happen. They have proven time and again that they won't fix things until they are forced to; this forces them.
It's just like being late for work. "But I was only 5 minutes late." Late is late.
It's a kind of thinking of the bureaucrat and not of an engineer. I'm the later, and in my areas of work the tolerance of 10% is the default, the tolerance of 20% or 25% is also natural, and only something more than that is something that is even worth the words.
As far as I know, some other engineering areas have even the safety factor of 2 or 3. That means, you expect the stress x, but your process has to sustain even 3 x.
There's no question that the hard 90-day deadline of Google's Project Zero is undermined by collisions with holidays and other calendar events, but Patch Tuesday is a restriction that Microsoft imposes on itself and its users. They had advanced warning and an opportunity to work within the limits of their own policy or roll out an unscheduled update.
Even so, this is a clash of two policies and Google needs to reevaluate its deadline (is 120 days better for everyone, including users?).
Given that Microsoft had excellent reason to ask for an extra 2 days, I guess the real question is that for a data-driven organization, why Google think 90 days is such a good number in the first place, and why they insisted on sticking to it despite the asinine alternative (forcing tens of thousands of IT departments to coordinate an out of band change for a low severity bug).
A "90 days no matter what" policy has the advantage that it takes any thought out of the disclosure process. It also has the disadvantage that it takes any thought out of the disclosure process.
Perhaps responsible disclosure occasionally requires considering the unique circumstances of each security flaw?
Even so, this is a clash of two policies and Google needs to reevaluate its deadline (is 120 days better for everyone, including users?).
This looks like a solution, but isn't. Perhaps Google's 90 day deadline is already a re-evaluation of a 60-day deadline that was made to accommodate holidays and companies with a once-a-month patch schedule. If Google's deadline was 120 and still hit two days before patch Tuesday, would you say the same thing but for 150?
(N.B. I'm not defending Google, just poking a hole in this particular idea.)
> By now the world really knows about Microsoft's second-tuesday-of-the-month policy for patches.
Which is a dumb policy for security patches. When its fixed it should be released.
> If Google isn't willing to wait the two additional days such that the patch can be deployed within the regular update window, this means that Google effectively gives MS only 60 days to react and fix issues (because once they missed the second patch day, the vulnerability will be disclosed before the third).
Google doesn't dictate Microsoft's patch releasing policy. 90 days are 90 days. Microsoft doesn't have "only 60 days", they have 90 days like anyone else, and they chose to miss it by adhering to a policy of their own choosing that makes security patches less timely.
The whole purpose of a fixed 90-day window is to give reasonable time to fix a security vulnerability but also to create pressure to do so timely. Making exceptions for vendors to accommodate existing policies that make security fixes less timely would both increase the effort for Google (as a fixed time window is always easier to implement than one that varies with each vendors policies) and undermine the whole purpose of the 90-day timeline.
It's a darn good policy if you're the one who is responsible to apply the patches inside of your organisation and you have to test the effect of the patches to the applications running in your company before you actually install them.
Applying the patch a few days later typically doesn't noticeably increase your risks but rolling them out unchecked can make some serious damage.
I wanted to say this, but evidently it was pointless given that seemingly 80% the people on this thread have absolutely no understanding of change management whatsoever, or more importantly the problems you might face when customers have your update infrastructure indirectly linked to national grids and industrial automation. Clearly Microsoft should just release Windows as a repo on GitHub and push fixes to master.
I agree with you and mentioned elsewhere in the thread that patch Tuesday was one of the best moves MS made when they started taking security seriously. Enterprises could now schedule change management around the dates far out into the future which leads to a predictable update schedule downstream.
Before, many enterprises rarely patched because the testing involved was a huge pain and it fell outside what they typically planned for.
At a prior company managing firewalls for SMBs that didn't have room for patch management beyond "automatically apply patches", we loved the predictability of Patch Tuesday. Often we would purposefully schedule around it, so if PT did break something, we could point to the schedule and say "nope, we didn't change anything on the box that Tuesday."
Why can't we just have the choice to apply as soon as it's ready?
If you don't want to apply the patches as soon as they're released, then you'd be more than welcome to put them on hold for 4 weeks yourself when it's more convenient.
This time, the "ready" will be the following Tuesday. Google didn't respect this, effectively providing the 0-day to the world.
There are bad guys looking for 0-days out there. If they learn about the vulnerability from the patch, at least the world has the patch before the bad guys do. Now it's the opposite.
Edit: See _wmd's explanation about the technical details of all this in the same level of the answers.
Basically because bindiff (http://www.zynamics.com/bindiff.html ). The moment an updated binary is available, the clock starts ticking towards a vulnerability being reverse engineered from the update. A few years back, there was a huge amount of research in the infosec community whose goal was to automate extraction of these vulnerabilities (yes really - a robot automatically producing 0-day given an updated binary). Symbolic execution trickery aside, this remains a straightforward task for a reverse engineer to manually perform given a set of debug symbols (which Microsoft supply for developers).
Your options become either to release an update the moment it's tested, immediately making vulnerable customers who have a change management policy (usually also the biggest and juiciest targets - fortune 500s including ironically the likes of Google), or delay any release until some coordinated date, giving everyone an equal and predictable opportunity to cope with the exposure, which is how Microsoft do it.
If you're in a situation where you test the effects of patches before applying them, then if Microsoft releases the security patch early, YOU have the option to wait and apply it on the regular patch day along with any other patches in the normal schedule.
Releasing the patch late (i.e., on patch day) makes that choice for everyone.
With the patch ready before the vulnerability release, there's no 0-day available to the all nefarious guys in the world. Now thanks to Google, there's one. (Edit: See _wmd's explanation about the technical details of this).
It's not that just the big companies are affected now: all users are.
Applying a patch to everyone at the same seems risky (not to mention scaling issues). Can't they stagger the patch, so if there is an issue with it then only some users have an issue instead of everyone.
If it was an important security patch for a bug that hadn't been publicly disclosed, rolling out to a few machines might be as good as disclosing the bug.
I don't think I'm exaggerating when I say that there is no other company in the world that understands the effects of releasing patches as much as Microsoft does.
Large enterprises already have centralized patch management, so they can decide how fast it gets pushed downstream to their users after MS releases the patch.
You apply a dozen different fixes and test. Something breaks badly. You now have a dozen different root causes to check when, if you applied one at a time and tested (or applied one at a time and let your users test it, which is more commonplace than it should - automated testing tools exist for a reason) you'd know what broke.
I'd prefer to have fixes available for rollout as soon as possible and to decide whether I deploy them or not based on my tests. Automatic mandatory deployment could be on a fixed schedule, for those who can't test or don't care much about it.
I wonder how people would have responded had the disclosure come from an independent security researcher instead of Google, knowing fully well that a patch is to be rolled out in 2 days.
The "second-tuesday-of-the-month" policy is a completely arbitrary MS-only policy.
If Google (or any other group that discovers security issues) has to take into account every policy of every software producer it becomes utterly impossible to have any disclosure policy.
If MS wants to handicap themselves, that's their problem. The rest of the world doesn't have to bend to their will, those days are over.
Yes, this is about being an ass. And it's Microsoft that's being an ass by claiming the rest of the world should take into account their peculiar policy.
Have you ever managed a nontrivial installation of user-facing desktop systems? 'Cause if not, declaring the policy of a predictable, telegraphed-well-in-advance day on which security patches will drop "peculiar" kind of just reveals where your head's at.
The rate at which security vulnerabilities are reported/abused isn't predictable.
Please don't sit on a fix until the time is more "convenient", give it to me now and let me be the judge on how important this security patch is to me.
Because the patch can easily be reversed into the exploit, it has to be convenient for everyone in the herd to apply it at the same time unfortunately.
>"We asked Google to work with us to protect customers by withholding details until Tuesday, January 13, when we will be releasing a fix," Microsoft's senior director of research Chris Betz said in a blog post.
> Microsoft confirmed that they are on target to provide fixes for these issues in February 2015. They asked if this would cause a problem with the 90 day deadline.
< Microsoft were informed that the 90 day deadline is fixed for all vendors and bug classes and so cannot be extended. Further they were informed that the 90 day deadline for this issue expires on the 11th Jan 2015.
So (a) Microsoft is unable to comprehend a simple 90-day policy or (b) do basic math.
TL;DR -- Google found bug in Windows 8.1. Gave Microsoft standard 90 days notice of public release on 11 January. Microsoft wanted to move release date to patch Tuesday on 13 January. Google released on their 90 day notice date of 11 January.
Personally, I don't think Google should bend to the internal red tape of other companies. You are going to start maintaining this long list of exceptions based on other peoples priorities. There is a published 90 day policy, they gave 90 days notice, figure it out. There is also details missing about the communication between Google and Microsoft. Like when they asked for an extension, etc.
The point of the two days isn't the two days - it's to establish the principal that the release date is negotiable, and it should depend on patch readiness.
You start out with two days because of patch tuesday. Then next time a bug is reported, well, this is a busy month with lots of people on holiday, if we could have an extra 10 days? And the next time, we're really close to releasing Service Pack N, the fix will be in that but it's got lots of changes - it'll be out in 60 days...
It's the opposite of bureaucracy. Strict simple rule cuts the bureaucracy off.
If you don't have it, then you have a lot of time wasted on communication, handling special exceptions, making decisions if you should bend it or not and so on.
> If there can't be any common sense exceptions to the 90-day policy, that's just bureaucracy by itself.
Its worth noting, as pointed out upthread, that the only reason it was released in January at all was because when Microsoft asked if their planned February release was going to cause a problem with the 90-day deadline, Google informed them the the 90-day deadline for that bug was 11 January and that that's when disclosure would occur. Clearly, the fixed deadline already achieved part of what it was intended to -- encouraging vendors to fix security issues more quickly.
And I'm not sure that there even exists such a thing as a "common sense exception" to that policy, but extending it simply to accommodate a vendor schedule that delays releases of security fixes to predetermined dates isn't such a common sense exception even if any exist. Its simply favoring the bureaucracy of fixed patch schedules over the purpose of the disclosure policy, which is encouraging vendors to more timely release fixes for security bugs.
Here's an idea. Knowing Redmond's schedule, could they have notified them but set the disclosure date 2 days ahead? That seems like professional courtesy.
It's not about bending to another company's internal policy. It's about having etiquette for the company patching the vulnerability that extends beyond the basic rules; especially when it could harm users. What Google did certainly stayed within normal policy, but that doesn't make it good form.
"Microsoft's senior director of research Chris Betz said in a blog post.", "Several security researchers", "wrote one developer", "But another said"
So is this what the disclosure issue is going to look like when packaged up for the masses? No historical context on how the ongoing disagreements are the latest in decades of ongoing discussion? Or any mention of the events that shaped the popular ideas today? Just a sour blogpost and some bland quotes of agreement and disagreement from an internet so large you can always find quotes for the positions you want to portray. We're so fucked.
Edit: And apparently it worked on us too. Of course external messaging is going to paint the other guy as the unreasonable one.
What? Microsoft asked for 2 extra days and Google refused? Seems like an asshole move.
I am in general a huge Google fan, but in using Google services I realize that I am not much of a customer (I purchase extra storage and buy stuff on the Play Store); advertisers are the customers.
Microsoft on the other hand gets its money from computer users and it seems like they have a much more customer focused mentality.
Of course, the thing about 0-days is that it's hard to say if those users wouldn't have been hurt anyway as the underground community exploited the known-only-to-them, Google, and Microsoft bug.
That's not safe to say. You're presuming that Microsoft and Google are the only two parties who knew about the exploit. Historically, it's more likely that the vulnerability was already known among cracking circles, and Google just announced something that was already in the wild.
Sure it is. We know that less people knew the details before Google released the details.
> Historically, it's more likely...
But going on what is actually known, less people knew before Google's actions than after.
EDIT: More accurately: We know that the information was definitely available after Google's action. We don't know that the information was definitely available before.
> Historically, it's more likely that the vulnerability was already known among cracking circles,
Why do you say this?
It implies a world where software is almost perfectly secure, and there are only a few bugs to fix, and then it's perfectly secure, and we are all happy.
In reality, there are effectively an infinite number of bugs out there, many with security holes. Finding one and going through the motions to fix, patch, test, and release still leaves you software with plenty of open holes.
If you magically theorize "the bad guys know about all the holes already," then they are still going to exploit all the other holes in the system, because they magically know about them, too.
*repost of my comment from another post on this subject[1]
>> "Google's Project Zero seeks to find bugs in popular software and then give the manufacturers responsible 90 days to fix the problem."
Seems reasonable.
>> "On 11 January, Google publicised the flaw. Microsoft said it had requested that Google wait until it released a patch on 13 January."
Dick move. Sorry, I can't think of any other way to describe it. They may have waited until the last minute (or maybe they really did have to rewrite a tonne of code) but that's no excuse or putting users at risk when you can wait two days. Seems more like a marketing tactic than a desire for faster security patches.
> Microsoft confirmed that they are on target to provide fixes for these issues
in February 2015. They asked if this would cause a problem with the 90 day
deadline.
< Microsoft were informed that the 90 day deadline is fixed for all vendors and
bug classes and so cannot be extended. Further they were informed that the 90 day
deadline for this issue expires on the 11th Jan 2015.
> Microsoft confirmed that they anticipate to provide fixes for these issues in
January 2015.
So basically Microsoft asked for an extra month, and they said no, which forced them to move quicker, and fix it a month earlier. Without picking any side of the debate, you can still see what effect the non-negotiation of timeline has on getting patches out as soon as possible.
Which sounds like blackmail to me. What did Microsoft have to put aside to move this up in their schedule? Maybe now the release date for Microsoft's new browser slips, giving Google the upper hand? Should corporations force their competitors to move like this? "If you don't drop everything, we're going to release vulnerability details about your product"?
I work in information security and patches are important, I understand. But it worries me that what we're basically seeing here is corporate warfare using security vulnerabilities. What gives any company the right to publish vulnerabilities about their competitors, especially when it has the chance to impact their competitor's performance? Does Pepsi have the right to demand Coke rotate the tires on their trucks within 90 days or they will publish the recipe for Coca Cola?
What a disingenuous comparison. It's not "accede to our demands or we'll publish this information"; it's "we're publishing this information in 90 days whether you like it or not."
If we ask "what gives any company the right to publish vulnerabilities about their competitors?" it's only a short step to asking "what gives journalists the right to publish scathing negative reviews?" The answer is the same: freedom of speech.
It's a fact of life that if you want to fix security bugs, that takes time away from working on other things. If you don't like it, fix the bugs faster, or pay more attention to security from the get-go. Microsoft should be thanking Google for finding the bug in the first place.
It doesn't matter if Google publishes it after the patch. It matters if the publish before. If they publish before the patch, even knowing when the patch will come out, that's enforcing their demands or making MS suffer the consequences. Google knew Microsoft had a patch. Google published it anyway, because their competitor didn't work fast enough, for Google's definition of "fast enough".
Journalists are not directly competing with tech companies. Google is. Imagine the next bug they find in Windows, and they publish it saying "ChromeOS doesn't have this bug!". They already use their search to push their browser, why not use their bug reporting to push their OS? When does free speech stop and anti-competitive behavior start? Would Google publish their own vulnerability if they were unable to fix it in 90 days?
> If they publish before the patch, even knowing when the patch will come out, that's enforcing their demands or making MS suffer the consequences.
So? As a general rule, people (and companies) have the right to say things like "I'll do X if you do Y" or "I'll do X unless you do Y". It becomes blackmail under certain circumstances, like where you're threatening to harm someone illegally, or demanding money for covering up a crime. In this case, Google picked a 90-day disclosure timeline which seems to be considered generally reasonable by the security community, so I don't see how they're doing anything wrong by sticking firmly to it.
> Google published it anyway, because their competitor didn't work fast enough, for Google's definition of "fast enough".
Yup, sounds like competition to me.
> Imagine the next bug they find in Windows, and they publish it saying "ChromeOS doesn't have this bug!".
Yup, sounds like competition to me.
Maybe I'm just being dense but it would help if you could explain why you think this is "anti-competitive." To me, forbidding a company from trying to demonstrate that its product is more secure than its competitors' is anti-competitive.
> Would Google publish their own vulnerability if they were unable to fix it in 90 days?
Maybe, maybe not. Presumably since Microsoft has so many employees and cares so much about security, it has its own team of researchers dedicated to finding bugs in Chrome, right? Or is it Google's responsibility to find everyone's bugs, and then give them as much time as they want to fix them?
> It becomes blackmail under certain circumstances, like where you're threatening to harm someone [illegally?]...
As a general rule, if I take action A and action A will result in a higher probability of harm coming to anyone, whether it's illegal or not...I'm a bad guy. Whether you call it blackmail or not, Google is the bad guy here.
> Yup, sounds like competition to me.
Oh good. I hope you can still apply the same logic if your personal bank gets attacked and your money is stolen because of the fact that Google decided to release detailed information to the mafia.
> ...explain why you think this is "anti-competitive."...forbidding a company from trying to demonstrate that its product is more secure...
That's not what's happening here. Google is not demonstrating any product here. The guy who runs Project Zero stated that “People deserve to use the internet without fear that vulnerabilities out there can ruin their privacy with a single website visit,”.
Do you think Google's action here has resulted in more or less of a probability of harm coming to users here?
In what world does the recipe for Coca Cola in any way influence the maintenance of a fleet of trucks?
Google's policy is responsible disclosure. Wavering on the well-known deadline would become a political headache. If you give a mouse a cookie... Two days becomes a week; a week becomes half of a month; half a month becomes a full month. Perhaps if Google is feeling generous, they could not disclose a vulnerability to a vendor until a later time (for example, if a vulnerability is found just before a well-known extended holiday or something) thus automatically "extending" the expiration of the quiet period. But that still leaves us, the users, more vulnerable for longer if the bad guys were already aware of the problem.
On a slight tangent, Microsoft's policy to not release security patches as soon as they're available (and instead wait until "patch Tuesday") harms us all. They don't have to forcibly push the fixes, but immediate availability would be a tremendous improvement.
Which they're doing with Windows 10. Consumers get them now, business get them on Tuesday. Have you ever deployed patches to a couple thousand machines? It's not something you want to do every night.
When to deploy patches to my thousands of machines is my administration problem, not Microsoft's. Giving me the tools to make these decisions puts more power to protect my company into my hands. Denying patches to me simply to fit a schedule denies me flexibility and, potentially, security.
Microsoft first has to test and deploy the patch to their servers, not yours. At the level they're operating, a schedule seems like an obvious requirement for releasing patches.
Of course they have to test internally first. Once the patch is validated, why sit on it for three weeks waiting for that arbitrary date? Put it out as soon as it's ready.
You act like security vulnerabilities aren't important. If Google found that security vulnerability, how much black hat already found it or are going to find it in the next 90 days? Sadly we can't know, that's why we need to set a schedule, there's no soon enough.
Everyone is saying that Google should have waited for Microsoft's patch day, but why should Google bend their standard procedure to fit Microsoft? If it really meant that much to Microsoft, they could have released a patch earlier.
They knew they had 90 days and decided to ignore it.
All the more reason for Microsoft to get to it and release the patch sooner. MS had already said they intended to delay the fix until February. The 90-day deadline seems to be Working As Designed®
Because "They don't have all of the OS code so they have no idea how much other code would have to be rewritten to correct the problem." and "That extra coding takes time to ensure that something else doesn't get broken in the process."
There is going to be a huge difference in speed based on size alone, but MS also has a much greater commitment to regression testing than Google ever has.
Google has embraced an engineering culture where the security team can contribute fixes directly to their own projects. I imagine this creates an unreasonable prejudice culture about how easy it is to implement fixes without concern for regression issues. You can see examples of this in recent e.o.y will not fix bug closures in AOSP. Those savants are going to set the usability vs security debate back a decade by by marking all http connections as insecure.
Finally, don't forget that Eric Schmidt agreed to a recruiting cease fire. For. All of their pride and arrogance, those Google security engineers are never going to escape the fact that they have compromised their own potential maximum value so they can sneer at other companies cultures.
Look, I'm been really happy with a lot of the stuff Microsoft has been doing recently, particularly in open source. But this is ridiculous. They had plenty of notice that Microsoft's standard 90-day (90 day!) policy applied, and that no exceptions were going to be made.
I applaud Google for not bending on their 90-day deadline (assuming they do hold all companies to that, and it appears they do). Maybe this incident will help encourage some companies that might otherwise be lax when confronted with a bug to hurry up. There's no telling who else knew about this bug and was actively exploiting it (probably lots of people).
> There's no telling who else knew about this bug and was actively exploiting it (probably lots of people).
You have no reason to believe it was a "lot of people." In fact we have no reports of people exploiting it in the wild at all, unless you have some information we don't.
edit: Downmod me all you wish, but substantiate your claims. Where is this being exploited in the wild before Google released it?
My exact phrase was "there's no telling", which is meant to indicate uncertainty. We don't know who or how this was exploited (if at all).
But I agree with you that I shouldn't have written "probably lots of people". I have no basis for that assertion. I retract that sentence (but not the rest).
By the way, I didn't downvote you. In fact, I almost certainly would have even upvoted your comment if you hadn't made the edit complaining about the downvote (against HN guidelines) and accusing me of downvoting you (false accusation).
As a general rule, you should never assume that the person you're disagreeing with was the one who downvoted. Many of us on HN only downvote people who are making low-information comments (which your comment was not, indeed it made me reconsider an assertion) or comments made in bad faith (yours was not, as far as I know).
Personally I feel like they should allow stuff like 2 days more, but they would need to be really strict about it.
Reading the comments on the ticket however, I really feel like Microsoft was in the wrong here. They asked 4 days ago to push it for a whole month and then now they are fine for their January release. I really feel like they start to feel the pressure of the 90 days so being strict about it is a good choice from Google.
Graham Cluley isn't a vulnerability researcher; he's a blogger and former antivirus author. Old school antivirus people are like the opposite of vulnerability researchers.
It seems reasonable for Google to release the details of the bug. If they make an exception for one company they'd have to start making exceptions for all companies. Microsoft is at fault here for not fixing this on time.
The linked bug shows that it was discovered Sep 30 and revealed publicly on Dec 30. Thus MS missed the deadline by two weeks, not two days. I agree there should be some flexibility but where do you draw the line?
If I were MS I wouldn't complain on this issue and instead I would just take the bait and put an internal team to find out bugs exclusively in Google products like for instance Android [1] and declare an arbitrary short disclosure policy [2] and then release these bugs when time is up.
Google's action resulted in a security bugfix which improved the security of Windows, and on faster schedule than Microsoft would have provided otherwise. But sure, let's call it evil.
Microsoft's patch schedule was going to be 32 days later. The hard stance produced a positive outcome here; the patch was available a full month earlier than it otherwise would have been. There is a lot of history between security researchers and big vendors, where the big vendor just delays and delays and delays while the bug is running around out in the wild.
I really do hear what you're saying, and while I'm sympathetic to it, I think that it's much more likely that the Project Zero team adopted the 90-day policy specifically because of years and years of vendors playing push-the-deadline. If there was an industry history of vendors acting promptly in good faith, this wouldn't even be a thing, but the politics behind bug reporting and disclosure are really pretty mature at this point, and I really do think it's naive to just chalk it up to "Google wants to embarrass its competition and is playing dirty to do it".
Google expended their resources to find a flaw in a MS product, in which MS was treated as any other vendor. If MS requires the ability to dictate the time alloted to fix their own mistakes, and are unwilling to change their own internal priorities for the sake of their own user base. Then perhaps, they should have found and fixed this prior to Google needing to point it out for them? I am amazed at the blind hatred for Google on this when MS has had a less than spectacular performance with its patches in the last year. Did all the MS fanbois forget about the bsod's just a few months back from MS's own "flawless", as you all seem to believe, patch schedule? (MS14-045 and MS13-036) If this deadline, self imposed by MS, is so greatly beneficial to MS patching why didn't the magic of patch Tuesday prevent those incidents?
Even given that Windows 8.1 is a large and complicated machine, what was it about this particular bug that required basically all of Q4 for MS to patch it?
It's one bug.
I have a sinking suspicion that MS simply didn't consider it a priority, even after responsible disclosure to them, which is why it's good that Google's public disclosure policy is a hard-limit 90 days. Too many companies, when given the option to choose their own priority tree over the priority tree enforced by security needs, will choose the former.
164 comments
[ 3.0 ms ] story [ 212 ms ] threadTheir 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.
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 f...
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.
MS is a huge company with an immense installed base and they have to be understandably careful with pushing updates. Working with them to disclose vulnerability on their regular patch day really wouldn't be such a bad thing for either Google nor the end users, even more so as we're talking about two days here and there even was a holiday week in the timespan.
This is about being an ass and I see no advantages for end users.
Even if Microsoft had not responded to Google at all, they could have waited for full three patch days (again, MS' patch deployment timeline is very much public knowledge by now) before publicly disclosing the issue.
Yes. Google designed Project Zero to "pressure firms into dealing with security problems more quickly." A firm policy with unambiguous enforcement has its advantages. Muddying the 90-day deadline with questions about when (and for whom) to make exceptions weakens it. For example, in the future, I expect Microsoft will not wait the extra two days in the event of a security disclosure from Google.
One may disagree with the 90-day policy to begin with. I, for one, think it should have had an exception process built in. But while these are Google policies, not laws, I respect them for adhering to published protocol. Even when it was difficult.
Microsoft do issue out of band updates but they are very rare and for very serious issues.
It isn't like Microsoft was stalling for time, they didn't ask for months, they asked for days to fir into their scheduled releases. It's also worth pointing out the enterprises time things on the patch Tuesday cycle. An earlier release causes all sorts of implementation problems, especially if only a day or two in advance. In all likelihood you wouldn't see many machines actually updated in that period, but cause significant extra grief.
Then again what does Google care, they don't use or support anything Microsoft, so it doesn't affect them.
As does Google Earth, Google Drive, the android development toolchain, and a handful of other desktop clients that I'm not going to bother to look up right now.
It seems to me Microsoft is like that student who has 3 months to do a project, but waits until the last 2 days, and then asks the professor to give him some more time. It was Microsoft's responsibility to patch the bug at the last Patch Tuesday.
It's just like being late for work. "But I was only 5 minutes late." Late is late.
As far as I know, some other engineering areas have even the safety factor of 2 or 3. That means, you expect the stress x, but your process has to sustain even 3 x.
Edit: Zero tolerances are never a good idea.
http://civilrightsproject.ucla.edu/research/k-12-education/s...
Even so, this is a clash of two policies and Google needs to reevaluate its deadline (is 120 days better for everyone, including users?).
Perhaps responsible disclosure occasionally requires considering the unique circumstances of each security flaw?
This looks like a solution, but isn't. Perhaps Google's 90 day deadline is already a re-evaluation of a 60-day deadline that was made to accommodate holidays and companies with a once-a-month patch schedule. If Google's deadline was 120 and still hit two days before patch Tuesday, would you say the same thing but for 150?
(N.B. I'm not defending Google, just poking a hole in this particular idea.)
Which is a dumb policy for security patches. When its fixed it should be released.
> If Google isn't willing to wait the two additional days such that the patch can be deployed within the regular update window, this means that Google effectively gives MS only 60 days to react and fix issues (because once they missed the second patch day, the vulnerability will be disclosed before the third).
Google doesn't dictate Microsoft's patch releasing policy. 90 days are 90 days. Microsoft doesn't have "only 60 days", they have 90 days like anyone else, and they chose to miss it by adhering to a policy of their own choosing that makes security patches less timely.
The whole purpose of a fixed 90-day window is to give reasonable time to fix a security vulnerability but also to create pressure to do so timely. Making exceptions for vendors to accommodate existing policies that make security fixes less timely would both increase the effort for Google (as a fixed time window is always easier to implement than one that varies with each vendors policies) and undermine the whole purpose of the 90-day timeline.
Applying the patch a few days later typically doesn't noticeably increase your risks but rolling them out unchecked can make some serious damage.
Before, many enterprises rarely patched because the testing involved was a huge pain and it fell outside what they typically planned for.
If you don't want to apply the patches as soon as they're released, then you'd be more than welcome to put them on hold for 4 weeks yourself when it's more convenient.
There are bad guys looking for 0-days out there. If they learn about the vulnerability from the patch, at least the world has the patch before the bad guys do. Now it's the opposite.
Edit: See _wmd's explanation about the technical details of all this in the same level of the answers.
Your options become either to release an update the moment it's tested, immediately making vulnerable customers who have a change management policy (usually also the biggest and juiciest targets - fortune 500s including ironically the likes of Google), or delay any release until some coordinated date, giving everyone an equal and predictable opportunity to cope with the exposure, which is how Microsoft do it.
What are the chances that attackers or other agencies already know of these vulnerabilities and are exploiting them?
Microsoft's delays extend the time that the silent attackers have.
Releasing the patch late (i.e., on patch day) makes that choice for everyone.
It's not that just the big companies are affected now: all users are.
Large enterprises already have centralized patch management, so they can decide how fast it gets pushed downstream to their users after MS releases the patch.
You apply a dozen different fixes and test. Something breaks badly. You now have a dozen different root causes to check when, if you applied one at a time and tested (or applied one at a time and let your users test it, which is more commonplace than it should - automated testing tools exist for a reason) you'd know what broke.
I'd prefer to have fixes available for rollout as soon as possible and to decide whether I deploy them or not based on my tests. Automatic mandatory deployment could be on a fixed schedule, for those who can't test or don't care much about it.
I haven't come across a source for that. Does one exist?
For all I know, Microsoft announced it in reaction to the publication, but I have no clue Google could have been made aware of it beforehand.
Edit: nevermind, I've found one.
You are new to IT aren't you?
Failure to blindly adhere to the common view isn't the same as being new.
If Google (or any other group that discovers security issues) has to take into account every policy of every software producer it becomes utterly impossible to have any disclosure policy.
If MS wants to handicap themselves, that's their problem. The rest of the world doesn't have to bend to their will, those days are over.
Yes, this is about being an ass. And it's Microsoft that's being an ass by claiming the rest of the world should take into account their peculiar policy.
Please don't sit on a fix until the time is more "convenient", give it to me now and let me be the judge on how important this security patch is to me.
Let me remind you: https://news.ycombinator.com/item?id=8728336
Disclaimer: I work for TAGA (The Arrogant Google Assholes)
>"We asked Google to work with us to protect customers by withholding details until Tuesday, January 13, when we will be releasing a fix," Microsoft's senior director of research Chris Betz said in a blog post.
The issue mentioned in the article [https://code.google.com/p/google-security-research/issues/de...] says that:
> Microsoft confirmed that they are on target to provide fixes for these issues in February 2015. They asked if this would cause a problem with the 90 day deadline.
< Microsoft were informed that the 90 day deadline is fixed for all vendors and bug classes and so cannot be extended. Further they were informed that the 90 day deadline for this issue expires on the 11th Jan 2015.
So (a) Microsoft is unable to comprehend a simple 90-day policy or (b) do basic math.
Personally, I don't think Google should bend to the internal red tape of other companies. You are going to start maintaining this long list of exceptions based on other peoples priorities. There is a published 90 day policy, they gave 90 days notice, figure it out. There is also details missing about the communication between Google and Microsoft. Like when they asked for an extension, etc.
You start out with two days because of patch tuesday. Then next time a bug is reported, well, this is a busy month with lots of people on holiday, if we could have an extra 10 days? And the next time, we're really close to releasing Service Pack N, the fix will be in that but it's got lots of changes - it'll be out in 60 days...
If you don't have it, then you have a lot of time wasted on communication, handling special exceptions, making decisions if you should bend it or not and so on.
Its worth noting, as pointed out upthread, that the only reason it was released in January at all was because when Microsoft asked if their planned February release was going to cause a problem with the 90-day deadline, Google informed them the the 90-day deadline for that bug was 11 January and that that's when disclosure would occur. Clearly, the fixed deadline already achieved part of what it was intended to -- encouraging vendors to fix security issues more quickly.
And I'm not sure that there even exists such a thing as a "common sense exception" to that policy, but extending it simply to accommodate a vendor schedule that delays releases of security fixes to predetermined dates isn't such a common sense exception even if any exist. Its simply favoring the bureaucracy of fixed patch schedules over the purpose of the disclosure policy, which is encouraging vendors to more timely release fixes for security bugs.
So is this what the disclosure issue is going to look like when packaged up for the masses? No historical context on how the ongoing disagreements are the latest in decades of ongoing discussion? Or any mention of the events that shaped the popular ideas today? Just a sour blogpost and some bland quotes of agreement and disagreement from an internet so large you can always find quotes for the positions you want to portray. We're so fucked.
Edit: And apparently it worked on us too. Of course external messaging is going to paint the other guy as the unreasonable one.
I am in general a huge Google fan, but in using Google services I realize that I am not much of a customer (I purchase extra storage and buy stuff on the Play Store); advertisers are the customers.
Microsoft on the other hand gets its money from computer users and it seems like they have a much more customer focused mentality.
(neither, or both)
> Historically, it's more likely...
But going on what is actually known, less people knew before Google's actions than after.
EDIT: More accurately: We know that the information was definitely available after Google's action. We don't know that the information was definitely available before.
Why do you say this?
It implies a world where software is almost perfectly secure, and there are only a few bugs to fix, and then it's perfectly secure, and we are all happy.
In reality, there are effectively an infinite number of bugs out there, many with security holes. Finding one and going through the motions to fix, patch, test, and release still leaves you software with plenty of open holes.
If you magically theorize "the bad guys know about all the holes already," then they are still going to exploit all the other holes in the system, because they magically know about them, too.
How many people does google have sockpuppetting social media? My goodness.
>> "Google's Project Zero seeks to find bugs in popular software and then give the manufacturers responsible 90 days to fix the problem."
Seems reasonable.
>> "On 11 January, Google publicised the flaw. Microsoft said it had requested that Google wait until it released a patch on 13 January."
Dick move. Sorry, I can't think of any other way to describe it. They may have waited until the last minute (or maybe they really did have to rewrite a tonne of code) but that's no excuse or putting users at risk when you can wait two days. Seems more like a marketing tactic than a desire for faster security patches.
[1]https://news.ycombinator.com/item?id=8873704
https://code.google.com/p/google-security-research/issues/de...
So basically Microsoft asked for an extra month, and they said no, which forced them to move quicker, and fix it a month earlier. Without picking any side of the debate, you can still see what effect the non-negotiation of timeline has on getting patches out as soon as possible.I work in information security and patches are important, I understand. But it worries me that what we're basically seeing here is corporate warfare using security vulnerabilities. What gives any company the right to publish vulnerabilities about their competitors, especially when it has the chance to impact their competitor's performance? Does Pepsi have the right to demand Coke rotate the tires on their trucks within 90 days or they will publish the recipe for Coca Cola?
If we ask "what gives any company the right to publish vulnerabilities about their competitors?" it's only a short step to asking "what gives journalists the right to publish scathing negative reviews?" The answer is the same: freedom of speech.
It's a fact of life that if you want to fix security bugs, that takes time away from working on other things. If you don't like it, fix the bugs faster, or pay more attention to security from the get-go. Microsoft should be thanking Google for finding the bug in the first place.
Journalists are not directly competing with tech companies. Google is. Imagine the next bug they find in Windows, and they publish it saying "ChromeOS doesn't have this bug!". They already use their search to push their browser, why not use their bug reporting to push their OS? When does free speech stop and anti-competitive behavior start? Would Google publish their own vulnerability if they were unable to fix it in 90 days?
So? As a general rule, people (and companies) have the right to say things like "I'll do X if you do Y" or "I'll do X unless you do Y". It becomes blackmail under certain circumstances, like where you're threatening to harm someone illegally, or demanding money for covering up a crime. In this case, Google picked a 90-day disclosure timeline which seems to be considered generally reasonable by the security community, so I don't see how they're doing anything wrong by sticking firmly to it.
> Google published it anyway, because their competitor didn't work fast enough, for Google's definition of "fast enough".
Yup, sounds like competition to me.
> Imagine the next bug they find in Windows, and they publish it saying "ChromeOS doesn't have this bug!".
Yup, sounds like competition to me.
Maybe I'm just being dense but it would help if you could explain why you think this is "anti-competitive." To me, forbidding a company from trying to demonstrate that its product is more secure than its competitors' is anti-competitive.
> Would Google publish their own vulnerability if they were unable to fix it in 90 days?
Maybe, maybe not. Presumably since Microsoft has so many employees and cares so much about security, it has its own team of researchers dedicated to finding bugs in Chrome, right? Or is it Google's responsibility to find everyone's bugs, and then give them as much time as they want to fix them?
As a general rule, if I take action A and action A will result in a higher probability of harm coming to anyone, whether it's illegal or not...I'm a bad guy. Whether you call it blackmail or not, Google is the bad guy here.
> Yup, sounds like competition to me.
Oh good. I hope you can still apply the same logic if your personal bank gets attacked and your money is stolen because of the fact that Google decided to release detailed information to the mafia.
> ...explain why you think this is "anti-competitive."...forbidding a company from trying to demonstrate that its product is more secure...
That's not what's happening here. Google is not demonstrating any product here. The guy who runs Project Zero stated that “People deserve to use the internet without fear that vulnerabilities out there can ruin their privacy with a single website visit,”.
Do you think Google's action here has resulted in more or less of a probability of harm coming to users here?
Google's policy is responsible disclosure. Wavering on the well-known deadline would become a political headache. If you give a mouse a cookie... Two days becomes a week; a week becomes half of a month; half a month becomes a full month. Perhaps if Google is feeling generous, they could not disclose a vulnerability to a vendor until a later time (for example, if a vulnerability is found just before a well-known extended holiday or something) thus automatically "extending" the expiration of the quiet period. But that still leaves us, the users, more vulnerable for longer if the bad guys were already aware of the problem.
On a slight tangent, Microsoft's policy to not release security patches as soon as they're available (and instead wait until "patch Tuesday") harms us all. They don't have to forcibly push the fixes, but immediate availability would be a tremendous improvement.
They knew they had 90 days and decided to ignore it.
I guarantee you that if this was an Android bug that the Android team would have gotten 2 more days.
That's the inconsistency here.
God help Google if an Android bug is discovered that takes them more than 90 days to patch across their 123421 variants of fragmentation.
Google headcount: ~49k MS headcount: ~130k
There is going to be a huge difference in speed based on size alone, but MS also has a much greater commitment to regression testing than Google ever has.
Google has embraced an engineering culture where the security team can contribute fixes directly to their own projects. I imagine this creates an unreasonable prejudice culture about how easy it is to implement fixes without concern for regression issues. You can see examples of this in recent e.o.y will not fix bug closures in AOSP. Those savants are going to set the usability vs security debate back a decade by by marking all http connections as insecure.
Finally, don't forget that Eric Schmidt agreed to a recruiting cease fire. For. All of their pride and arrogance, those Google security engineers are never going to escape the fact that they have compromised their own potential maximum value so they can sneer at other companies cultures.
Toxic and stupid.
I applaud Google for not bending on their 90-day deadline (assuming they do hold all companies to that, and it appears they do). Maybe this incident will help encourage some companies that might otherwise be lax when confronted with a bug to hurry up. There's no telling who else knew about this bug and was actively exploiting it (probably lots of people).
You have no reason to believe it was a "lot of people." In fact we have no reports of people exploiting it in the wild at all, unless you have some information we don't.
edit: Downmod me all you wish, but substantiate your claims. Where is this being exploited in the wild before Google released it?
But I agree with you that I shouldn't have written "probably lots of people". I have no basis for that assertion. I retract that sentence (but not the rest).
By the way, I didn't downvote you. In fact, I almost certainly would have even upvoted your comment if you hadn't made the edit complaining about the downvote (against HN guidelines) and accusing me of downvoting you (false accusation).
As a general rule, you should never assume that the person you're disagreeing with was the one who downvoted. Many of us on HN only downvote people who are making low-information comments (which your comment was not, indeed it made me reconsider an assertion) or comments made in bad faith (yours was not, as far as I know).
Reading the comments on the ticket however, I really feel like Microsoft was in the wrong here. They asked 4 days ago to push it for a whole month and then now they are fine for their January release. I really feel like they start to feel the pressure of the 90 days so being strict about it is a good choice from Google.
If the Project Zero programmers were independent or malicious, they could have sold this information or released it without giving the 90 day window.
Seems like Google is trying to do the right thing by alerting others on these flaws and holding a fast deadline to fix it.
[1] https://news.ycombinator.com/item?id=8874339
[2] https://nakedsecurity.sophos.com/2010/06/15/tavis-ormandy-pl...
What does Google care? I get the impression they care about not much else than ads and HUGE NUMBERS of users.
Unless it hurts a competitor and is bad for their customers.
I don't believe for a second that they would have disclosed this if it was Android and they had a fix that would land within 2 days. No f'ing way.
That's the evil.
I really do hear what you're saying, and while I'm sympathetic to it, I think that it's much more likely that the Project Zero team adopted the 90-day policy specifically because of years and years of vendors playing push-the-deadline. If there was an industry history of vendors acting promptly in good faith, this wouldn't even be a thing, but the politics behind bug reporting and disclosure are really pretty mature at this point, and I really do think it's naive to just chalk it up to "Google wants to embarrass its competition and is playing dirty to do it".
Even given that Windows 8.1 is a large and complicated machine, what was it about this particular bug that required basically all of Q4 for MS to patch it?
It's one bug.
I have a sinking suspicion that MS simply didn't consider it a priority, even after responsible disclosure to them, which is why it's good that Google's public disclosure policy is a hard-limit 90 days. Too many companies, when given the option to choose their own priority tree over the priority tree enforced by security needs, will choose the former.