Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
From: Georgi Guninski (guninskiguninski.com)
Date: Thu May 24 2001 - 08:24:38 CDT

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    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.

    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 Sleep().

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


    Vendor status:
    Microsoft was informed on 20 May 2001.

    Georgi Guninski

    • application/x-unknown-content-type-cppfile attachment: pipe3.cpp