4 ms·
Because a Windows zero-day is a major risk to our economic system as our business and governments infrastructures run on MS products for the most part. OSX jus
by drzaiusapelord 12y ago
Because a Windows zero-day is a major risk to our economic system as our business and governments infrastructures run on MS products for the most part. OSX just doesn't have that level of install base and for the most part its installed on consumer/residential equipment. Heck, most OSX shops I've been part of have bog standard Windows AD on the back-end. Windows, good or bad, is everywhere that matters.
Google seems to think Windows is a poorly written php app where you can just change a line and walk away. Windows testing has to be top notch and handle a huge about of 3rd party software, libraries, and drivers. The 90 day deadline really speaks to how web devs think and not how application engineers with massive install bases on a variety of equipment and running a variety of software think.
It does piss me off to be honest. MS isn't saying no to the updates its just saying, "We're doing them in 100 days, not 90 as out of band patches are really bad for the ecosystem and we need more time to certify our changes." Google is saying, "Fuck you. Buy an android tablet, microserfs."
Imagine if Google found the Kaminsky DNS bug. The internet would have melted on day 91 when google told everyone, "Sorry, too bad." I think this kind of "fuck you" disclosure should only be for attacks that have been demonstrated to be in the wild. Now they will be in various crimepaks, botnets, and trojan droppers within hours.
- mikekchar 12y agoI used to work on telephone switches. We had 31 million lines of code. I can't remember the entire details since it was over a decade ago, but I believe Bellcore required us to deploy fixes for 70% of all reported bugs within 30 days. We were a huge, fat-ass company with 5000 programmers working on the same project and managed this. 90 days is a lifetime to fix a security problem. The point behind having a deadline before publicly disclosing is that if one person has discovered a security problem, then some other people probably have as well. It is fair enough to give vendors time before you make disclosure but if the vendor is moving too slowly -- for whatever reason -- you want to give the consumers a chance to implement their own security work around. Because if you don't they are vulnerable. Giving Microsoft 90 days to fix an issue is fine. They can prioritize it anyway they want. If they think it is super urgent, they can almost certainly get a fix out. If they think it is not so urgent, then they don't have to make a fix -- but they know that the problem will be disclosed. Nowhere in Google's documentation of this problem do I see a massive issue. Google gave MS 90 days. MS found a fix but there was another bug so they couldn't meet the window. Google released the information. Nowhere do I see MS requesting more time or any indication that anybody in the process thinks that anything went badly at all. It didn't meet the disclosure deadline. That's just the way it goes sometimes.
- smt88 12y agoYou had one system on, at most, a few thousand machines, and those machines were tailored to the software. The still-supported Windows versions, by contrast, are 50+ million lines of code EACH installed on hundreds of millions of machines EACH. Your telephone switch analogy is just not even in the same solar system as what Microsoft is dealing with. I'm not saying 90 days is necessarily too little time, I'm just saying your reasoning is totally flawed.
- lern_too_spel 12y agoThe Kaminsky bug was disclosed 30 days after it was announced, and by then, pretty much the entire internet had been patched. Google is being generous with 90 days, and Microsoft is being utterly incompetent.
- huhtenberg 12y agoThis is trolling.
- Malician 12y agoIt's a reply to a poster who said, "Imagine if Google found the Kaminsky DNS bug. The internet would have melted on day 91 when google told everyone, "Sorry, too bad." Given this, if the Kaminsky bug was fixed in 31 days, that seems like a very bad example to use.
- boie0025 12y agoIn my experience, the only kind of PHP (or any) app where you can change just one line and walk away is a well written one. It's the poorly written ones where you have to change dozens or hundreds of lines, and run away screaming. But point taken.
- danielweber 12y agoThe issue isn't fixing the flaw. The issue is testing. Say I patch a security flaw in a webapp I run. If I screw up the phone starts ringing, and then I undo the patch I made and think some more about it. Meanwhile no one has any clue about the flaw. If I have to deploy a release to fixed endpoints, I have to think about what could possibly go wrong on every device out there running my software. Plus, if I didn't fix the problem completely, the nature of distributing the patch has now told the rev-eng community exactly where the problem was. Google once pushed out a version of their browser that stopped the entire browser from working when their sync server went offline (for anyone using sync in their browser). Microsoft does not want even 1% of their users to suddenly be unable to use their computers.
- haneefmubarak 12y agoThen perhaps MS ought to shorten its bug fixing period. Three months is quite a long time to find a bug, fix it, and run extensive tests. What good is a fixed time period if you're willing to extend it just because one company can't pull their shit together? As for the Kaminsky DNS bug, it was leaked more than a solid week ahead of the time he intended to release it. Sure, patches had already been released, but how about if other companies had said, "We need a full month to test this patch prior to rolling it into production."? They would have been putting themselves at risk. Mind you, this bug was simply an extension of an earlier flaw - too small a range of transaction IDs, and some DNS projects (`djbdns` comes to mind) had already mitigated it (ostensibly fixing the root cause as opposed to the symptom). Had the other vendors mitigated that flaw in a similar fashion (they had almost a decade since djb pointed it out), they would not have been vulnerable. However, there was no looming deadline, so few of them even noticed until an actual attack was possible (as opposed to fixing issues as they come up). What happens if someone leaks the bug early? Or if a malicious adversary discovers the bug at the same time? The whole idea of these deadlines is to force security bug fixes to be released ASAP, taking precedence int time and importance over all else. Deadlines can't be adjusted just so MS can screw around for longer doing nothing. If it's really taking them more than three months to fix a bug and release patches, perhaps they need to rethink their priorities and dedicate more resources to the task. And perhaps we need to seriously reconsider our dependence on their products.
- gtirloni 12y agoEverybody is saying that 90 days is too much, even at MS' scale. So, taking into account that everybody seems to know very well what MS has to support, what is a good number of days to finish all the work that needs to be done?
- haneefmubarak 12y ago90 days seems just fine. What they need to do is give greater importance to bugs and apply more resources accordingly. When it actually affects them, they aren't hesitant to do whatever the hell it takes, with no regards as to the consequences for others, with zero warning at all, as was shown during the whole fiasco when they effectively took down NoIP's services. Meanwhile, when Google holds them to a perfectly reasonable deadline, for the extremely valid reason that bugs should be fixed on time, Google is evil? Given their scale, they can afford to dedicate larger teams of people to the task of fixing security vulnerabilities. They can afford to hire independent security researchers and whatnot to help them find and fix such vulnerabilities. If they need to break some third-party application in fixing a security vulnerability, that's okay. Because that application can also be fixed by its developer, and security needs come ahead of an app here or an app there. Besides, it isn't as if users of Microsoft's products are not used to the concept of having stuff break all the time anyways. Have you noticed how quickly MS starts releasing patches and updates when a 0day comes out? That shows that they are clearly capable of doing whatever they need to do pretty damn quickly. They just don't do that with all security vulnerabilities, due to "business reasons", and as a result their customers suffer.
- bla2 12y agoAnother perspective is that Google found a bug through which they (and other businesses) can be owned, and ms is saying "fuck you" to google by not fixing it for months. Without this disclosure strategy, google wouldn't have any leverage to get bugs critical to their business (and to most other businesses) fixed. If your company is using windows, google is doing your company a favor.
- RogerL 12y agoYa, my comment was too brief. I was mostly reacting to the HN posters that basically were saying "Microsoft evil" by gently pointing out that other companies are leaving bugs in for longer than Microsoft. For example, someone posted "Other companies fix such bugs in days." Well, there are counterexamples, aren't there (OS X at the moment). I think what Microsoft is doing is really hard. I don't have insight into their process, having never worked there. So yes, we can speculate that they could do things much faster. But can they? I find it rather tasteless to just assume so with no evidence and to then go on and call them names. I dunno, maybe they are falling flat on their faces internally, or maybe the team is performing heroics at the cost of personal lives, or maybe it is just business as usual. But, it was also an honest question. Maybe there is evidence out there that Microsoft is just failing, and I haven't seen it or my reading comprehension failed me and I saw it but didn't register it. But mostly, I am tired of the hurl accusations and drag people&companies through the mud meme that happens here, and this seemed to be more of the same (again, open to evidence, not claims, to the contrary).