4 ms·

2 days leeway is not uncalled for. Bad form Google.

by Beltiras 12y ago

nodata 12y ago
Didn't they give MS 90 days to patch? (That's two or three patch Tuesdays).
- shoggs 12y ago
  Apparently Microsoft needed some time for testing.
- pilif 12y ago
  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)
  - gizmo686 12y ago
    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.
  - tomiko_nakamura 12y ago
    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.
    - Someone1234 12y ago
      > So, who forces Microsoft to stick to (so called) patch Tuesdays? 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.
      - deleted 12y ago
        [deleted]
      - jdjb 12y ago
        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.
        Someone1234 12y ago
        > 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.
      - tomiko_nakamura 12y ago
        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.
    - matwood 12y ago
      it's Microsoft internal schedule 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.
- majc2 12y ago
  And they asked for 92 days and Google decided to publish anyway? While I'm not surprised, it doesn't strike me as the most responsible action.
  - tomiko_nakamura 12y ago
    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.
    - majc2 12y ago
      "Our objective is to significantly reduce the number of people harmed by targeted attacks." (http://googleprojectzero.blogspot.co.uk/2014/07/announcing-project-zero.html http://googleprojectzero.blogspot.co.uk/2014/07/announcing-p...) 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?
    - Beltiras 12y ago
      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.
- _wmd 12y ago
  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.
deleted 12y ago
[deleted]
spydum 12y ago
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?).
- cmdkeen 12y ago
  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?
  - orf 12y ago
    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.
  - doodpants 12y ago
    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.

2 days leeway is not uncalled for. Bad form Google.

nodata 12y ago

Didn't they give MS 90 days to patch? (That's two or three patch Tuesdays).

shoggs 12y ago
Apparently Microsoft needed some time for testing.
pilif 12y ago
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)
- gizmo686 12y ago
  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.
- tomiko_nakamura 12y ago
  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.
  - Someone1234 12y ago
    > So, who forces Microsoft to stick to (so called) patch Tuesdays? 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.
    - deleted 12y ago
      [deleted]
    - jdjb 12y ago
      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.
      - Someone1234 12y ago
        > 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.
    - tomiko_nakamura 12y ago
      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.
  - matwood 12y ago
    it's Microsoft internal schedule 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.
majc2 12y ago
And they asked for 92 days and Google decided to publish anyway? While I'm not surprised, it doesn't strike me as the most responsible action.
- tomiko_nakamura 12y ago
  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.
  - majc2 12y ago
    "Our objective is to significantly reduce the number of people harmed by targeted attacks." (http://googleprojectzero.blogspot.co.uk/2014/07/announcing-project-zero.html http://googleprojectzero.blogspot.co.uk/2014/07/announcing-p...) 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?
  - Beltiras 12y ago
    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.
_wmd 12y ago
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.

deleted 12y ago

[deleted]

spydum 12y ago

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?).

cmdkeen 12y ago
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?
- orf 12y ago
  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.
- doodpants 12y ago
  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.