Elevation of privileges with debug registers on Win2K

[Georgi Guninski <guninski () guninski com>]

Georgi Guninski security advisory #45, 2001

Elevation of privileges with debug registers on Win2K

Systems affected:
Win2K, Win2K SP1 
have not tested on Win2K SP2 but according to Microsoft SP2 fixes this

Risk: High
Date: 24 May 2001

Legal Notice:
This Advisory is Copyright (c) 2001 Georgi Guninski. 
You may distribute it unmodified. 
You may not modify it and distribute it or distribute parts 
of it without the author's written permission.

Disclaimer:
The information in this advisory is believed to be true based on 
experiments though it may be false.
The opinions expressed in this advisory and program are my own and 
not of any company. The usual standard disclaimer applies, 
especially the fact that Georgi Guninski is not liable for any damages 
caused by direct or  indirect use of the information or functionality 
provided by this advisory or program. Georgi Guninski bears no 
responsibility for content or misuse of this advisory or program or 
any derivatives thereof.


Description:

If someone can execute programs on a target Win2K system then he may
elevate his privileges at least to extent which gives him write access
to C:\WINNT\SYSTEM32 and HKCR.


Details:
The problem is the x86 debug registers DR0-7 are global for all processes.
So setting a hardware breakpoint in one process affects other processes and
services. If the hardware breakpoint is hit in a service then an unhandled
single step exception occurs and the process/service is terminated.
After the service is terminated it is possible to hijack its trusted named
pipes and when another service writes to the named pipe it is possible to 
impersonate the service.
In my exploit pipe3.cpp LSASS.EXE is killed with the help of hardware breakpoint
and then \\.\pipe\lsass is hijacked.
Simple test for debug registers: Start debugging CALC.EXE with windbg.
Set hardware breakpoint on memory write to the current value of ESP.
Start taskmgr.exe and wait some time.
If you start receiving Single Step exception with dialog boxes and/or BSOD
in processess other than CALC.EXE then there is vulnerability.

Notes on using pipe3.cpp:
pipe3.cpp is kind of ugly but works on all the boxes I have tested.
It has 2 arguments - <pid of LSASS.EXE> and <ESP in LSASS.EXE>.
Build and start pipe3. Wait some time. The expected result is to get
exception in LSASS.EXE and then it must be terminated. Then after sometime
the console is locked and the mashine is rebooted. A file is created in 
c:\winnt\system32 and a key in HKCR.
If LSASS.EXE is not terminated stop and restart pipe3.
If nothing happens you may need to play with the parameter MAGICESPINLSA -
this is the ESP in a thread in LSASS.EXE.
If you get BSOD then you need more playing with the parameter and or Sleep().

Workaround: According to Microsoft SP2 fixes this though I have not verified it
personally.

Demonstration:
http://www.guninski.com/pipe3.cpp

Vendor status:
Microsoft was informed on 20 May 2001.

Regards,
Georgi Guninski
http://www.guninski.com

Attachment: pipe3.cpp
Description: