Hi rdmaloyjr,
I think Steve Gibson and others gave the free ZA a mythical status it cannot live up to. Read this here. I do not know if ZA is still vulnerable to this mutex exploit, but ZA must not acquire a sort of Snort status, the software Firewall of choice. Read this:
------------------------
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). (not available here)
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--------------------------
I quoted this in its entirety, because this should be with this source, but what do you think about this? I think in future, especially DSL users should have mutual FW-alling a hardware packet-filtering device and a software firewall period.
polonus
