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.
Re:Good ole' 2002 (Score:2, Insightful)
Re:Good ole' 2002 (Score:2, Funny)
Strawman argument... (Score:5, Insightful)
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.
Re:Strawman argument... (Score:5, Insightful)
Some more points about your criticism: strawman arguments [princeton.edu] aren't what you accuse the original post of being. They are weak or sham arguments created by an opponent to easily refute, not arguments made by the original party. And your Opera example is predicated on exactly the strawman I pointed out in the reponse to the original post: you read "if smaller software companies" as "if all smaller software companies", and then argues that one smaller company doesn't patch all of their bugs. When in fact the implicit qualifier in "if smaller software companies" is "if some (or any) smaller software companies". So their predicate is valid if even a single smaller software company patches all its bugs. And, as I mentioned, the bugs that matter in this argument are those that are reported, known, and security. If you insist on "all bugs" being literally all-inclusive, you're arguing for that release to be the final one, without even new features - sometimes known to some users as fixing bugs of omitted features.
So, as usually seen in posts by people who call factual, logical criticism "bashing" (of MS or any other party), you at last accuse the fair criticism of being "sophistry" and "sport". True to form, you project the serious flaws in your own strawman and absurdly reductionist argument onto your targets. It might be sport for you, but it's unsporting conduct.
Re:Good ole' 2002 (Score:3, Interesting)
Re:Good ole' 2002 (Score:5, Informative)
$
Re:Good ole' 2002 (Score:3, Informative)
Write = 2
Execute = 1
0444 = Read by everyone
0111 = Execute by everyone
Re:Good ole' 2002 (Score:5, Informative)
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!
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.)
They don't have that much money (Score:3, Insightful)
Go back and read Fred Brooks' Mythical Man Month. Microsoft doesn't have the money to hire enough coders to fix all their bugs. Their code is just too complex for that to work. Each coder coming in to change something affects all (most) of the others. Hiring more coders just makes it more difficult to fix bugs.
Where I work there are 5 programmers on a project that was written from scratch within the last year or two, and we were all on the project from the beginning. Even still we still have proble
Seems like some people don't understand coding (Score:5, Insightful)
Do you really think if Microsoft COULD do it, they wouldn't.
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.
Comment removed (Score:5, Insightful)
"Quality" (Score:5, Insightful)
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.
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: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 step
Re:Seems like some people don't understand coding (Score:3, Interesting)
Re:Seems like some people don't understand coding (Score:5, Insightful)
Do you really think if Microsoft COULD do it, they wouldn't.
Just because they CAN do something doesn't mean that they WILL. Anybody care to remember what it was way back in the day with Microsoft software? Anybody remember how they ignored holes that were exploited far worse then this one until the public outrage overwhelmed their PR spin?
They don't look on security as anything other then a marketing ploy.
Re:Seems like some people don't understand coding (Score:5, Informative)
Many components of Windows and MS Software on Windows utilized Remote Procedure Calls, even if the applications are on the same exact system. This is inherently flawed, as shown in many past MS Windows exploits. Just look at the MS-SQL expoits as perfect examples.
If designed with security, instead of "ease of coding" was the design from the start, RPC wouldn't be used for communication between processes on the exact same piece of hardware. This is how it is done with MySQL and Apache on Linux and why RPC exploits won't work if those services are running on the exact same hardware.
The list of flawed design decisions that went into Windows at the very beginning continue to haunt the Windows Operating System to this day. No, I am not some blind unqualified moron making these statements, I manage Windows desktops for a living, used to work full time with Windows Servers and one of my hobbies has been looking into OS architecture design and how it relates to system security.
Mod parent up! (Score:5, Insightful)
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
Re:Mod parent up! (Score:5, Informative)
By tying ActiveX so tightly into the OS, they not only succeeded in making ActiveX an almost required component of any Windows Installation, they also knee-capped themselves in regards to handling security. Unless it is seperated from OS, ActiveX will always be a threat to the security of a Windows PC.
Re:Mod parent up! (Score:3, Insightful)
It's not just ActiveX. One of the examples linked to in the article involves a corrupted font file being able to bring the OS down.
At least a part of the problem is Microsoft deliberatly writing "sphagetti code" in order to make applications be a part of the OS.
Unless it is seperated from OS, ActiveX
Re:Mod parent up! (Score:5, Informative)
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 PO
Re:Mod parent up! (Score:3, Informative)
An OS running privileged code is not a problem. The problem comes when that privileged code can execute arbitary code with the same privileges without any form of control or even indication that this is happening. A well engineered OS will be written to minimise the amount of code running with privs because of the amount of damage even a bug, let alone malwar
Re:Seems like some people don't understand coding (Score:5, Funny)
1. Base it on tried and tested code. Maybe supply the source code for the world's programming talent to see if there is anything wrong with it. Also encourage help with new projects.
2. Give it a snappy name - words ending in an "x" always sound cool.
3. Oh - and it would need a logo - maybe from the animal kingdom?
4.
5. Profit! (Oh - wait...)
Re:Seems like some people don't understand coding (Score:3, Insightful)
Re:Seems like some people don't understand coding (Score:2)
May I suggest they refactor IE a bit? Maybe starting by switching to a more modern and secure engine like Gecko or KHTML? IE doesn't earn them anything directly and the
Re:Seems like some people don't understand coding (Score:5, Funny)
that OP question is a dumb as "why can't the US kill all the terrorists? with their large army and all their technology?". We'll put in the same bin as "why can't you marry britney spears" and "why can't you quit your job and become a scuba diver"
Re:Seems like some people don't understand coding (Score:3, Insightful)
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.
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/
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
Well ... (Score:3, Funny)
patch the leaky boat (Score:5, Insightful)
Re:patch the leaky boat (Score:5, Insightful)
Not to mention that a new hull design, or switching from sail to diesel, might require that you retrain all your sailors too!
Michael, Row the OS Ashore (Score:5, Funny)
Though I must admit, it gives new meaning to "software piracy". Ahrrrrrrrr.
Re:Michael, Row the OS Ashore (Score:3, Funny)
Stewart: "[Bill] Clinton also became speaker number 683 to mention Kerry's naval service:"
Clinton: "Since we're all in the same boat, we should choose a captain of our ship who is a brave, good man, who knows how to steer a vessel through troubled waters, to the calm seas and clear skies of our more perfect union."
Stewart: "Saying 'ahoy' to prosperity. Ending our economic scurvy... with the oranges of fiscal responsibility. Kerry's the right man
It can't be done ... (Score:5, Insightful)
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 [openbsd.org] does it!
Re:It can't be done ... (Score:2, Insightful)
You can go on to claim 'well then just install secured packages as well', but it turns out third party apps never run as well as integrated apps. And microsoft is aiming at the people who want a working system out of the box, not a system that's basically a clean slate that you need to draw up yourself.
Re:It can't be done ... (Score:5, Insightful)
Microsoft (and other vendors) make a cost-benefit analysis.
And that's where we get screwed.
Because they don't have to (Score:5, Insightful)
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.
Re:Because they don't have to (Score:5, Insightful)
This is something that winds me up terribly about Microsoft, or rather, the people who use Microsoft software. For example, a friend has had absolutely terrible problems with his Windows XP laptop, tearing his hair out stuff with viruses and worms and other issues. He was going to buy a laptop for his wife and asked me for my advice. I said, buy an Apple laptop and you won't have all these problems. So what did he get? Another windows machine. Why? WHY??? Because everyone uses Windows, and he was afraid of something different. And this isn't the only example.
I got my old mum and dad a Mac Mini - they love it, and their friends coo over the slide show software and ask me how to buy one. I explain it's an Apple computer, it's cheap and compatible and will have all the software they need already installed. Then I find out later they've brought a Windows machine, because their son uses one and they were afraid that if they got an Apple they wouldn't be able to email him.
Microsoft survives because of the fear most people have of something different. Drives me nuts. My only recompense is saying to these people "You asked my advice and I said buy a Mac then you wouldn't have these issues. So sorry I can't help you. " when they phone me to solve their stupid problems...
Rant over.
Re:Because they don't have to (Score:3, Insightful)
not a priority (Score:5, Insightful)
Doesn't he know? (Score:5, Funny)
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.
Re:Doesn't he know? (Score:2, Informative)
Do you have any sources to back up that statement? It sounds highly dubious as there was just a trojan that exploited an unpatch vulnerability reported earlier today [slashdot.org] on Slashdot. I find it very hard to believe that there have been no worms or viruses, *ever* to exploit an unfixed vulnerability.
Re:Doesn't he know? (Score:2)
J.
I ask the same question (Score:5, Insightful)
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
Re:I ask the same question (Score:2)
Re:I ask the same question (Score:5, Funny)
But their bugs are free.
You're Missing Something... (Score:5, Informative)
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) [mozilla.org]. (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.
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]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: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:It's because they are so big. (Score:2)
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.
It's not just more stable. It's a better kernel model (you had to reboot just to change an IP in 98), it's more powerful (ever seen my taskbar at work? I often get up to 15 apps going -- fat chance on 98), etc, etc, etc.
I really dislike Microsoft as much as the next guy but I think you are being too har
Microsoft and Everything don't mix (Score:5, Insightful)
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)
Eureka! (Score:2, Funny)
Obligatory tinfoil hat (Score:5, Funny)
"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.
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
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 just not that simple... (Score:3, Insightful)
Not much of an edge when you consider that there are at least two bugs in Firefox which haven't been fixed for 5 and 6 years respectivily.
Granted, they aren't as critical as the ones that come out of Microsoft, but I consider a couple of years to fix something more than a reasonable amount of time.
Too many unexpected consequences (Score:2)
-The patches worked
-They didn't adversely affect other functions
-The patches come out on the 2nd Tuesday of the month
A massive army of programmers will do no good (Score:3, Insightful)
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.
The reasoning... (Score:2)
2. Perception of fear: how can they get you to upgrade to Longhorn if there are no security issues with Windows XP? How can their spyware and other partners suceed if they close all of the holes? How can all those consultants fill their days if they're not applying patches to every workstation? They're doing you
Re:The reasoning... (Score:2, Insightful)
I'd take a gander and say because you just don't know what people are going to throw at it until you let them have it.
It's more cost effective to release a piece of software and apply patches periodically than to attempt to work out all the bugs (which is almost impossible) before you release it.
The reason is quite simple (Score:2)
Can't patch CDs (Score:2)
Also, if you "fix" something, it's not like it doesn't impact other things. Microsoft's Rollup 1 for SP4 Windows 2000 a few months ago broke the ability to save to floppy disks in Microsoft Office products. They fixed
Because it's such a huge company (Score:2)
Maybe it's time for MS to break off into 3 sections? Just like where I work (huge municipal organization)...our project WILL save our city millions of dollars but what's happening right now? It's at a stand still because it's budget time. *sigh
have I misread something (Score:2, Insightful)
Ok have I missread something?
Small companies = 1 or 2 programs with each a couple of thousands lines of codes. Usually new program, so fresh and structured code.
Microsoft = dozens of programs, with each a couple of millions lines of codes. Usually based on ancient versions returning to
They Can't (Score:2)
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.
Re:It's all about "cute" data structures (Score:5, Informative)
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.
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].
Re:It's all about "cute" data structures (Score:3, Insightful)
Code is not executed from the heap (data segment), unless you explicitly point the instruction pointer there. This is actually pretty difficult to do. To do it in a standard program run, you would have to write self modifying code [wikipedia.org]. To force a program that otherwise *wouldn't* execute code from the heap, you would first need to corrupt the stack and adjust the return pointer to the pointer at your instruction buffer. But if you can't corrupt the stack, you're still
Re:It's all about "cute" data structures (Score:5, Insightful)
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.
Welcome to Corporate America (Score:2, Informative)
The reality of Corporate America, however, is based on quarterly results. Getting that next release out the door and being able to sell is everything. That means that all clean-up work (bugs, exploits, refactoring) will be prioritized along with new features and unless it's really critical will lik
Re:Welcome to Corporate America (Score:2)
In a company run by Software Engineers, bugs would be fixed before new features are added and we'd see life cycles similar to open source projects that produce typically stable and largely bug free 1.0 releases.
Yes because as developer I love bugfixing and regression testing way more than implementing cool new features.
Care to explain why OSS projects frequently have long lists of unpatched bugs if your point was even remotely close to accurate?
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 c
Spoken like a true non-developer (Score:2)
Why can't they just churn out patches? Testing. You have to be sure the patch doesn't break something else. That's just as important as fixing the holes in the software. So many things are interdependent in Windows it's impossible to know what effects changes will have.
Do you really think MS is sitting on code or ignoring security problems? If you do, you're naive. MS is a business - it doesn't pay to ignore these things.
Answer (Score:4, Insightful)
Oh, he didn't really want an answer?
It's not practical to "patch everything"! (Score:5, Insightful)
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.
Only two dozen??? (Score:2)
Really? Only two dozen? If the author is foolish enough to think that Windows only has two dozen bugs, it's no wonder he's foolish enough to think it should be easy to fix them.
This post is not a slam against MS, but the article...
zero-day (Score:2, Funny)
Maybe it should be named zero-year exploit.
How many users are really effected by IE holes? (Score:2)
I would bet its such a small percentage that it is laughable. Remember, the security companies get money and PR by exposing as many holes in software as they can find. In all the lifespan of using windows and its various versions and IE I have NEVER encountered any site with any of the security problems that the "experts" jump up and down about.
Yes they should be fixed, but they should also not be treating this stuff
Big OS +Lots of employees + Techsupport = $$$$ (Score:3, Insightful)
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?
Maybe still denying the root problem (Score:5, Insightful)
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.
Re:Maybe still denying the root problem (Score:3, Funny)
ActiveX is one HELL of a typo.
and lose the weekly free advertising? (Score:3, Funny)
also, the constant need for patches allow them to feel they are still relevent.
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.
Dependecy hell (Score:3, Informative)
MS likes to pretend that windows is immune to such things, but the truth is every piece of software is interconnected. MS creates the illusion of no dependency problems by solving as much of it as possible behind closed doors, and wrapping the results in binary installers. The sheer amount of effort to resolve the problem is high
4 words (Score:4, Insightful)
smash.
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.
There are an infinite number of bugs (Score:3, Insightful)
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
Re:Because they're too busy.... (Score:2)
Re:What the? (Score:2)
Well, they COULD. But at what cost? With the threat of Open Source competition ever-looming, Microsoft simply can't afford to let their feature lists stagnate for the next five years while every available developer is tasked with bug fixing and unit testing against the existing codebase.
Re:What the? (Score:5, Insightful)
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?
Re:Unsafe at Any MHz (Score:3, Insightful)