A Nasty NT Bug

by HJH

First off, I owe a major thanks to Zappadoodle.com.  Most of what follows is just an easier to parse summary of what they've already discovered.

Despite being quite bullish on Linux, I've still considered the Windows NT line to be a worthy competitor, especially Windows 2000.  From what I'd read, and the little experience I'd had, it seemed like a solid, dependable, if somewhat bloated OS.

Then I read Zappadoodle.com.

That site described an odd little bug that allowed anybody to bring that OS to its knees.

The entire demo consists of a measly three lines of C code:

void main() { for (;;) printf("Hungup\t\b\b\b\b\b\b"); }

That loop prints a string to the console, which means it passes through some code in CSRSS.EXE.  The output routine that happens to parse it has a nasty flaw; it doesn't properly handle several backspace characters after a tab.

Specifically, it backs up one character too many, and doesn't make sure the cursor position is still within the console buffer.  By repeatedly doing this, the cursor position will eventually move outside the memory area set aside for CSRSS.EXE.

By also writing normal characters, CSRSS.EXE will attempt to write there.

It won't succeed.

The processor will refuse CSRSS.EXE attempts because it doesn't have access to that bit of memory.  NT will follow up by killing off CSRSS.EXE.  So far, this is nothing more than poor bounds checking and standard OS procedure.

Now things get interesting.

See, CSRSS.EXE is apparently a vital part of the NT operating system.  If the kernel notices CSRSS.EXE isn't around, a kernel panic ensues and everything halts; no buffers are flushed, no more network requests are handled, and so on.  Don't ask me why Microsoft considers console access so critical.

Depending on the version of NT, the machine may immediately reset or hang on a blue screen.  That's right, this bug affects more than one version of NT.  It's known to be in Windows XP, Windows 2000, and Windows NT 4.0.  It may be in NT 3.5 and NT 3.1 as well.  Basically, if you run NT, you have this bug.

I know what you're thinking; bounds checking isn't that hard to fix, and we already know where to find the relevant code, so Microsoft probably has a patch out already.  Guess what?  The bug has been public knowledge since late October of 2001 and as of now, no patch is available.  Microsoft hasn't even admitted this bug exists.

Even worse, Microsoft is due to stop supporting NT 4.0 in a year or two and has already abandoned NT 3.5 and NT 3.1.  It's unlikely those three will ever see a patch.

O.K., if Microsoft isn't going to be any help, an administrator will have to fill in.  Force anyone other than trusted admins into a guest account.  Prevent them from uploading and executing their own programs.  From now on, only a small set of programs are permitted.  That should take care of it, right?

Nope.

Despite its importance to NT, CSRSS.EXE handles all console output by any user.  Administrative privileges are irrelevant.

And I said all console output.  This means Visual Basic programs can still down NT.  As can a Perl script.  Or Python, Tcl, QBasic, and even a few Java programs.  The only exceptions are programs that do more than just spit data at the console.  For instance, EDIT is safe, but TYPE isn't.

In case you missed that, let me make it clear: you can crash NT merely by printing out a text file to a console.  It sounds impossible, but I've confirmed it on a Windows XP box with a 16 MB text file.

While I could use this nasty bug to bash Microsoft and sell Linux, I'm more concerned about all those vulnerable NT machines.  Maybe if we spread this info around enough, we can get Microsoft to pay attention and release a fix.

It sure beats waiting for a worm to exploit it, anyway.