[lusket fra bugtraq]
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
also vulnerable.
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
them.
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:
http://www.hackbusters.net/ob.html
-TL
Tom Liston, GSEC
Network Administrator
Prem Magnetics, Inc.
tliston@premmag.com
tliston@hackbusters.net