Slashdot Mirror
The Story of a Microsoft Patch
buckethead writes "eWeek is running a story about a security patch from Microsoft that failed to adequately address a denial-of-service flaw on CSRSS (Client/Server Runtime Server Subsystem), the user-mode part of the Win32 subsystem. It stems from a research paper from Argeniss that discusses how Microsoft only patched one path to the vulnerable function, but they forgot to do proper research to identify all the paths." From the article: "The problem was that Microsoft didn't patch the vulnerable function; they just added some validation code before the call to the vulnerable function, but what Microsoft missed was that the vulnerable function can be reached from different paths and the validation code was added on just one of them"
I'm liable for bugs in my software.
I'm not liable if my patches fail to patch the bug.
I'm not liable if my patches make more damages than the pathced bug.
If I do the same in restaurant business I get jailed!
It would be great at least a "pay after use", just like pizza: do you use to pay for pizza after or before you ate it?
Maybe Computers will never be as intelligent as Humans.
For sure they won't ever become so stupid. [VR-1988]
Cue all the "Microsoft doesn't remove the causes of bugs but only fixes symptoms" comments
Why didn't they fix the vulnerable function in the first place (is there a specific reason)? Sure, adding validation seems like a quick and valid fix, but a company the size of MS should have known in the long run, fix the function instead.
KeepTrackOfIt.com - Find the lowest gas prices in your area graphically
The article criticizes Microsoft for not fully understanding the vulnerability, and issuing an incomplete patch.
I understand that in a best case scenario, a vendor should release a 100% effective patch. However, in reality, that's not always going to be the case.
Microsoft released a patch that stopped the public vulnerable attack vector. Then, once they were alerted that they didn't fix all possible vectors, they issued a new patch (albeit quite a few months later).
With the large amount of bugs and vulnerabilities that a software behemoth like Windows is going to have, is it really that unthinkable that an incomplete first-patch would be released? I'd wager that even OSS products routinely have incomplete first-patches.
Now we get to listen hundreds of people who's programming experience consists of 5000 lines or C/Perl/Python tell everyone what the proper process is for matching vulnerable code.
Has any Windows security problem ever hurt Microsoft's stock price?
I checked MSFT a couple of times when mail-based malware was running amok, seriously enough to reach the general news media. No effect.
If that's the overall pattern when it comes to Microsoft security issues and Microsoft's business success, it goes a long way toward explaining security missteps like MS05-018. There's no direct incentive for them to master security.
org.slashdot.post.SignatureNotFoundException: ewg
Maybe because they didn't really care about the other ways to get in, but all they cared about in this case was their image to the outer world, and thereby being able to say "See, look at us, we patch our flaws immediately".
You can either:
1) Give some references, or
2) Accept the Troll moderation you are about to recieve.
Your choice..
"Oops, I always forget the purpose of competition is to divide people into winners and losers." - Hobbes
There is always going to be the same fundamental flaw in software development: humans.
Humans write the original code that produces bugs. Other humans (who may or may not fully understand the code they're working on because the original developer left the company) write patches to fix those bugs and in the process of doing so, create new ones.
Its the nature of the beast, it happens everywhere. Don't get me wrong, Microsofts overall record is pretty weak and I think they have made some serious design flaws with their OS, but to write a whole article on one bugfix smells a little like flamebait to me.
A Microsoft bashing story on Slashdot??
Here is an example, perhaps, where FOSS has an advantage. Microsoft might not be able to fix the function because it is "in the wild" and there could be many dependent "already-compiled" applications which would/could be affected. In the FOSS world where backwards binary compatibility is not an issue, a source patch could be made available. Oftentimes the way these sorts of problems are handled by Microsoft is they roll out a new updated API, leaving the old ones in place. This obviously doesn't address the installed base of buggy code, but fixes the problem going forward - assuming they can convince the developers to adopt the new API. Unfortunately, this course of action is also not applicable to a security patch scenario. So, MS issues an imperfect patch addressing, hopefully, the most flagrant problems, and queues the function as one needing to be deprecated in a future release.
The more you regulate a company, the worse its products become.
This is a valid approach, if the hole was being exploited by script kiddies or an automated worm. If your system was being DOSed, you would take the quickfix rather than waiting two weeks for the proper one.
This happens over and over and over again— with some users, I'm afraid to upgrade their software because their "world" sadly depends on the cargo cult execution of gestures to get their work done. Too many applications change how they look and feel with every upgrade that many users go off the rails whenever that happens. At least with an application, you can kind of avoid it, but when it's Windows— aw man, why not just fix the SECURITY HOLES instead of changing the UI? Please, Microsoft?
Screw it [sic; I'm being polite.], I'll keep my Mac OS X for clients and Gentoo Linux for servers and any web service that doesn't suck (Gmail, Basecamp, etc.), thank you very much.
Microsoft's days are over the moment Google decides to market an operating system that includes GFS for redundant data-storage and their MapReduce for batch processing. These things are big contributors to how its even possible for Google to exist. Simplicity trumps mediocrity.
One must also consider the possibility that the folks doing the coding and the quality assurance (SQA) may not be the original authors of the specific branch involved, and therefore did not have the proper experience level required to do the research and make the judgement calls. With the rumored turnover Microsoft has seen lately, I wonder if this is not a possibility?
More and more of the post-development activities (break/fix, SQA, implementation/packaging, etc.) for software are happening in little bubbles, somewhat removed from the core competency group that created the original code. We even see this touted as the right way to do things from sources that are considered to experts in the process + workflow arena (well, some folks consider them experts, anyway). When this becomes the standard operating procedure, any company runs the risk of bad patches to any kind of software: you can not limit the culpability to Microsoft.
when it rains, it gets real soggy. when it pours, i'm under the tap just _waiting_ for the joy
It always struck me as odd, the way the console window appears to be a part of the system instead of a separate executable, but I guess it has to do with the way DOS emulation works "seamlessly", i.e. just run the .exe and a console window appears for it. I suppose the system X11 uses, where if you need the text output of a program, you run it in a terminal emulator, is too difficult for users or something...
# cat
Damn, my RAM is full of llamas.
More likely if they fixed the function, then they would have had to produce patches for all the affected packages. Lots more time, energy and money. The pressure from sales and marketing would have been quite hard.
The missing part of this story is that, yes, it's OK to fix the function with a wrapper or a rush-release. However, they must have known that there was a long-term problem so MS should have procedures which can handle the tracking of problems like this. In the company I work for, we have just such a system, and we're just small-fry. If MS haven't got these procedures then, whoops, their bad. Their request-management must be chaotic to say the least. Anyone know how MS handle their request-to-release management? It can't be a state secret surely.
Patriotism is a virtue of the vicious
Probably goes like this:
Coder(s): this will take two weeks to fix and test properly
Management: you've got four hours.
Does a Christian soccer team even need a goalkeeper?
IANAP, but couldn't they have put the validation code in the function itself?
My new blog
Translation: "I'm going to defend Microsoft on Slashdot to get karma (it makes you look enlightened and individual to moderators), so in an article where Microsoft was clearly caught with their pants down, I'm going to instead distract the issue by mocking the coding experience of some of the commenters, as if that has anything to do with the #1 software company in the world not getting the 'software' part right. It's kind of like telling movie reviewers who've never made a movie before that they can't criticize movies."
"Sufferin' succotash."
The next time MS claims it fixes security holes faster then anyone else ...
Never underestimate the dark side of the Source
All paths?!?!
How do we know in the future that this function won't be used again in something/somewhere else? Since we all know how "wonderful" M$ is at documentation, how many here think that there'll be a note in there that specifies something extra that needs to be done before the call to that function. Talk about wasted time/money.
You patch the function that needs to be patched, period. That way the vulnerability just goes away no matter who might call that function in the future. You also won't have to worry about "all the paths" as you kill them all with one stone.
Not patching the function in question is just asking for trouble later on.
Sheez. Talk about a neural misfire by this guy.