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
This archive was generated by hypermail 2b30 : Thu May 24 2001 - 09:56:26 PDT