Microsoft Taking Longer to Fix Flaws
An anonymous reader writes "A look back at the last three years of security patches from Microsoft shows Redmond is taking at least 25 percent longer to issue patches for "critical" vulnerabilities, now averaging around 135 days to issue a fix. The exception appears to be with "full disclosure" flaws, for which Redmond issued fixes in an average of 46 days last year."
So they're concentrating efforts on the full disclosure exploits... and this is bad why?
If you look at the data, you will notice that some critical flaws were patched in less than 3-4 weeks. While that may seem long, it is somewhat reasonable due to the amount of verification/validation necessary. People forget that 95% of the world runs on M$ so they have to really test a patch before releasing it.
On the other hand... because so much of the world depends on M$, they have an obligation to its customers to provide a secure OS and timely patches. Personally, I feel they are doing an "ok" job and seem to be getting better. Alot of vulnerabilities can be avoided just by running your PC behind a router and/or by using a firewall application. Personally, I have NEVER had a virus at home on any of my computers because I take simple preventative measures like running Norton AV and AdAware. I also put all my pcs behind a router.
http://religiousfreaks.com/Imagine if their patch accidentally disabled * * * TENS OF MILLIONS * * * of computers. If that happened, they'd loose so much consumer confidence -- essentially loosing whatever gains (if any) they have made in the last several years (and billions in spending).
(okay, that did happen on a lot of sp2 systems, and MS is not loved for it)
MS has to ensure that the patch works on a staggering and dizzying array of systems and architectures (lots of different mobos, pentiums, AMD's, dual core CPU's, XENON's, via chips), and for dozens upon dozens of applications. That's why you often find that they'll often release a patch on NT or more server based systems before they release it for consumer systems.Another reason is that, depending on the type of problem, will do a full tracability check, and also cross reference all their code that references the changed module, and evaluate (probably manually) if they put that dependency at risk. A huge, horrible job, suitable only for type-A micro-detail oriented folks. I wouldn't want to do it!
If MS disabled TENS OF MILLIONS of computers, you would see a huge shift away from regular Patch Tuesday activities, towards one of 'install on a test bed' -- extremely tedious and manual that everyone would hate. Millions of people would be put out. Seriously bad Karma.
So, they can:
I'm sure at least someone is thinking "Heck: our flaws are the manure in which an entire security industry will grow in".
So I guess which approach you take depends on your goal. If your goal is the glory of a 0-day exploit, then post away. But if your goal is the security of the end user, maybe you should keep it to yourself for the time being.
You've made a number of incorrect assumptions and failed to consider several important concerns. First, is the vulnerability likely being exploited? Is the vulnerability able to be mitigated by users and if so, are there drawbacks to the fix? What systems would be made vulnerable?
For example, suppose I find a trivial exploit in code I know blackhats have already reviewed. That means there is a good possibility that it is being quietly exploited. Or what if I am running a network that needs network access, but is top-secret and would be disastrous if compromised. I find a flaw that has a work-around that requires disabling a service. This will cost hundreds of thousands of dollars a day, but I can't risk exposure. Should I:
Here's my general take on things. Windows machines will be compromised in huge numbers until MS gets their act together. Compromises to the average machine are not too important to me. Why do I care if 100,000 idiots turn into spam bots? Compromises to my system do concern me. The best way for me to keep my machine secure (and for other security conscious people who run important systems) is for me to be well informed about vulnerabilities. If there is a vulnerability in a particular service I want to know, so that I can disable it if need be, plan work arounds, migrate to a different service, and set up honey pots and IDSs to look for attacks or strange behavior.
To put it bluntly, in some cases it is best for me to publicly disclose vulnerabilities and in others it is not. To imply, however, that it has something to do with trying to garner fame or a reputation is very mistaken. In some cases the security of end users if better served by full disclosure, while in other cases it is not. It all depends upon the vulnerability.
Of course, what we can't see here is the long tail effect. How many Windows boxes are being exploited by holes unknown to the public, but that Microsoft is aware of. There is not any way to tell easily.
Heres a new benchmark that Microsoft would not like.
T.C.C.M.
Total Cost of Code Maintnence, how much does it cost to patch and test the base operating system source code per year? Microsoft vs Other commerical operating systems? Vs opensource operating systems.
The T.C.O Microsoft does not talk about is on there end, That is the price of closed source code.
Or a simpler explanation might be that, given a certain budget for fixing bugs/security flaws, they have to prioritize, and since bugs that have an exploit out in the wild are much more likely to have a negative impact, they get pushed to the front of the queue... which makes sense to me.
I don't think they set out to solve X bugs in Y months. I would assume they have a certain number of manhours devoted to fixing bugs, and fix however many they get around to. They can always increase the resources devoted to this, yes, but I doubt anyone over there says "oh, this one doesn't have an exploit in the wild, try to take as long as you can to fix it".
ClutterMe.com - easiest site creation on the Net. Just click and type.
It's more likely how long it takes to run that battery of test scripts on several hundred "typical" hardware configurations. It takes a while, we should not berate MS for testing, if indeed that is what is happening.
In all likihood they are diverting resources from patching to Vista so they can ship it sooner. This is bad.