SalaTar
12-30-2000, 08:27 AM
Diamond Computer Systems Security Advisory http://www.diamondcs.com.au/alerts/zonedown.txt
VULNERABILITY:
ZoneAlarm and ZoneAlarm Pro can be taken down with a tiny batch file.
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), (http://www.zonelabs.com),)
possibly all versions.
REMOTE EXPLOIT:
No.
RELEASE DATE:
Friday Dec 29, 2000
VENDOR NOTIFIED:
Zone Labs Inc. were notified on Wednesday Dec 27, 2000, but as Zone Labs
have given a final response to this particular vulnerability, it can now be
disclosed to the public.
---
DESCRIPTION:
ZoneAlarm and ZoneAlarm Pro, like all good multi-filed programs, supports an
Uninstall feature. The Uninstall routine executes zonealarm.exe (or
zapro.exe in the Pro version), vsmon.exe, and minilog.exe, passing special
uninstall and unload parameters to each program. By doing this, ZoneAlarm
shuts down it's user interface and services.
THE PROBLEM:
By design, ZoneAlarm\ZoneAlarm Pro has no way of determining WHICH program
is calling it to unload, thus allowing a trojan to execute the ZoneAlarm
programs in the same way to shut down the firewall.
THE EXPLOIT:
A very trivial exploit - all a trojan has to do is look in
HKEY_LOCAL_MACHINE\SOFTWARE\Zone Labs\ZoneAlarm\InstallDirectory to locate
ZoneAlarm.exe (as just one of many ways to locate ZoneAlarm), then locate
the Windows System32 directory before executing zonealarm.exe, vsmon.exe and
minilog.exe, parsing each one the uninstall and unload parameters as
specified in ZoneAlarm's Manual Uninstall.
ZONE LABS RESPONSE:
From Conrad Hermann, VP of Engineering at Zone Labs:
"...Of course, you are intended to be able to uninstall ZoneAlarm--as I'm
sure you can tell, this is a very important thing to be able to do, since it
is an introductory product for new users. In testing ZoneAlarm Pro, it seems
you did not set a password, or else you would have reported that the
password would be required to shut down using VSMON -unload. Without the
password, vsmon -unload doesn't disable security."
In other words, if you get the buy-before-you-try version of ZA (ZoneAlarm
Pro) AND you set passwords, you won't be vulnerable. As a matter of
convenience, the majority of ZoneAlarm Pro users would _NOT_ use passwords -
and by default there is no need for them to do so. It appears those who
don't set passwords and regular ZoneAlarm users are left out in the cold
with this one.
DEMONSTRATION:
Running this batch file will shut-down your ZoneAlarm\ZoneAlarm Pro
firewall. The batch file assumes that you have installed ZoneAlarm\ZoneAlarm
Pro into their default directory locations. Needless to say, this isn't a
very efficient way of using the exploit, and a trojan would be a lot smarter
in determining the locations of the four ZA executables, but this batch file
demonstrates the simplicity of the vulnerability.
---File begins: ZONEDOWN.BAT ---
@echo off
@echo Shutting down ZoneAlarm and ZoneAlarm Pro, one moment...
c:\progra~1\zonela~1\zoneal~1\zapro.exe -unload
c:\progra~1\zonela~1\zoneal~1\zoneal~1.exe -unload
%windir%\system\zonelabs\vsmon.exe -unload -uninstall
%windir%\system\zonelabs\minilog.exe -unload -uninstall
%windir%\system32\zonelabs\vsmon.exe -unload -uninstall
%windir%\system32\zonelabs\minilog.exe -unload -uninstall
@echo Finished
@echo on
---File ends---
--
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
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), (http://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
VULNERABILITY:
ZoneAlarm and ZoneAlarm Pro can be taken down with a tiny batch file.
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), (http://www.zonelabs.com),)
possibly all versions.
REMOTE EXPLOIT:
No.
RELEASE DATE:
Friday Dec 29, 2000
VENDOR NOTIFIED:
Zone Labs Inc. were notified on Wednesday Dec 27, 2000, but as Zone Labs
have given a final response to this particular vulnerability, it can now be
disclosed to the public.
---
DESCRIPTION:
ZoneAlarm and ZoneAlarm Pro, like all good multi-filed programs, supports an
Uninstall feature. The Uninstall routine executes zonealarm.exe (or
zapro.exe in the Pro version), vsmon.exe, and minilog.exe, passing special
uninstall and unload parameters to each program. By doing this, ZoneAlarm
shuts down it's user interface and services.
THE PROBLEM:
By design, ZoneAlarm\ZoneAlarm Pro has no way of determining WHICH program
is calling it to unload, thus allowing a trojan to execute the ZoneAlarm
programs in the same way to shut down the firewall.
THE EXPLOIT:
A very trivial exploit - all a trojan has to do is look in
HKEY_LOCAL_MACHINE\SOFTWARE\Zone Labs\ZoneAlarm\InstallDirectory to locate
ZoneAlarm.exe (as just one of many ways to locate ZoneAlarm), then locate
the Windows System32 directory before executing zonealarm.exe, vsmon.exe and
minilog.exe, parsing each one the uninstall and unload parameters as
specified in ZoneAlarm's Manual Uninstall.
ZONE LABS RESPONSE:
From Conrad Hermann, VP of Engineering at Zone Labs:
"...Of course, you are intended to be able to uninstall ZoneAlarm--as I'm
sure you can tell, this is a very important thing to be able to do, since it
is an introductory product for new users. In testing ZoneAlarm Pro, it seems
you did not set a password, or else you would have reported that the
password would be required to shut down using VSMON -unload. Without the
password, vsmon -unload doesn't disable security."
In other words, if you get the buy-before-you-try version of ZA (ZoneAlarm
Pro) AND you set passwords, you won't be vulnerable. As a matter of
convenience, the majority of ZoneAlarm Pro users would _NOT_ use passwords -
and by default there is no need for them to do so. It appears those who
don't set passwords and regular ZoneAlarm users are left out in the cold
with this one.
DEMONSTRATION:
Running this batch file will shut-down your ZoneAlarm\ZoneAlarm Pro
firewall. The batch file assumes that you have installed ZoneAlarm\ZoneAlarm
Pro into their default directory locations. Needless to say, this isn't a
very efficient way of using the exploit, and a trojan would be a lot smarter
in determining the locations of the four ZA executables, but this batch file
demonstrates the simplicity of the vulnerability.
---File begins: ZONEDOWN.BAT ---
@echo off
@echo Shutting down ZoneAlarm and ZoneAlarm Pro, one moment...
c:\progra~1\zonela~1\zoneal~1\zapro.exe -unload
c:\progra~1\zonela~1\zoneal~1\zoneal~1.exe -unload
%windir%\system\zonelabs\vsmon.exe -unload -uninstall
%windir%\system\zonelabs\minilog.exe -unload -uninstall
%windir%\system32\zonelabs\vsmon.exe -unload -uninstall
%windir%\system32\zonelabs\minilog.exe -unload -uninstall
@echo Finished
@echo on
---File ends---
--
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
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), (http://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