COMMAND

    getadmin

SYSTEMS AFFECTED

    Win NT 4.0

PROBLEM

    Mnemonix posted yet another  "get yourself admin rights  exploit".
    This exploit requires nothing  more than the default  permissions.
    By  default,  the  group  "Everyone"  has  special  access  to the
    following registry key:

        HKLM\Software\Microsoft\Windows NT\CurrentVersion\AeDebug

    As part of  the special access,  "Everyone" is allowed  to Set the
    values  of  the  entries.   The  default  for  the  debugger  is :
    "drwtsn32 -p %ld  -e %ld -g".  Anyone can change  this to whatever
    they want but for this exploit  to work it needs to be  changed to
    simply "usrmgr.exe"  on an  NT server  or "musrmgr.exe"  on an  NT
    Workstation.

    You now need  to get a  service to crash.  When we say  service we
    mean any process started by the  system.  It needs to be  a system
    process because a  child process will  inherit the permissions  of
    the process that spawned it.  When and if you can get a service to
    crash User Manager will be started with system privs.  Below is an
    account of the testing of this.

    When Mnemonix ran getadmin.exe on NT 4 Workstation (SP1) a  memory
    error occured in  winlogon.exe.  He  then upgraded the  PC to SP3.
    When  he  ran  getadmin  the  same  access  violation  occured  in
    winlogon.exe.   He  logged  on  as  a  plain old user, changed the
    debugger  to  musrmgr.exe  and  then  ran getadmin.exe... what was
    strange was the fact that he had to run getadmin on a non-existent
    account first  then run  it against  the account  he was logged on
    with before it  would load User  Manager.  If  you didn't do  this
    then the system would tell you  of a memory problem as opposed  to
    the debugger being loaded.   As to why getadmin was  failing after
    SP3 was installed we can't be  quite sure.  Anyway, it seems  this
    exploit will work on  NT Server and workstation  SP1 (and on 1  NT
    Wkst SP3 - the same getadmin  program works fine on all other  SP3
    machines.) No hotfixes have been applied.

    This could  obviously be  refined....spoolss.exe and  winlogon.exe
    being  the  likely  candidates  to  be targeted for causing memory
    problems...all that you need is either  a way to get a service  to
    crash or to write a util that will do it for you.

SOLUTION

    The fix is to ACL the registry key as described in the white paper
    on  securing  Windows  NT  at  http://www.microsoft.com/security/.
    The white paper is dated October, 1997, but this fix was described
    in versions from 2 years ago.  Note however - that will break some
    things.  SP4 comes with SCE and might include fix for this.