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]
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
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.
Well, is that wrong? Isn't that exactly what they did in this case?
# cat
Damn, my RAM is full of llamas.
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
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?
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