Slashdot Mirror
Microsoft Sits on Security Flaw for Six Months
pmf writes "Yet another critical vulnerability affecting Windows 2000/XP/2003 has been just announced by eEye. It is worthy to note, that it took Microsoft over 6 months to fix it. The bug affects ASN.1 library and is remotely exploitable through authentication subsystems (Kerberos, NTLMv2) and applications that make use of SSL certificates." The AP has an overview.
didn't The Gates himself said not so long ago that they were "as fast or faster" than opensource in fixing security flaws?
i don't have the quote on hand though...
"Microsoft Corp. warned customers Tuesday about unusually serious security problems with its Windows software that could let hackers quietly break into their computers to steal files, delete data or eavesdrop on sensitive information." What "usually serious"? Code Red? Nimda?
Also, Microsoft's own document on "Trustworthy Computing" (warning: MS Word format!) establishes as a goal that "[t]he company is open in its dealings with customers. Its motives are clear, it keeps its word, and customers know where they stand in a transaction or interaction with the company." I suppose that waiting six months before fixing this "unusually serious" problem somehow satisfies that criterion?
A very big deal is going to be made about this. Feel free to correct me (or mod me down) if I'm wrong, BUT:
From my understanding, this is a heap overflow. Given the nature of the heap, I could see this resulting in a DoS condition, but what is the likelihood that a practical exploit can be developed, given that the heap generally contains data in random locations?
akad0nric0
This sentence no verb.
Your post seems like FUD to me. Now I'm no expert, so I could be wrong, but are there not several proprietary programs that are no longer supported? The key difference of course being that with a non-supported proprietary app you have no chance of getting support. With OSS you could get the source code and either learn programming or hire a programmer to add support for you.
Have you tried Linux yet?
I use to work at HP Ft. Collins in the early 90's. At that time, there was a major hole in the network code of the that was going to take about 6 man-months to fix. The local management decided to not fix it as it was decided that few knew about it and it would not be a problem. I would suspect that every major company does the same thinking; MS, Apple, Sun, SGI, IBM, etc.
I have no doubt that all these companies do care a bit more due to the pressure being brought, but it will still be a decision similar to what Ford did with Pinto and who it was did the tires that exploded. If it costs money to fix, but nobody will see it, who cares.
That is one of the advantages of OSS as everything is in the open. Have to fix it or will suffer big.
I prefer the "u" in honour as it seems to be missing these days.
So, you're happy that eeye - a company you don't have any relationship with - has had access to your computer for the last six months? And that's fine with your customers, too?
Ok, what about someone else who found the hole independently? Or, what if someone has broken into eeye's systems and has been monitoring their email for a "heads up" on unreleased flaws. (or the home computer of a microsoft security person). Or someone at their ISP or on their cablemodem monitoring their email. You're happy to give all these people access to your computer, too, right? Compartimentilization is very hard to do outside a rigorous structure (like the NSA) which has very strict rules, procedures, and punishments to allow enforcement.
A virus or worm that takes advantage of this flaw is only one indicator - people using the flaw for other purposes are probably not going to tell the world about it. The point is that it's impossible to tell if no harm has been done.
HIV Crosses Species Barrier... into Muppets
- Blame the developer for creating the bug.
- Blame QA for inadequate testing.
- Blame management for not accepting responsibility and getting it fixed ASAP.
- Blame marketing and account reps who don't recognize this will hurt sales.
- Then, when you're almost done, blame the developers again for their lack of pride to not demand the right to fix their code.
Just because you find someone to blame does not make everyone else on the team blameless.Bít, zabít, jen proto, ze su liska!
Stop the Slashdot effect! Don't read the articles!
Now why do you presume it's kids....
I'm far from a kid and use Linux in a work environment. We also use OS/390, VMS, and yes Win9/2k/XP.
The "M$" has little to do with Linux. It has everything to do with M$ and it's defacto monopoly, it's penchant for sucking the cash cow, and showing that ogranization the respect it 'deserves'.
And when will you windoze kiddies learn it's Linux and not Lunix and that the gpl isn't viral (or we'd have windows on gpl - see MS services for Unix and in particular it's gpl components), that proprietary (and paid for!) software can be purchased for it. And that it supports most hardware. We actually did better with linux than with Win2K, driver wise, back when they were both new.
On the issue... A six monthg turnaround? You must be kidding me! It was only a week ago Bill was, falsely, claiming a one day turnaround versus weeks for Linux (typically it's less than a day).
Any windows setup, mine included, was a potential target for abuse due to this. You have to trust M$ employees not to leak it, the finding company's employees not to leak it, and the black hats community to not find it.
That is a ridiculous situation for any company to be in and it's unsatisfactory performance for any software supplier let alone one who tries to claim they're the best... M$ showed zero respect for the operations of your organization and zero respect to each and every individual customer by allowing them to face that risk without warning.
I would never trust our critical business operations to Microsoft. They have repeatedly violated that trust.
There is enough blame to go around in these situations:
* Blame management for forcing tight deadlines on the developer who writes shoddy code, creating the bug.
* Blame management for limiting the time and resources for QA to develop and execute test cases which results in inadequate testing.
* Blame management for prioritizing new sales to support, thereby not accepting responsibility and getting it fixed ASAP.
* Blame management for structuring sales compensation so that marketing and account reps don't care about what happens after the sale, and so don't recognize this will hurt sales.
* Then, when you're almost done, blame the developers for needing food, clothing and shelter, and getting beat down when they say anything, which gives them lack of pride to not demand the right to fix their code.
I'm sure this is what you meant to say, right?