WayneDiamondCS.com.au

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Diamond Computer Systems Security Advisory

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

VULNERABILITY:
 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.

SEVERITY:
 Low-Medium, but as Zone Labs will not be fixing the problem it could be
considered Medium-High.

AFFECTED SOFTWARE:
 "Zone Alarm" and "Zone Alarm Pro" (Zone Labs Inc. - www.zonelabs.com),
possibly all versions.

REMOTE EXPLOIT:
 No.

RELEASE DATE:
 Friday Dec 29, 2000

VENDOR NOTIFIED:
 Zone Labs Inc. were notified 12th of October, 2000

---
DESCRIPTION:
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).
THE PROBLEM:
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.
THE EXPLOIT:
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.
SOLUTION:
We offered suggestions to Zone Labs Inc. in October/November, including
encryption/hashing of the Mutex, but all were dismissed, and none have been
implemented.
ZONE LABS RESPONSE:
From Conrad Hermann, VP of Engineering at Zone Labs, in regards to
encrypting the mutex:
"... the solution you propose is one of "security through obscurity", which
isn't really good enough for us--mainly because it means it will eventually
need to be re-implemented to be truly secure. It would not be impossible to
discover the same base information, re-implement the same encryption
algorithm, and use the same key we use to encrypt/hash the data--this is
precisely the methodology that most software crackers use, and most software
that anyone cares to crack has been cracked."
In other words, 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.
DEMONSTRATION:
We have created a harmless, simple, working executable to demonstrate the
vulnerability, available at http://www.diamondcs.com.au/alerts/zonemutx.exe
(16kb).
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).
--
DiamondCS would like to thank Steve Gibson of grc.com for his mutual
assistance to both DiamondCS and Zone Labs.
Publishing of this document is permitted providing the text is published in
it's entirety and with no modifications.
Copyright (C) 2000, Diamond Computer Systems Pty. Ltd.
http://www.diamondcs.com.au - http://www.diamondcslabs.com

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]