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.
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/"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
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.