7 Dec 2001 14:19:54

Tom responds to the spin.

   Date: Fri, 7 Dec 2001 14:19:54
     To: bugtraq@securityfocus.com
   From: Tom Liston
Subject: Re: Flawed outbound packet filtering in various personal firewalls


Since their response was posted here too, I'll post my rebuttal: 

There are several inaccuracies in ZoneLab's response that I feel the 
need to correct:

> Tom contacted us a couple of weeks ago with the 
> information that certain packet drivers can bypass the 
> low-level firewall that is part of our ZoneAlarm and 
> ZoneAlarm Pro drivers. Upon investigation we 
> confirmed the problem and we are testing a fix.

It was 3.5 weeks ago.  I suppose that could be considered 'a 
couple', but since I'm replying about other inaccuracies in this, 
why not be precise?

> It turned out that a bug in Windows NDIS layer allows 
> a packet driver to bypass any personal firewall or 
> similar product. 

Ah... It's Microsoft's fault...

> In order to exploit the bug, malicious 
> code would have to break through two levels of 
> protection in our software - our inbound firewall 
> protection and/or our MailSafe feature that blocks 
> potentially dangerous attachments. 

'Break though two levels of protection'?  That makes downloading a 
program sound like escaping from Alcatraz.

> In addition, a 
> malicious application would need administrative 
> privileges under Windows NT, 2000 and XP. 

This is correct.

> To date, 
> there have been no reports of actual exploits of this 
> potential vulnerability and we are working on a fix and 
> expect to have another build for testing next week.

I was promised one yet this week.
  
> After providing Tom with a test version of ZoneAlarm 
> Pro that sealed this vulnerability to confirm the fix, he 
> was then disappointed that his LaBrea@Home 
> application would not work any more. 

Yes, you're correct.  I was disappointed.  I was disappointed 
because perfectly valid TCP packets that were being sent by 
LaBrea@Home were being silently dropped by ZoneAlarm.  The user 
wasn't given the option to allow LaBrea@Home to work like they are 
for any other network application.  Why?  Because the TCP packets 
that LaBrea@Home generated were from a source other than a 
'standard' protocol adapter.

> LaBrea@Home 
> is a honey pot application that attempts to frustrate 
> hackers by initially responding to a scan but then not 
> continue 'the conversation'. The theory is that a 
> hacker would waste time in his/her scan but would 
> ultimately be unsuccessful in the attempt.  We'd 
> recommend that a honeypot application be put on a 
> separate machine and not be protected by a firewall.
>
> If used by security specialists,  honeypot applications 
> have their legitimacy, but we firmly advise against this 
> approach for most users because honey pots do 
> (and are designed to) attract subsequent attacks.

You're entitled to your opinion.

> ZoneAlarm and ZoneAlarm Pro will block 
> indiscriminate outbound traffic to untrusted 
> computers by applications that attempt to bypass the 
> normal TCP/IP stack and therefore we don't expect 
> that LaBrea@Home and our products will work 
> together. 

This is the answer that I've been trying for about three days.  For 
those of you who don't speak 'marketing', a translation:  ZoneAlarm 
*will* drop valid TCP packets simply because they don't originate 
from a 'standard' protocol driver.

> It is possible to configure ZoneAlarm and 
> ZoneAlarm Pro for this setup but we don't 
> recommend it for the reasons listed above.

Certainly not the beta version that I was sent.  No matter what 
settings I used, if it was a TCP packet, and it didn't come from 
winsock, ZoneAlarm sent it to packet heaven.

> Tom contention that we block any outbound traffic 
> issued by drivers other then the regular TCP/IP driver 
> is simply wrong.  For example, most VPN drivers do 
> just that in one way or the other. However we require 
> that such drivers only communicate with the trusted 
> computers as defined by the local zone in ZoneAlarm 
> and ZoneAlarm Pro.

This is really unfortunate.  What I *actually* said was that the 
beta version that I received blocked any outbound *TCP*  traffic 
issued by drivers other than the regular TCP/IP driver.  VPN 
packets, although they look remarkably like TCP packets are actually 
*not* TCP packets.  TCP packets are defined as IP type 6.  VPNs 
generally send IP type 50, or type 51 packets.

> Tom further complains that he doesn't get an alert for 
> every single blocked packet. This is as designed. 
> ZoneAlarm and ZoneAlarm Pro have been carefully 
> designed to eliminate unnecessary alerts. This 
> includes:
> 1) Only issue one alert for any hack attempt even if 
> the attempt consists of multiple packets.
> 2) Reduce alerts by 'Internet background noise'.
> 3) Repress alerts if issuing an alert might lead to a 
> DoS situation because processing the alerts start to 
> take up too much CPU time.

No, I didn't complain.  I simply stated that because ZoneAlarm 
*didn't* do this, it was possible write a program that communicated 
via two-way traffic with an external site while the user's personal 
firewall was set to block all traffic.  Indeed, I actually have a 
little 'chat' application that works wonderfully while ZoneAlarm's 
internet lock is engaged.

> This behavior is consistent with most professional 
> firewalls - personal or otherwise. In addition, 
> ZoneAlarm Pro allows the user to customize many of 
> the alert settings.

Once again, I'll state my contention that it isn't a matter of this 
specific vulnerability, it's a matter of marketing claims.  Personal 
firewall vendors are making claims, and people are buying software 
based on a faulty assumption: the assumption that outbound traffic 
can be reliably blocked.

-TL

Prev | TOC | Next