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"
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.
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.
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!
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.
(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.