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"

Comments

unpatchable

[Anonymous Coward]

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.

As if the patch woes are not enough...,

[bogaboga]

...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.

Re:Why didn't tehy fix it right in the first place

[Xugumad]

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...

Re:Patch

[canuck57]

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

Re:Is this really that bad?

[jZnat]

Your mentioning of Firefox made me think of how boring it is for a Mozilla dev to go back and even look at the 1.0 Aviary branch let alone patch it for some random "security vulnerability" that was fixed ages ago on the pre-1.5 branch. Microsoft is usually working on their new products, and going back to continue working on severely outdated branches to fix a few problems can sometimes feel like a waste of time the closer you get to launching the next big version. I guess the big difference here is that Microsoft isn't going to be offering free upgrades to Vista for current 2000/XP users, so they have a much larger need to go back and continue fixing up old branches in order to continue support for the old versions.

*sigh* The annoying pitfalls of developing a massive project and randomly having to go back and fix small or large things in 10+ month old code.

Re:Monolithic design of CSRSS is to blame here...

[Foolhardy]

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.

I think that CSR was intended to be a generic subsystem server at one point. CSR actually loads libraries that contain the work code: from HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems, Windows value

%SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows SharedSection=1024,3072,512 Windows=On SubSystemType=Windows ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2 ProfileControl=Off MaxRequestThreads=16

This is the command line used to start csrss. Note the ServerDll= lines: csr loads basesrv, winsrv and calls entry point UserServerDllInitialization and ConServerDllInitialization. Csrss.exe is only some 6KB: the real work is done in these libraries. Back when Win32 was all in user mode (NT 3.51) winsrv.dll was 1.3MB: it's where all the GDI and USER back end code lived. There was also a call to GdiServerDllInitialization in winsrv. In NT4 winsrv.dll shrunk down to 166KB, since most of the code was moved into win32k.sys. Anyways, it looks like the console is implemented in winsrv but using the ConServer init function; it might be (or have been) possible to have CSR start another unpriviliged process that just does the console work. I bet MS could do it if they really wanted to.

Re:Symptoms vs Causes

[sld126]

I think you can make Steve Ballmer say it himself: http://www.axisofstevil.com/djballmerfresh.swf