COMMAND

    SP5

SYSTEMS AFFECTED

    WinNT + SP5

PROBLEM

    Les Landau found following.   He reported this to the  Microsoft's
    Security  Advisor  on  26/8/1999.   When  NT  SP5  is applied to a
    workstation (either by someone  sitting at the workstation  or via
    some  distribution  system  such  as  SMS)  the  service  pack  is
    installed in an admin context (it needs to be) and as part of  the
    installation,  it  places  a  number  of  entries  in  the RunOnce
    registry key, so that on re-boot these programs will be run  (this
    is not documented as part of any readme's in SP5).

    In  a  large  corporate  environment,  users  do not normally have
    administrator  access  to  their  workstations,  and  so after the
    re-boot for SP5, they log on  and the RunOnce entries are run  (in
    the user context).  Two problems here:

        1. That the programs may  not run correctly, as they  probably
           need an admin context and
        2. (the  security concern)  that the  entries are  NOT removed
           from the RunOnce key and will be executed every time a user
           logs on until one of them is an admin (Domain or local).

    So, given this situation, the user can then alter the contents  of
    two   executables   files   referenced   in   the   RunOnce    key
    (%systemroot%\system32\pstores.exe   and   csvroot.exe)   to    be
    something else, such as a privilege elevation program.  Users have
    full  access  to  these  files.    Next  they  need  to  have   an
    administrator log  on some  time, and  then they  will have  their
    substituted programs  run once,  and be  removed from  the RunOnce
    key.

SOLUTION

    It is  amazing that  Microsoft would  release a  Service Pack that
    requires an admin to signon afterwards and not inform ppl of  that
    need, or how to achieve that where there are thousands of desktops
    to visit.  In any case, even if users followed all of  Microsoft's
    recommendations  and  the  system  was  "secure", SP5 would not be
    installed correctly until an administrator logged on.

    Workarounds:
    1. A suggested way has been  to do the AutoAdmin logon thing  with
       keyboard and mouse locking.  Problem with this is that you also
       have to display the last username and remove legal text  before
       that will work (and then put it back afterwards).  Also if  SP5
       stuffs the machine somehow, then  you may end up with  a locked
       machine as a result of needing  to do the re-boot.  Further  to
       that, the  file that  does the  AutoAdmin thing,  will need  to
       include  the  admin  user  account  and password, and that will
       probably not be encrypted.

    2. Ensure that the job you distribute with SMS to install SP5 also
       sets ACLs on  %systemroot%\system32\pstores.exe and csvroot  as
       well as on regsvr32.exe which is also used.  Work out some  way
       for admins to logon sometime.

    3. Ensure that the job you distribute with SMS to install SP5 also
       sets ACLs on  %systemroot%\system32\pstores.exe and csvroot  as
       well as on regsvr32.exe which  is also used.  Distribute  a job
       with SMS (post SP5) that  will run all the RunOnce  entries and
       remove  the  contents  of  the  key  afterwards.   All in admin
       context.

    4. Tighten  up  NT  security  on  all your NT workstations  before
       implementing SP5 (impractical).

    Some references:

        http://www.microsoft.com/ntserver/security/exec/overview/Secure_NTInstall.asp
        http://www.trustedsystems.com/NSAGuide.htm
        http://www.sans.org/ntstep.htm