COMMAND

    NAI

SYSTEMS AFFECTED

    McAfee Netshield and VirusScan 4.5

PROBLEM

    Richard  Fry  found  following.    During  extensive  testing   of
    Netshield  4.5  and  VirusScan  4.5  a potential security loophole
    emerged in the AutoUpgrade facility of the product.

    If the  directory pointed  to by  the mechanism  (controlled via a
    registry key) is insecure and has the correct format (PKGDESC.INI,
    SETUP.ISS included) any file which  is placed there with the  name
    of SETUP.EXE will be run in local administrator context.

    Actually, SETUP.EXE will be run in the context of whatever account
    is  used  to  run  4.5's  equivalent  of  the old 4.03 McAfee Task
    Manager.

    AutoUpgrade, for those  without experience works  like this:   You
    grab the  latest SuperDAT  file (SDATnnnn.EXE)  from NAI's website
    or FTP server.   You then put it  in a directory with  these other
    mentioned files  (PKGDESC.INI, SETUP.ISS,  etc) and  rename it  to
    SETUP.EXE.   Voila!   You have  just created  a McAfee AutoUpgrade
    site.  Because of the relative complexity of this procedure,  most
    installations make the very wise choice of having a single  server
    go and grab the SDAT file each week, dump the old SETUP.EXE,  then
    dump the  new file  in and  rename it.   Then AutoUpgrade  on  all
    workstations and other servers are pointed to the shared directory
    where  these  files  reside.   Boom!   All  stations  are  updated
    regularly, as long as the server  is able to get to NAI's  site to
    update its own AutoUpgrade site.

    Hopefully, registry  security has  been generally  hardened on all
    accessible  servers  in  your  enterprise.   And  also  hopefully,
    administrative rights and permissions are doled out very sparsely,
    as well.   This should  protect the  servers from  either registry
    shenanigans  (to  run  ANOTHER  SETUP.EXE)  or  file   replacement
    (subbing in  a trojan  SETUP.EXE "in  place").   Further, you have
    hopefully  used  a  service  account  for  McAfee  that is a local
    Administrator on all the  workstations, but has no  further domain
    rights or  permissions beyond  those necessary  to reach  the file
    share.

    However,  the  workstations  are  WIDE  OPEN  as  far  as  this is
    concerned, unless you also secure their registry permissions.

    Scenario: Domain Admin  Bob secures his  servers and domain(s)  in
    general  against  every  known  threat  to  people,  property, and
    liberty.   He makes  sure his  AutoUpgrade site  is safe  from the
    world.   He then,  for good  measure, implements  desktop security
    procedures  that  protect  the  users  from themselves (somewhat).
    After  a  hard  day's  work,  he  returns  to  his own workstation
    (probably wide open,  due to laziness  or "it can't  happen to me"
    syndrome...admins are notorious  for this) only  to find that  his
    AutoUpgrade has  been used  (via a  trojan SETUP.EXE  run from  an
    altered location) to create a new Domain Admin account, which  has
    in turn been used to  delete the company's financial data  for the
    last  six  years,  change  all  occurrences  of  "plan" to "peanut
    butter" in all Word documents,  and deface the website to  espouse
    the relative merits of paper versus plastic.

SOLUTION

    NAI have been informed and  there response is "This security  hole
    can be  filled by  the operating  system, using  user rights,  and
    registry lockdown.  Some of this is outlined in the NetShield  4.5
    Administrators Guide".   NAI also claim  that this "feature"  also
    exists in  other scheduling  type software  such as  the Microsoft
    Scheduler.

    Shouldn't be a threat to anything but workstations unless you have
    sloppy admins.