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"
A Microsoft Microsoft patch? That's the worst kind!
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]
Stuttering in the summaries? "It stems from a research paper from Argeniss that discusses how Microsoft 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; ...... 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"
Freedom is fragile and must be protected. To sacrifice it, even as a temporary measure, is to betray it.
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
As Microsoft have "intergrated" all their api's into one core buggy OS it doesnt suprise me. Fixing the actual function would probably crash loads of others. But hey thats the microsoft way..
..
Frankly it would be better if they started over again.. Look at the situation now.. even M$ themselves have to create infect a machine to track down spammers instead of fixing the root problem. Its like an aircraft with Gaffer Tape holding it together (with a paint job to make it look cool in new version of windows vXXX).. and they couldnt blame weather
I also feel really sorry for m$ coders.. they have a lot of talent but they are probably in a situation where they dont want to mess with code too much as changing things will bring the whole system down.. and a lot of chair throwing.
As Ballmer is a coder himself maybe he should join the troops in the basement and get to the fix and a steady system. Only them will users believe that Wind is a truly great system. At the moment m$ are in denial.
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.
From TFA:
It's being called the "story of a dumb patch."
Soon to be a 200-part epic, starring John Goodman as Steve Balmer.
Coming to a Windows Vista box near you!
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.
At least they tried! And mommy says thats what counts.
The Story of a Microsoft Patch
A Tragedy in Three Acts
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".
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.
One possible reason is that changing the code to make it "safe" would have broken application compatability. I would be very surprised if this was not the reason...
This would explain why, instead of fixing the underlying problem, they chose to wrap it in validation to reduce the risk. It sounds like they did not do a complete analysis of the problem, but I think that's a method problem rather than a rundamental flaw in how they fixed it.
But when it's found "Hey, calling this function with these arguments causes a crash", why *isn't* fixing the function the first thing that comes to mind?
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
The problem, as far as I can see, is that CSRSS.exe, which implements some important parts of win32 (important enough for the kernel to die in sympathy if CSRSS dies), is also responsible for the menial tasks of drawing console windows.
If the code to draw console windows were in a separate, unprivileged process, or even better a library, this bug would not be particularly exploitable. The worst DoS possible would be to prevent anyone from making console windows until the process was restarted.
There was another console bug a few years ago, see here. Printing a few tabs and backspaces to the console would cause the machine to blue screen.
...in my case, I have found that the total disk space consumed by Windows 2000 patches is bigger than the original Windows 2000 install itself! To make matters worse, I am now very low on disk space. I console myself by the fact that disk drives are cheaper nowadays. Whether these patches actually work as advertised is an open question, but I have my doubts though. All I see are a bunch of Hot Fix entries and nothing more.
We decided to tell IBM, and they patched it. But not fully: the same hole was still open. It was not anymoe possible to access the configuration data by appending a dot, but this time is was enough to add a "%20" to the filename or something similar.
Instead of moving those configuration files out of the webroot!
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??
As a developer, there are times we'll just gloss over a security problem to get the worst of it fixed ASAP with the least risk of breaking something else in the progress (and there are also holes that I'm desperately hoping no-one finds before I have time to completely rewrite the code, and beat to death the programmer responsible for it in the first place, but that's a rant for another day).
It's possible that the first fix was just a temporary measure they knew wouldn't break anything else, while they rewrote the problem function and put it through proper testing. On the other hand, this is Microsoft, so I may be being overgenerous here...
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 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's a glitch in the Matrix. It usually means they've changed something...
That's our life, the big wheel of shit. - The Fat Man, Blue Tango Salvage
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
Is a microsoft patch anything like one of those Nicotine patches that help you stop smoking? If so I wonder if my health care will cover it. I'd like to slap one of those on asses of my co-workers and help get them off their addiction to microsoft.
I guess one might consider Linux to be sort of a methadone. Something that hels you with your cravings for the bad stuff, but ultimately leaves you without that satsifying high.
Personally I useto OSX, but I'm not addicted. I could stop anytime I want to. I just don't want to that's all. Now excuse me while I watch the Genie effect a few times before I send this.
Some drink at the fountain of knowledge. Others just gargle.
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?
But when it's found "Hey, calling this function with these arguments causes a crash", why *isn't* fixing the function the first thing that comes to mind?
Logically your right, but Microsoft is a marketing machine. They would rather you buy another ISA server so they can profit from defects. http://www.microsoft.com/isaserver/default.mspx
IANAP, but couldn't they have put the validation code in the function itself?
My new blog
For those of working on any windows app, if possible, as an experiment put your app through some memory leak detection software (like Purify etc). I'm sure you'll be as shocked as I was to see how many OS level buffer overflows are happening at any given time. There's so many of them that it makes sense, from a cost perspective, why MS simply fixes the ones that matter as they come up.
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.
(1) I think the previous AC was referring to the Samba 2.x series exploit that Digital Defense unearthed back in 2003. See http://www.digitaldefense.net/labs/advisories/DDI- 1013.txt.
Note that this is a remote root access by an anonymous user, as Samba is commonly deployed. It was indeed serious.
This vulnerability may have been the result of a vulnerability in Microsoft's SMB protocol itself, which also unpatched for about the same length of time. I can't recall at the moment, and I don't have backups of my notes from the time right at hand. It was a late night, I'm still sucking coffee, and feeling lazy.
(2) Strictly speaking, that would depend on your threat model, wouldn't it? That said, I would regard the vulnerability in CSRSS as typically being far more dangerous.
What you do with a computer does not constitute the whole of computing.
The best way is to take your time estimate (1 week), strip the units from it (1), double it (2), and finally add the unit back in, using one larger a unit (2 months).
;-)
Some more examples:
3 hours -> 3 -> 6 -> 6 days
10 weeks -> 10 -> 20 -> 20 months
"Your effort to remain what you are is what limits you."