Vulnerability

    ZoneAlarm

Affected

    ZoneAlarm (Pro)

Description

    Following is based  on a Diamond  Computer Systems Sec.  Advisory.
    ZoneAlarm  and  ZoneAlarm  Pro  can  be  stopped  from  loading by
    creating  a  memory-resident  Mutex  (one  call to the CreateMutex
    API).   Uninstalling\reinstalling  ZoneAlarm  in  a different path
    has no effect.

    This is Low-Medium risk, but as  Zone Labs will not be fixing  the
    problem so it could be considered Medium-High.

    Zone  Labs  "ZoneAlarm"  and  "ZoneAlarm  Pro" programs both use a
    Mutex - an event synchronisation  memory object - to determine  if
    it has already loaded (to prevent loading a second instance of the
    firewall).

    By design, ZoneAlarm\ZoneAlarm Pro has no way of determining WHICH
    program actually set the Mutex, thus allowing a trojan to use  the
    Mutex and block both ZoneAlarm and ZoneAlarm Pro from loading.

    A trojan can easily set  this Mutex ("Zone Alarm Mutex")  with one
    simple call  to the  CreateMutex API  (see msdn.microsoft.com  for
    more information on Mutexes).  ZoneAlarm\ZoneAlarm Pro are then be
    prevented from loading while the trojan is alive. If ZoneAlarm  is
    running, all the  trojan has to  do is terminate  the processes of
    zonealarm.exe, vsmon.exe and minilog.exe first before creating the
    Mutex.  Despite being services, vsmon.exe and minilog.exe can both
    be  killed  by  any  program  by  setting it's local process token
    privileges to SeDebugPrivilege,  giving it the  power to kill  any
    process/service.

    DiamondCS have created a  harmless, simple, working executable  to
    demonstrate the vulnerability, available at

        http://www.diamondcs.com.au/alerts/zonemutx.exe

    While the demo program  is running, you will  not be able to  load
    ZoneAlarm   or   ZoneAlarm   Pro,    and   if   it   finds    that
    ZoneAlarm\ZoneAlarm  Pro  is  running,   it  will  terminate   the
    ZoneAlarm  processes  and  services  first  using SeDebugPrivilege
    before stealing the ZoneAlarm Mutex.  The demo also opens an  echo
    server socket  to listen  on TCP  7, allowing  you to  test socket
    connectivity/data transfer (try telnetting to 127.0.0.1 on port  7
    and saying hello).

Solution

    DiamondCS offered  suggestions to  Zone Labs  in October/November,
    including encryption/hashing of the Mutex, but all were dismissed,
    and none have been implemented.  According to Zone Labs encryption
    isn't  good  enough  for  Zone  Labs,  so  they  have opted to use
    plain-text.  Even despite  exhaustive correspondance to Zone  Labs
    between DiamondCS and Steve Gibson  / GRC, they have expressed  no
    desire  in  fixing  the  vulnerability.   Because  of this, trojan
    authors are now free to  exploit it, knowing that the  vendor will
    not be fixing the problem.  This alone escalates the magnitude  of
    the problem.