ZoneAlarm and ZoneAlarm Pro can be stopped from loading by creating a memory-resident Mutex (using a call to the CreateMutex API). Uninstalling\reinstalling ZoneAlarm in a different path has no effect.
The impact of this vulnerability is that a Trojan running on a victim's machine can prevent ZoneAlarm from loading, and thus leave the victim open for attack.
Zone Labs "ZoneAlarm" and "ZoneAlarm Pro" programs both use a Mutex - an event synchronization 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.
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 and ZoneAlarm Pro are then prevented from loading as long as 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 its local process token privileges to SeDebugPrivilege, giving it the power to kill any process/service.
Demonstration:
A harmless, simple, working executable to demonstrate the vulnerability, is 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).