Why Can't Microsoft Just Patch Everything? 640
paneraboy writes "If smaller software companies can patch all of their bugs serious or minor, ZDNet's George Ou asks, why can't Microsoft -- with its massive army of programmers and massive budget -- patch all of its vulnerabilities? Had Microsoft fixed a low risk browser vulnerability six months ago, perhaps we could have avoided last week's zero-day exploit. Currently, more than two dozen Windows XP issues remain unpatched. Ou thinks Microsoft ought to fix them all." From the article: "Almost 4 years after the launch of Trustworthy Computing, I found myself wondering why am I staying up till 4:00 AM to deliver an emergency set of instructions (Home and Enterprise) to my readers because Microsoft felt it unnecessary to patch a flaw six months ago that was originally low risk but mutated in to something extremely dangerous."
Good ole' 2002 (Score:3, Interesting)
By the way, when I read a statement like this one:
If smaller software companies can patch all of their bugs serious or minor, why can't Microsoft just patch all of their vulnerabilities with their massive army of programmers and massive budget?
I start thinking there ought to be some kind of credibility (karma) system for anyone giving public opinions. You know, give the article '-1', give the guy 'Terrible Karma'. Make all his subsequent articles dissapear for you, or even better, replace the article with a 'joke of the day', you know, to dilute the real news a bit.
There doesn't seem.... (Score:1, Interesting)
It's because they are so big. (Score:5, Interesting)
The biggest problem that M$ has is their size. Sure they have tons of cash and an army of coders, but I bet the left hand doesn't know what the right is doing. There must be so much red tape there as to basically paralyze them. Just look at the lack of innovation coming out of M$. Windows has been stagnant since Windows 98 and Office hasn't improved much since Office 97. M$ is being crushed under their own weight.
gasmonso http://religiousfreaks.com/ [religiousfreaks.com]Army of Programmers != Agility (Score:5, Interesting)
A smaller, and thus possibly more agile group of programmers may actually be able to patch more holes than a mammoth like MSFT. Size can be a disadvantage (don't quote me on this
Re:Seems like some people don't understand coding (Score:5, Interesting)
Do you really think if Microsoft COULD do it, they wouldn't.
Whereas I agree with you that it isn't as easy as some people think, if any company in the world has the resources to do it, its Microsoft. I see NO reason why a company with this many people and this much money can't get good patches out the door soon after vulnerabilities are found. The only exlplanation is poor organization and bureaucracy.
software != bowling ~ Nothings perfect. (Score:2, Interesting)
This is impossible. With patches, new releases, and updates there will always be new bugs introduced, some exploitable, some not. No program will ever be invulnerable to malicious attacks. As long as a person made it another person can break it. Maybe micro$oft could be doing better at realeasing patches, but it will never be error free. And that goes for all software.
It's just not that simple... (Score:5, Interesting)
Yes, it happens anyway.
Thie is the downside to having a huge, inter-dependent set of apps. Regression testing and dependency testing regimens have to be followed to ensure that small or even massive destabiliations don't happen. This also means that the easy stuff and the most urgent stuff (by their reckoning, not necessarily mine or yours) gets done first, and the tough stuff is just tough.
It's also what makes the closed source model more difficult to deal with, as Microsoft isn't just one pool of programmers, rather thousands of coders working on largely interdependent projects. While it looks like they should be able to do this, it's a reality that it cannot. And it would be irresponsible for them to do so, given so many users, and so many inter-related apps. We just wish it could. That's why OSS methodologies have a bit of an edge in this context (and others).
Re:It's because they are so big. (Score:5, Interesting)
The biggest problem that M$ has is their size. Sure they have tons of cash and an army of coders, but I bet the left hand doesn't know what the right is doing. There must be so much red tape there as to basically paralyze them. Just look at the lack of innovation coming out of M$. Windows has been stagnant since Windows 98 and Office hasn't improved much since Office 97. M$ is being crushed under their own weight.
As much as I agree with you about Office and Microsoft in general I think you'd be hard pressed to find someone that can say with a straight face that Windows 98 remotely compares to the 2000/XP line. Anybody remember 95/98? I remember that I could never keep it running more then a day or two. I remember that having to kill mIRC would often take Windows down with it (WTF???). I remember running out of "system resources" long before I ran out of RAM (what good is RAM if there are artificial limits on "resources"?).
If you want to blame Microsoft then blame them for XP not adding anything to Windows 2000 other then eye candy and phone-the-mothership code. Blame them for rolling out ME for no other reason then to exploit more revenue out of the 95/98 kernel. But don't say something stupid like Windows has been stagnant since 98.
Re:Seems like some people don't understand coding (Score:1, Interesting)
It's all about "cute" data structures (Score:4, Interesting)
Where the whole thing is allocated dynamically, based on what someone else told you the size was.
Dangerous Assumption in Article (Score:2, Interesting)
Another thing the author is missing is that these competitors stay in business by creating the impression that all vulnerabilities are fixed. Microsoft is vastly more publicly responsible than the smaller competitors mentioned. In the interest of continued business, they are pretty much required to adopt a policy of full disclosure. Smaller companies are not required to do this as much because they are the underdog, and everyone loves an underdog.
If it was discovered Microsoft knew about some bugs and didn't publicly release the information, there would be massive outcry. If Mozilla did the same, they might get a slap on the wrist, but I doubt it would seriously affect their business. As I mentioned above, they are the underdog and everyone loves an underdog.
Re:It's because they are so big. (Score:2, Interesting)
I'll stick by my original statement, but will add one point. With all the resources available at M$, Windows has been rather stagnant since 98. Look at what Macintosh has done over the same period of time. XP may be more stable than 98, but that's to be expected. Innovation has been not existent.
gasmonso http://religiousfreaks.com/ [religiousfreaks.com]Re:Good ole' 2002 (Score:3, Interesting)
Re:Seems like some people don't understand coding (Score:5, Interesting)
I agree with you that it's pissheaded of any software company to ignore fixing their security holes, I would suggest that that their "reason" would have something to do with the fact that a new version of Windows and IE are on their way, that don't have the same holes, and the cost/effort to fix those existing problems would be too costly to the newer versions (going from the IE Blog, alot of the IE 6 team has something to do with IE 7, and the WinXP team is involved in WinVista).
That being said, perhaps the problem here is that it costs less for Microsoft to ignore security holes than fix them. That would mean the solution is to forget adding to the "Microsoft so bad" arguments and start pressuring lawmakers to punish companies that are negligent and exposing consumers to harm.
Once the cost of inaction is greater than the cost of action, we'll start seeing a difference.
Re:Seems like some people don't understand coding (Score:2, Interesting)
It seems you don't understand coding. It's certainly possible to patch everything. It's possible to prove the mathematical correctness of code (you just can't write a program to do it). Such is very difficult, however, and takes a ton of time. This is similar to the fact that there are quick alogrithms to produce numbers which might be prime, but it's a lot slower to actually prove a number *is* prime.
Do you really think if Microsoft COULD do it, they wouldn't.
No. Microsoft's core interest is selling products, not making perfect code. Nothing about Microsoft's steps towards providing better security has focused on mathematical correctness. Instead, it's been more about doing more extensive testing and using tools that reduce the probability of including certain types of bugs. It would likely cost Microsoft more money than it has to prove the mathematical correctness of Windows. And in the end, it would have only marginal effects on sales; there simply aren't enough people who could buy their software to compensate for the task.
So, I don't hold Microsoft in contempt for not proving they've fixed all bugs. But I also wouldn't deny that it's possible for them to do such.
As a small note, this is almost certainly the reason those in the field are called Computer Scientists, not Computer Mathematicians. You can have much broader progress making code (hypothesis), testing it (experimentation), and declaring it as okay (conclusion), but you're going to have holes in your understanding (we still don't fully understand gravity). Of course, some people (CPU manufacturers) would actually prefer Computer Mathematicians, given they're working wholly with computation and there's no simple way to patch millions of CPUs already deployed.
Re:Seems like some people don't understand coding (Score:3, Interesting)
Re:Seems like some people don't understand coding (Score:3, Interesting)
This is actually only true about 50% of the time, but it is a very good thing to pretend is true when fixing security bugs.
MS discovered a bug that sent execution off to a magical realm of fairies and candy, and decided 'Well, that's okay, we'll fix it someday.', which was just completely idiotic. They didn't even bother to notice that the magical realm was user-supplied text, thus begging to be replaced with actual machine instructions.
Re:Good ole' 2002 (Score:3, Interesting)
Excuse me, how much CASH do they have in hand? Some tens of BILLIONS, I believe?
(When they aren't handing it out to stockholders in one-time stock prop schemes...)
This is exactly my constant point - they HAVE THE MONEY to hire the PEOPLE to FIX their problems! AND THEY DON'T!
Period. End of story. Nuttin' more needs to be said (but will be, anyway.)
Re:Seems like some people don't understand coding (Score:3, Interesting)
If it doesn't put money in Bill's pocket, it isn't done at Microsoft.
Look at their new "security" software. It is going to be CHARGED for. They created the crap that produced the need, and now they're going to charge for fixing it.
Assholes.
Re:It's all about "cute" data structures (Score:3, Interesting)
There are plenty of buffer overflows in the heap that lead to exploits:
A quick Google search for "heap overflow vulnerability" returns 475,000 hits [google.com].
Breaking news: there are plenty of really, really stupid coders! You might want to revise your advice. Buffer overflows in the heap are definitely possible and many times exploitable.
Re:Mod parent up! (Score:3, Interesting)
Code run at Ring 0 has no restrictions on what it can do, period. There's nothing virtual about it.
I know I'm splitting hairs, but saying that is has "virtually" no restrictions kinda implies that there is some restrictions, when in reality there is.none
Ring 0 is the seat of ultimate, absolute, completely unchecked power in a computer system ! The POWER ! MuahaHAHAHAHAHAAA !!!
Re:Mod parent up! (Score:0, Interesting)
So really, you have no idea what you're talking about.
I've worked for MS in Sustained Engineering (Score:4, Interesting)
The major issue is: How many customers is it affecting? Nevermind that it's a huge security flaw with the potential to be exploited. Has it been exploited yet? If so, by whom and who was affected? If nobody has been affected, why not? These things go into determining the prioritization for a fix.
Another slew of issues is: How many man-hours will it take to fix the bug? Can the functionality which causes the bug simply be removed without terribly ill effect? Does the person who originally wrote the code still work at Microsoft? Given the fondness for contingent staffing (aka CSG, contract workers) at Microsoft, a good number of people come and go on pretty much a 6 to 12 month basis. I know that some divisions tend to not let contract workers do development expressly for this reason, but there are always exceptions. (ie, a full-time employee (FTE) leaves the company and the company has a CSG with the skills to replace him in the interim while they hire a new FTE) Also, how many man-hours will it take to test the bug? If it will take 5,000 hours to test a bug that presently affects nobody, it ends up near the bottom of the priority list. If it will take 2,000 hours and they have a report or two from customers who have experienced the bug themselves, fixing it becomes a higher priority.
You also have to keep in mind that Windows isn't just one program. Windows XP, for example, is XP Home, XP Pro, the new XP N (sans media player), and Windows Media Center Edition I believe is also XP-based. So that's four platforms that need a fix developed and tested. That doesn't seem like much, right? Ok, Microsoft localizes their software in 44 different languages, which will all need to be fixed and tested. Four platforms, 44 languages, that's 176 different variations which need to be fixed and tested. They will generally not release a fix for only one language at a time.
The open-source community is filled with people with a lot of free time on their hands, as is evidenced by the fact that they are willing to do development work for free, and some of them do quite a lot of that development work. If a team of developers and a team of testers were to volunteer at Microsoft, giving their time over at no charge what-so-ever, I imagine you might see more of these bugs that don't actually affect anyone get fixed sooner. But as long as the company needs to make a risk-vs-cost analysis, bugs that don't affect anyone (yet) will not get fixed any time soon.
Re:Mod parent up! (Score:1, Interesting)
IE exploits can change SYSTEM binaries and libraries. If it was a "User Space" application, instead of something else, it wouldn't be able to do that.
I have had users, that I specifically setup as unprivileged, find their way onto the Internet with IE and completely hose the system. Tell me how an unprivileged user, running a web browser, should be capable of diong that?
If IE wasn't integrated into the OS in some way beyond being a simple "User Space" application, then it wouldn't have been possible for them to do what they did. Also, if it wasn't integrated into the OS, I should be able to right-click and delete the IE directory without detrimental effect, beyond simply needing to address what the default web browser on the system is.
Since you are so sure it isn't integrated into the OS, why don't you open up your program files directory and simply delete IE off the PC and then go about your business. Please, post your results.
Re:Seems like some people don't understand coding (Score:3, Interesting)
While that may be true now, what was the IE6 team up to for almost four years while IE 6 was left out to dry like a bastard stepchild and Microsoft had no intention of ever writing IE 7? If your hypothesis were true, IE 6 vulnerabilites should have been fixed much faster before work was begun on IE 7 then they are now. Survey says: Not So!
Coding isn't the problem. (Score:3, Interesting)
Instead, you take the software and reverse-engineer a mathematical description of it. Once you have a mathematical model, you can use theorum provers to determine what parts of the code are mathematically illogical/incorrect/incomplete. Once you know what parts of the code simply don't make sense, you can restrict your debugging solely to those parts of the code. You don't need to investigate the code that works. Assuming there is any.
Of course, for "trivial" classes of bugs (buffer overflows, buffer underruns, null pointer access, etc), there are code validators which will specifically look for those flaws. splint (a lint derivative) is one, the Stanford Code Validator is another. As these form the bulk of easily exploited bugs, it would seem obvious to scan the code with these first. To make certain you've caught everything, there are also validating mallocs, such as Electric Fence, which detect obviously bogus memory accesses.
I don't know how long it would take to do a reasonable scan of the Windows source code, using such tools, but I would not think it likely to take more than a few months to do the most rigorous of these checks (convert to formal notation, then use a maths theorum prover) to locate all suspect areas, and maybe a few more months to actually correct all of these bugs. You'd probably want to use a memory profiller and/or a validating malloc first, though, to cure the really obviously bogus code.
After all that, you would then want to do regression testing to ensure you'd not broken anything in the process (or unbroken something that actually needs to be broken). This would not correct "all" of the bugs in the code, but it would reduce the number by a couple of orders of magnitude and in a timeframe that would be very reasonable.
the problem is that you can't find all the bugs (Score:3, Interesting)
you can't unscramble that much spaghetti code and conflicting system calls to find the hooks to fix. by contrast, any wild-eyed wobbly who wants to break in and (pick one: wreak havoc, steal credit card info, make zombies, hack spy satellites) only has to find one hole in the snakepit to let his own snakes in.
so that's why they don't patch everything in windows. it's like counting to infinity.. just when you're almost there, somebody slams the door, and you lose count.
Travoltus had a SIG over here a few years ago that I copied down because I liked it so much... quoting...
63,000 bugs in the code
63,000 bugs
ya get 1 whacked with a service pack
now there's 63,005 bugs in the code.
that's where MS is at. Promoting Secure Computing, indeed. hard act to get on the road, that.