COMMAND

    screen saver

SYSTEMS AFFECTED

    Win NT 3.5x, 4.0, 5.0

PROBLEM

    Cybermedia Software  has found  the following  vulnerability.  The
    Screen Saver is  started by Winlogon.Exe  whenever the machine  is
    idle for the specified amount  of time. Screen Saver setting  is a
    per user property and every user  has right to set his own  screen
    saver.  The screen saver is started by Winlogon.Exe, initially  in
    a suspended mode using CreateProcess API call.  Once  Winlogon.Exe
    gets the process  handle to screen  saver, it changes  the primary
    security token of the screen saver  to that of the logged in  user
    and  then  resumes  the  screen  saver  process.  This is done for
    security reasons.   If Winlogon were  to NOT do  this, then screen
    saver would run with  the security context of  Winlogon.Exe (which
    runs in system context).

    The Winlogon.Exe DOES  NOT check whether  the changing of  Primary
    token is successful.  Hence if setting of primary token fails  due
    to some reason, the screen saver binary will run in system context
    and be able to  do whatever it pleases  (e.g adding the logged  in
    user to admin group).

    On Windows NT 3.51 and all its service packs, Windows NT 4.0  with
    Service  Pack  1,  and  NT  5.0  beta1  and  beta2, when an MS-DOS
    application  is  spawned,  the  returned  process  handle  is junk
    (rather it is a special event handle).  The simulation consists of
    one  32-bit  application  say  BEADMIN.EXE  and  one  MS-DOS based
    application, say SCRNSAVE.EXE.  The BEADMIN.EXE when started  does
    the following

        * Creates one event in `not-signal'ed state
        * Sets up  the screen saver.   The screen saver  executable is
          specified as SCRNSAVE.EXE and the timeout is set to minimum.
          BEADMIN.EXE now waits on the event.

    After some time, the screen  saver is triggered.  This  results in
    Winlogon.Exe spawning SCRNSAVE.EXE.  Since the CreateProcess  call
    returns junk handle to Winlogon.Exe, the setting of primary  token
    fails.   Hence the  SCRNSAVE.EXE application  (NTVDM.EXE) runs  in
    System  Context.   This  SCRNSAVE.EXE  again  spawns   BEADMIN.EXE
    application.   Now this  second copy  of BEADMIN.EXE  inherits the
    security  context  of  NTVDM   which  is  System  Context.    This
    application adds the logged in user to admin group and signals the
    event  on  which  first  instance  of  BEADMIN.EXE is waiting.  In
    response to  this the  first copy  of BEADMIN.EXE  resets back the
    Screen  Saver  settings  and  quits.   The  logged in user name is
    passed  between  the  first  and  second copy of BEADMIN.EXE using
    shared section. To download Demo for Screen Saver vulnerability:

        http://www.cybermedia.co.in/Free%20Downloads/ScrnSave.zip

    It  is  important  to  understand  that  the user must able to run
    exploitation  code  on  a  machine  in  order  to  elevate   their
    privileges. There are two types of machines at risk:

       - Machines that allow non-administrative users to interactively
         log on.  Workstation and terminal servers typically do  allow
         this,  but,  per  standard  security  practices,  most  other
         machines only allow administrators to interactively log on.
       - Machines that allow remote users to submit arbitrary programs
         for execution.  Servers such  as domain  controllers, line of
         business servers, application servers, print and file servers
         and the like typically  do not accept arbitrary  programs for
         execution.

    It  also  is  important  to  note  that the scope of the privilege
    elevation is  highly dependent  on the  specific machine  on which
    the exploitation code is run.   For example, a user who  exploited
    this  vulnerability  on  a   workstation  could  join  the   local
    Administrators  group,  but  could   not  directly  exploit   this
    vulnerability to become a  domain administrator.  However,  a user
    who exploited this vulnerability  on a domain controller  would be
    able to become a domain  Administrator, because the domain SAM  is
    shared among all domain controllers.

SOLUTION

    Microsoft has released patches that fix the problem identified.
    The patches are available for download from the sites listed
    below:

        ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa/NT40/hotfixes-postSP4/ScrnSav-fix/Scrnsavi.exe
        ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa/NT40TSE/hotfixes-postSP3/ScrnSav-fix/Scrnsavi.exe
        ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa/NT40/hotfixes-postSP4/ScrnSav-fix/Scrnsava.exe
        ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa/NT40TSE/hotfixes-postSP3/ScrnSav-fix/Scrnsava.exe