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