Sign Up for Your FREE Weekly SecurityTracker E-mail Alert Summary
Put SecurityTracker Vulnerability Alerts on Your Web Site -- It's Free!
Become a Partner and License Our Database or Notification Service
ZoneAlarm Firewall Fails to Block Outbound Packets From Alternate Protocol Stacks
SecurityTracker Alert ID: 1002937|
SecurityTracker URL: http://securitytracker.com/id/1002937
(Links to External Site)
Date: Dec 11 2001
Host/resource access via network|
Vendor Confirmed: Yes |
Version(s): 2.6; possibly earlier versions|
A vulnerability was reported in the ZoneAlarm Firewall software for Microsoft operating systems. The software fails to inspect and block outbound packets generated by alternate protocol stacks.|
It is reported that the "Lock" or "Block All" setting of the firewall is ineffective against TCP packets from non-standard protocol adapters (i.e., any protocol stack other than the default Microsoft stack).
The vendor is apparently aware of the flaw and working on a fix.
An alternate protocol stack can send packets that will bypass the firewall's access control filtering mechanism.|
No solution was available at the time of this entry. The vendor is apparently working on a fix.|
Vendor URL: zonelabs.com/products/zap/index.html (Links to External Site)
Access control error|
|Underlying OS: Windows (Me), Windows (NT), Windows (95), Windows (98), Windows (2000), Windows (XP)|
Source Message Contents
Date: Wed, 5 Dec 2001 17:08:57 -0600|
Subject: Flawed outbound packet filtering in various personal firewalls
Issue: Outbound filtering in personal firewalls does not block
packets that are generated by protocol stacks other than the
default Microsoft stack.
Description: While working to port LaBrea to the Win9x platform, I
was faced with the task of creating packets with specific flags,
window sizes, etc... In order to accomplish this, I was forced to
"roll my own" protocol adapter that would allow me to send TCP
packets formatted in specific ways. As a side effect of this, I found
that at least two personal firewalls don't "see" the TCP packets
that this "non-standard" protocol adapter generates.
In experimenting further, it was found that the "Lock" or "Block All"
settings of those firewalls was also ineffective against TCP packets
from non-standard protocol adapters.
Known vulnerable firewalls: ZoneAlarm and ZoneAlarm Pro as of
their current revisions and Tiny Personal Firewall. Although I
cannot test it, I believe all versions prior to the current ones are
Vendor responses: ZoneLabs was initially contacted regarding this
issue on November 9th. Since that time, I've received sporadic
updates on their progress in fixing this issue. As of the present
time, I have tested at least one ZoneLabs supplied "fix." The
method of "fixing" this issue, as demonstrated by this "beta" was
to silently drop all TCP packets not originating from the standard
Windows TCP protocol adapter. I have explained to Zone Labs that
I don't believe this is a valid approach.
They have, in my estimation, taken this route because they cannot
trace the source of packets back through a protocol adapter that
they know nothing about. Any other approach would require that
they issue a warning to the user, saying essentially "Some
application on your machine has attempted to send a TCP packet.
We don't know what that application is... we can't know.... So! Do
you want to let it communicate?" That would tend to tarnish the
carefully crafted ZoneAlarm image.
I fully expect to take heat from ZoneLabs for publishing this
vulnerability. However, I will say this: ZoneLabs has, from the
outset, done nothing but attempt to duck, mislead and obfuscate
the issue. It has been over three weeks, and I have seen nothing
from them but a buggy beta "fix" that essentially breaks NDIS
functionality without any warning to the user. I have asked them to
confirm for me in writing their intention to "fix" this issue by silently
dropping valid packets.
Tiny Software: Tiny was also contacted in mid-November, but did
not reply. I have recently re-contacted Tiny, and they have now
acknowledged that the problem exists, and have stated that they
intend to block "non-standard" protocol access to NDIS, but have
yet to reply about how (ie. silent drop, warn the user, etc...) this
will be accomplished.
Note: Other personal firewalls might very well be susceptible to this
same problem. I haven't the time or the resources available to test
Also troubling is the fact that, in both cases, specially crafted
packets can be sent *to* a machine which an application can sniff
off the wire. These packets are ignored by the personal firewalls
and there is no warning to the end user. This makes two-way
communication possible with a machine, even when its firewall is
set to "Lock" or "Block All" network traffic.
Please forgive me for jumping on my soap box: I believe that the
real issue at hand has little to do with vulnerabilities and protocol
adapters. The real issue here is marketing. The entire personal
firewall industry has been driven to make claims that it cannot
deliver on. There is a vicious "me too" cycle that drives personal
firewall vendors. Now, there are testing labs and "certifications."
(Both TinyPFW and ZoneAlarmPro are certified by ICSA Labs.)
This is just insane. When I look at the concept of "outbound
filtering", I see a distinct parallel to "copy protection." Both
concepts suffer from the same, basic flaws. The problem is in the
claims that personal firewall vendors are making and the fact that
they're allowed to get away with it.
An application, demonstrating this vulnerability is available at:
Tom Liston, GSEC
Prem Magnetics, Inc.
Go to the Top of This SecurityTracker Archive Page