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."
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.
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.
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.
Insightful? Clearly moderated by people who don't code for a living.
// No one will ever give us input longer than this! // Possible overflow
// Improved : sprintf(buffer, "%s", fullAddress); // More Improved : snprintf(buffer, 25, "%s", fullAddress);
Okay, first off, your code (as mentioned by the other poster) isn't legal C or C++. But let's fix it and discuss it how I'm sure you *meant*.
So here's the correct code:
struct foo {
int length;
char* buffer;
};
Now then, you argue that this is problematic because it's allocated dynamically, based on what someone else told me the size was.
Actually, this struct doesn't appear in the Win32 or the MFC API anywhere (nor does anything that looks significantly like it), but more importantly, this kind of struct will *never* be a problem. Let's consider all of the cases:
1) length is too large to allocate a buffer for. The code throws a bad_alloc exception when buffer = new char[length] is called.
2) length is negative. new takes unsigned integers for allocation, so the value is actually very large and positive. The bad_alloc will be thrown in this case too.
3) length is zero. I get a pointer to memory that is 0 bytes long.
4) length is valid. We allocate a proper amount of space and away we go.
Let's assume for a second though that someone gives me the buffer pointer *and* the length.
1) length is the correct size (no issue).
2) length is too small for the buffer (no issue, but I am wasting memory).
1) length is larger than buffer actually is long. I write out of bounds, but in the heap. This will likely result in a crash, but NOT in an exploit. This struct could be anywhere in memory, but it will not overwrite the stack, which would be necessary to execute arbitrary code.
Buffer overflows are only a problem when the buffer exists on the stack. In the heap, buffer overflows will result in a crash, or possibly undefined behavior. But on the modern PC, it would be impossible to use a buffer overflow in the heap to reliably execute arbitrary code.. Unless the coder in question was doing something really, really stupid (like executing code from an arbitrary instruction buffer in their structure, which you conveniently just overwrote). Fortunately for us, MS does not do anything of that nature.
For reference, buffer overflows occur when someone does something like this:
void GetAddress(char *& streetName, char* fullAddress)
{
char buffer[25];
sprintf(buffer, fullAddress);
streetName = new char[strlen(buffer) + 1];
strcpy(streetName, buffer);
0;
0;
}
But the best would've been to do it like this:
void GetAddress(char *& streetName, char* fullAddress)
{
int requiredBufferSize = snprintf(0, 0, "%s", fullAddress) + 1;
streetName = new char[requiredBufferSize];
snprintf(streetName, requiredBufferSize, "%s", fullAddress);
}
Or to not use C style reading at all.
I currently have no clever signature witicism to add here.
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.
Actually, this struct doesn't appear in the Win32 or the MFC API anywhere (nor does anything that looks significantly like it)...
I beg to differ. MFC may not contain this sort of thing, but Win32 and the system API behind it absolutely, positively include lots of structs like that. Check out the serial port DCB struct, or many of the associated serial-communications related structs, for example. Check out almost any TAPI-related struct. Many other subsystems are the same, I'm sure.
Usually, the length is actually used as a version code, not a buffer limit. OS code and user code can both check the length to see which version of the struct they're dealing with. As long as it's really used that way, it's not a problem.
this kind of struct will *never* be a problem. Let's consider all of the cases:
Allocating the struct isn't the main problem. The structs Win32 hands back can be downright baroque in their complexity, including variable length data objects and pointers to those objects. An application program written with the assumption that those data objects will not exceed some documented maximum length could easily wind up with a buffer overflow on the stack when interpreting, parsing, or otherwise manipulating a maliciously constructed struct.
Let's assume for a second though that someone gives me the buffer pointer...
Aren't you hosed right there? If the pointer points to your own stack, and you write through it, then bye-bye process. If what you write is some data chunk also provided by the same malicious someone, then you could very well be dumping exploit code right into your own stack.