|Georgi Guninski security advisory #45, 2001
Elevation of privileges with debug registers on Win2K
Win2K, Win2K SP1
have not tested on Win2K SP2 but according to Microsoft SP2 fixes this
Date: 24 May 2001
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.
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.
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.
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
Workaround: According to Microsoft SP2 fixes this though I have not
verified it personally.
Microsoft was informed on 20 May 2001