Slashdot Mirror
Why Can't Microsoft Just Patch Everything?
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."
Here's one from the article flagged: "Less critical" from 2002: SA7127 Check out the first paragraph of this 'less critical' item's description.
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.
Seems like some members of the press don't understand coding. You can't just go and patch everything. Regression testing? Making sure all the changes work as needed without impacting other subsystems.
Do you really think if Microsoft COULD do it, they wouldn't.
You can only patch a leaking boat so much, even if you drydock the vessel for a few months. When it's only held together by the barnacles and the masthead, it's going to sink whether you bail it out or not. At some point, you're going to have to re-think the design of that hull, and start from scratch.
[
I think MS has come a long way from where they were, but I agree. To the people who claim it can't be done: OpenBSD does it!
Why should they?
People will still buy thier product, people accept that it sucks.
Unless they see a good ROI on patching or developing good code they won't.
Quite honestly if it isn't a worthwhile use of their resources they shouldn't patch code.
When there is serious competition and code quality becomes a competative advantage they'll fix it.
Microsoft is growing and profitable having their developers do other things, until such time as they are held hugely financially liable for their bloated buggy crap they won't make that their prime focus
Issuing patches is dangerous.
Every time Microsoft patches its software, hackers use their patches to discover security holes and to issue exploits!
But when they don't patch their software, no bad guys notice these vulnerabilities. In fact, no virus or worm has *ever* exploited a vulnerability before a critical update was released!
Duh.
We recently had heard in the office over one of the Yellow Machine that's made by Anthology Solutions.
Why can't the Mozilla Software Foundation allt the 6300
Firefox Bugs? instead, they have to release a "new" version... just freeze the freaking lreleases and patch your bugs!
No, OSS is not free of bugs
Ubuntu is an African word meaning 'I can't configure Debian'
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/If Microsoft fixed everything, then the companies that made programs that allowed users to work around the "flaws" in Windows would go to the federal prosecutors and demand that Microsoft be sued for having a monopoly on fixing their own bugs.
All kidding aside, Microsoft has a huge amount of users, maybe more than any other product in existance (I didn't do the research). This does mean that more bugs will be found, and the reason behind not fixing certain bugs may be that the bug was addressed in a future rollup or patch already. Because Microsoft is a massive corporation with so many departments, it is possible that Microsoft BugCentral says "Fix this!" and Microsoft PatchCentral says "We fixed it in Article 931321 coming next week" and Microsoft ReleaseCentral says "We're waiting for a fix on another bug before releasing that."
I'm not a fan of it, but it is really hard to just come out and say they're ignoring a bug, when it may be something deep set within the software (hard to remove) or it might be addressed but on hold for another reason (opened up another flaw?). If we think we as geeks found all the vulnerabilities, we're fooling ourselves. Windows is a massive program, and even Linux has ongoing flaws. When Linux has as many third party apps and interconnecting drivers as Windows does, I'll accept a complaint towards getting things fixed post haste. Until then, we just have to (thankfully) support third parties that give us options! (And paychecks)
"What's the status of our new software?"
"Ready for launch Mr Carver, and - as requested - it's full of bugs, so people will be forced to upgrade for years."
"Delicious."
/not serious... no, seriously.
A-Bomb
Just because MSFT has an army of programmers, it doesn't mean it has an easier time patching its old code. Larger groups of people (be they developers or military groups or a bunch of friends going out drinking) almost always require more grooming and maintenance. Look up "Dunbar Number" - here - I find it fascinating.
;)).
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
Simpy
Patches, no matter what they are, are woven into most things that Microsoft and developers do. There are numerous dependencies, and the numerous divisions, API sets, and partner dependencies make this difficult if even impossible to do on an ad hoc basis, as a generally available patch that breaks things is irresponsible.
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).
---- Teach Peace. It's Cheaper Than War.
The best way to find a bug is to take the code away from the original programmer and give it to a dedicated tester.
The best way to fix a bug once it's found is to give the code back to the original programmer, and tell them to go fix. Because they know the code. And it's less likely that fixing the bug will introduce more bugs. Obviously, this limits the amount of people you can set to the task of fixing them - and in a project the size of Windows, there are a lot of them.
Where the whole thing is allocated dynamically, based on what someone else told you the size was.
No folly is more costly than the folly of intolerant idealism. - Winston Churchill
Incompetence, disinterest, different priorities, and no business reasons to do it.
Oh, he didn't really want an answer?
Assorted stuff I do sometimes: Lemuria.org
We're used to OSS products that can be patched in a day, but we're also used to seeing those patches break things in unanticipated ways, often making things worse.
We're also used to picking on Microsoft for having buggy software. But they have extensive and long testing procedures, without which MS software would be WAY buggier on release. Their software is massive (for some good reasons and some bad ones), so it's a huge undertaking to fully test it.
In order to avoid, as much as possible, unanticipated consequences of a patch, Microsoft cannot simple make the fix and release it. An argument could be made that if they were to do that, they would often create more vulnerabilities than they started with, so releasing too quickly would be a BAD thing to do. Windows 95 is an example of something that was released too quickly, lacking certain kinds of testing entirely; you can see the unfortunate results when you try to connect a Win95 box direcly to the internet and wait 5 minutes.
So, why can't Microsoft 'patch everything'? Here are the reasons:
(1) First, you have to FIND 'everything', and Windows is just massive.
(2) When you make a change, you have to test it extensively, which takes a LOT of time.
(3) Some patches are one-liners. Some affect large amounts of code that makes it even harder to anticipate consequences.
(4) Sometimes, you have to test things one at a time. This serializes your patch process in such a way that it just takes a very long time. This is very hard to avoid.
The fact of the matter is that if Microsoft were to 'patch everything', we would have a lot more to complain about. People should stop asking for stupid things and be realistic.
Even OSS projects can't 'patch everything' successfully. Sure, many of them are better designed from the start, so there are fewer things to patch, but when a patch needs to happen, the same amount of testing is going to have to happen, one way or another (either you release a beta and let it get tested for a while, or you just stick it in and wait for the shit to hit the fan and end up fixing the consequences the same amount of time later anyhow).
Also, certain people forget that Microsoft did go on a 'patch everything' hunt and DID fix a huge number of bugs. They still didn't find everything.
Oh, and if we're just talking about patching everything that's currently known, my argument still stands. Patching a bug of vulnerability is often quite difficult.
This is not the reality of software development. This is the reality of incompetent developers and management perhaps: making technical decisions based on how to lock in your customers, work around lawsuits, and shove software out the door to crush the competition.
Plenty of systems---yes, open source ones are good ones to look at---are not so bug-ridden and complex that they can't stay ahead of the curve and react quickly. If you write good software, if you're at least decent at what you do, that is the reality of software development.
But, they don't. They have reports of bugs for months, often, and do nothing until it's publically reported and/or there's an exploit in the wild. Does it take Microsoft 6 months to come up with a patch for a single buffer overrun? Or are they just too arrogant and think they're above doing anything about problems until they're exposed?
How often do we see bug reports from Microsoft about a critical vulnerabilities, compared to third-party reports?
Don't think of it as a flame---it's more like an argument that does 3d6 fire damage
There are two types of "patching".
... and opened a whole other category of exploits FOR THE OS.
1) Patches to fix code flaws in an otherwise sound security model.
2) Band-aids for a flawed security model (anti-virus updates are in this category).
Microsoft focused on "user friendly" and "easy of use" for so long to the detriment of security. And security cannot be retro-fitted to a system.
When they merged IE with the OS, just to be able to beat Netscape, they opened the OS to a whole new category of exploits.
And then ActiveX made web app programming so much easier
Attention all hands! Abandon metaphor! ABANDON METAPHOR!!!
Though I must admit, it gives new meaning to "software piracy". Ahrrrrrrrr.
That problem was fixed, um... 4 years ago?
/lib/ld-linux.so.2 ./test ./test: error while loading shared libraries: ./test: failed to map segment from shared object: Operation not permitted
$
Comment removed based on user account deletion
The initial post is a strawman argument...
...which predicate the argument on the notion that small software companies patch all their bugs.
If smaller software companies can patch all of their bugs serious or minor, ZDNet's George Ou asks
So if I go looking for bugs in say the Opera browser I wont find any, because small companies patch all their bugs?
Nobody patches all their bugs; not small companies, and not large companies. The argument is a piece of sophistry that simply sets up another round of MS bashing. A fun sport, but it shouldn't be mistaken as anything exccept sport.
Microsoft has alot of employees to feed large salaries to. The teams of developers, designers, programers, PR guys.. They're still giving support and updates to an OS that's coming on 8 years old, on top of all their new product.
Now, I can't say for certain, but I imagine that means that every time they release a new OS, their support staff grows bigger, whether in house or contracted out (I'm not sure how MS handles it).
This is ALOT of people folks.
So, you're in charge of keeping MS a growing profitable company. Does it make sence to focus your time on patch after patch after patch, which does nothing but tie up your employees with aditional support and coding while in no way contributing to the effor of actually paying them? Do you focus on pushing out the new OS, forswearing support of a decades worth of previous OS's, Office, and other programs (I'm not going to venture a guess at what they're still supporting... and how many questions they have to field about things they're not still supporting, and how many questions they get for, I dunno... any program that was ever made for PC that people have trouble making run out of the box.."
Smaller companies don't have tis problem. For most of them, all they need is a relatively short testing period to make sure itruns on Windows. Microsoft has the reverse problem : to make sure ANY legitimate programs, however poorly implimented, run out of the box whilte at the same time distinguishing between those and malicious unwanted programs. They can't cater to the smart people either. Linux has less bugs, but lets face it; even the easy to instal builds are a brain job for newbies, and impossible for most grandmothers.
So yeah, Microsoft has a full plate, and as ugly as it sounds, I doubt its economically fesable for them to fix everything. They have to prioritize. New features= new money. New patches = no money + continued expenses.
Conspiricy theories aside, does anyone really think they *like* having a reputation for buggy software?
Note the vast majority of "bugs" in bugzilla that are labeled "enh" --> those ones are enhancements that users would like to see.
Instead of counting against Mozilla, the fact that they allow so much user input is a great OSS feature.
No one said OSS was free of bugs. Since end users are allowed to submit bugs, the only ones that should be counted are those that are confirmed.
Try the following list: bugs that are in Firefox, not marked "enh", and have an action priority (P1-P5). (note: copy/paste link since bugzilla refuses connectiosn referred by /.)
Only 179 bugs. Sure, those are only the ones that the Mozilla team deem necessary to work on; however, we've seen from their reactions with 1.06 -> 1.07 that they are very quick on figuring out what's important and patching it quickly. Sure, that's a lot of unpatched bugs. But: that list is publicly available. Any researcher can go in and say, "hmmm.... let's find the security flaws that Mozilla has left unpatched". And they do, trust me; the thing is, the Firefox team patches the bugs that cause security flaws. Other ones are cosmetic, user interaction, or feature-based in nature. They still appear as "bugs", even though they don't pose a security threat.
The issue is not that OSS has no bugs - that's an obvious farce. The issue is that Microsoft first misdiagnosed a critical bug, and then left it unpatched for 6 months and counting. The Firefox team consistently finds those bugs that do pose a threat, and they leave the work they do open and transparent so that security researcheres can check up on what happens. Microsoft - let's put it thise way: if security researchers never found the flaws in Microsoft's programs, Microsoft would save money and increase efficiency by not fixing them.
There was a business mantra in the '90s, and still out there today, that defines "quality" as whatever it takes to please the customer. Consultants hauled in buckets of money generating cliches out of that. Companies may be driven by customer satisfaction, which is fine as far as it goes, but it doesn't mean their products are any good.
The flaw in the cliched definition is that often the customer doesn't know what they're getting or have any basis to judge how good the product is.
Microsoft, being driven by market share, is a step removed even from that level of quality. They only want their customers to be happier with their products than with the competition (which is often another of their products or an earlier version of the same one).
Making things properly is not in their range of capability.
sigs, as if you care.
Imagine you write a long long book. Even if you try to correct all the typos you may miss some of them. It is hard to publish a book with no typos at all.
I think that was great fun! If MS management believes that the security problems are "typos" then I understand they cant fix them all. Of course, security problems are more like problems with the story line: contradictory events, inconsistent background and such things.
Maybe they still have not accepted that the reason for their security problems is the poor design of Windows (particularly integrating things very freely). As long as they dont accept the truth they will try to correct typos, and that will not make the story any better.
As an example of the extra hurdle copying imposes, say you want to attack someone via a set of holes in Firefox. With /lib/ld-linux.so, you need only the following, if you can't make firefox itself do arbitrary things:
With out the ld-linux vector, you have to:
So it's not a huge hurdle, but it's there!
--
Given enough personal experience, all stereotypes are shallow.
I've worked for MS in the past, in their Windows Sustained Engineering (WinSE) division. So I think I can bring some valid criticism to this situation.
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.
Reinvent the wheel only at either a lower cost, greater effectiveness, or your own personal enrichment and satisfaction.
smash.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
Windows contains above 100M lines of code (recollection from some time back, probably more now).
The overall design philosophy is 'tight integration', so everything affects everything.
Any software testing problem is combinatorial: all combinations of inputs checked against all outputs. This is why testing cannot be used to produce a quality product, only to check whether the development process is capable of producing a quality product.
I guarantee you that MS's bug list for each product is in the 10s of 1000s. It is a major effort to even sort through bugs and choose the most critical, consolidate by root-cause, isolate to DLLs, AND REGRESSION-TEST THE FIX(es).
In a large system, the overhead of source code management (checkout, change, test, merge with the release with the bug, and then merge into later releases of code) is enormous. The productivity of people doing bug fixes in these large systems is very low, no matter how expert they are. This is why developers HATE fixing problems in released code.
No large company can fix all their bugs, even when bug fixes don't generate new bugs.
Lew
"The Constitution, the WHOLE Constitution, and nothing but the CONSTITUTION."