About | Buy | News | Products | Rants | Search | Security
Home » News

Full Disclosure

December 10, 2001 4:10 PM UTC
Or why little boys and girls shouldn't tell lies. Read the original at http://incidents.org/diary/diary.php?id=112.

Monday, December 10th 2001
Non-Standard Packet Drivers and Why We Need Full Disclosure

Tom Liston has discovered that packets sent by a driver that does not use the Microsoft network protocol stack will not be blocked (or even seen) by some personal firewalls. Most notably, Zone Alarm and Zone Alarm Pro allow these outbound packets to flow unimpeded even when configured to 'Block All'. Further, Mr. Liston found that even under 'Block All' conditions, an application can sniff certain types of packets off the wire, even when the packets are denied by the firewall. These two facts taken together imply that an attacker could accomplish two-way communication with a compromised host without having to disable or reconfigure the victim's personal firewall. (Tiny Personal Firewall was also found to be vulnerable.)

Mr. Liston acknowledges that the technical challenge of building a firewall that will gracefully handle unrecognized packet drivers is significant. However, he still argues that vendors are grievously at fault for routinely making intentionally misleading claims regarding the capabilities of their products. Mr. Liston states: '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.'

(Recall that a different but related problem was discussed weeks ago when researchers demonstrated that a 'trusted' process such as IE can be commandeered by a rogue application and used to send packets that will be allowed out by personal firewalls:
http://www.incidents.org/diary.php?id=50 )

Mr. Liston explains: '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.)'

Mr. Liston's further criticized Zone Alarm's 'fix' for the problem which appears to simply black hole TCP packets generated by non-standard drivers. Zone Labs' Director of Corporate Communications, Te Smith, posted the following rebuttal:

'Tom's 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.'

Mr. Smith vaguely blamed the fundamental problem on a 'bug in Windows NDIS layer', and did not provide additional details.

Mr. Liston responded again and outlined some of the misleading remarks in Mr. Smith's argument. For example, Tom noted that his original complaint was that the Zone Labs fix blocked all outbound TCP packets sent by non-standard drivers. Mr. Smith's VPN example is irrelevant here since VPN drivers typically use IP protocols other than TCP (e.g. type 50 and 51).

Matt Scarborough made several additional observations regarding Mr. Smith's contention that only a process already running with administrator privileges would be able to use a home-grown protocol stack (that is, 'game over' anyway). Specifically, Mr. Scarborough pointed out (with references) that under certain conditions ANY non-privileged user can access the packet driver. One such circumstance is when an Administrator has previously installed and loaded the WinPCap driver used by WinDump, WinSnort, Ethereal, etc.

Mr. Scarborough also made the excellent point that: 'It seems to me that any Personal Firewall vendor making the claim that its product protects against 'known and unknown Internet threats' (See: http://www.zonelabs.com/) would have somehow stumbled across the capabilities of packet injection using alternative device drivers.'

In general, this discussion illustrates the necessity of full disclosure if nothing else. If this type of vulnerability information is not made available to the public, vendors will be tempted (and perhaps even forced by competition) to make increasingly overblown claims regarding the capabilities of their products. If full disclosure were disallowed, these claims could not be exposed as false or misleading. Then the real loser becomes the consumer who is unable to accurately assess the risks to the computers protected by these products.

About | Buy | News | Products | Rants | Search | Security
Copyright © Radsoft. All rights reserved.