Home    |    View Topics    |    Search    |    Contact Us    |   



Category:   Application (Firewall)  >   Tiny Personal Firewall Vendors:   Tiny Software
Tiny Personal Firewall Fails to Block Outbound Packets From Alternate Protocol Stacks
SecurityTracker Alert ID:  1002936
SecurityTracker URL:
CVE Reference:   GENERIC-MAP-NOMATCH   (Links to External Site)
Date:  Dec 11 2001
Impact:   Host/resource access via network
Vendor Confirmed:  Yes  
Version(s): 2.0.15; possibly earlier versions
Description:   A vulnerability was reported in Tiny Software's Tiny Personal 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.

Impact:   An alternate protocol stack can send packets that will bypass the firewall's access control filtering mechanism.
Solution:   No solution was available at the time of this entry. The vendor is apparently working on a fix.
Vendor URL: (Links to External Site)
Cause:   Access control error
Underlying OS:  Windows (Me), Windows (NT), Windows (95), Windows (98), Windows (2000), Windows (XP)

Message History:   None.

 Source Message Contents

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

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
Network Administrator
Prem Magnetics, Inc.


Go to the Top of This SecurityTracker Archive Page

Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2021, LLC