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. tlistonat_private tlistonat_private
This archive was generated by hypermail 2b30 : Thu Dec 06 2001 - 08:57:57 PST