Date: Wed, 4 Nov 1998 11:41:32 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: Open Systems Networking <opsys@mail.webspan.net> Cc: freebsd-security@FreeBSD.ORG Subject: Re: Amazing wonder packet sneaks by deny all rule? Message-ID: <Pine.BSF.3.96.981104113649.29377C-100000@fledge.watson.org> In-Reply-To: <Pine.BSF.4.02.9811040815360.4966-100000@orion.webspan.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 4 Nov 1998, Open Systems Networking wrote: > It's really late/early this morning and I was just checking the rule set > on a clients machine I just built. When I saw this: > > 65534 195 14104 deny log ip from any to any > 65535 1 76 deny ip from any to any > > Now maybe it's my lack of sleep but how did that amazing wonder packet > on rule 65535 sneak by 65534 :-) A fluke? A 1 in a million chance? > A posessed packet? This isn't exactly the kind of thing that instills > confidence in ones choice of firewall software :-) > It's ipfw BTW if you cant tell from the syntax, not ipfilter. > I have NEVER seen this happen before, so im guessing it's just a freak > accident. But it is curious nonetheless. Chris, My guess it is a race condition. The packet arrived between when your network interface went up, and the ruleset was added. Because your default policy is deny, it worked fine. However, this does actually bring interesting risks to mind: as long as the rules are added in numeric order, and the default policy is deny, you should always get consistent (if overly draconian) policy during bootup. However, if you have your ipfw lines not in the rule order, then some allows might be installed in the list of rules *before* the denies that precede them. In this situation, the race condition would allow a packet in that should not have been allowed in. The whole effect is because the installation of ipfw rules is non-atomic. I wondered for a while about the same thing on some of my systems. It would be nice if it were possible to set up the rules, then 'apply' them atomically. I suspect that this is really the equivilent of ifconfig down before ipfw, then ifconfig up at the end. I seem to recall at one stage there were some bugs in the up/down behavior of some network drivers, but that was years and years ago (I hope). Perhaps a better solution is to either a) always order ipfw rule addition, or b) insert a rule '1' that denies all packets, install the rest of the rules, then remove this rule '1' when the rest of the rules modifying the policy are in place. While the current behavior is perfectly consistent, it might catch new users by surprise, as it is a non-obvious source of vulnerability. Robert N Watson Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.981104113649.29377C-100000>