Date: Thu, 5 Nov 1998 08:52:50 -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 Part 2. Message-ID: <Pine.BSF.3.96.981105082421.4653A-100000@fledge.watson.org> In-Reply-To: <Pine.BSF.4.02.9811050419420.26130-100000@orion.webspan.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 5 Nov 1998, Open Systems Networking wrote:
> "seeing how /etc/rc.firewall is a shell script, it is reasonable to assume
> that most ruleset will include small raceable sections where some packets
> that should be denied will not be. I kludged as bellow:
>
> put a '$fwcmd add 1 deny all from any to any' as the first rule and moved
> the flush command to one line above it.
>
> put a '$fwcmd delete 1' right after my 65534 deny all.
>
> This should cut the available time for races down substantially. I've seen
> packets hit the temporary rule but have never seen a magic packet that
> made it too the last."
Chris,
This is indeed what I had in mind, and it does substantially narrow the
window of vulnerability. However, it seems to me after a quick perusal of
the /etc/rc* files that it is probably still preferable to have a default
deny policy than to use this kludge. There are in fact two different
variations on the race attack to be considered:
1) The default policy is 'accept'
and
2) The default polic is 'deny' but the rules are added out of order
The problem with 1) is that it is possible programs will be loaded in
earlier portions of rc.* that might bind network ports prior to the
initialization of ipfw. That is, there is a window between the ifconfig
portion of rc.network in pass1 and the ipfw behavior -- and if you have
ipfw as a loadable kernel module, that might actually be a large window
with a debugging kernel due to the linking time. Both rc.serial and
rc.pccard run prior to that point (in my rc.* as of some revision of 3.0
from the past month or so). The default rc.* files seems to be fairly
well arranged, although I have found one possible vulnerable program:
rc.pccard is run prior to the ipfw rules. rc.pccard runs pccardd, which
in turn will run other programs when cards are inserted/discovered. One
such program is the ISC dhclient if DHCP is used to configure the machine.
If ipfw requires a long link time for lkm loading, then pccardd may
successfully discover the card before ipfw has been loaded into the
kernel. If there is a vulnerability in dhclient (or something else run by
pccardd) that your ipfw rules would normally protect you from, then *there
is a dangerous window*.
Picture:
rc.pccard runs
pccardd starts
rc.firewall runs
ipfw.o lkm begins to link
into kernel
pccard probes card, runs dhclient
packet arrives, buffer overflow in
dhclient gives root access
ipfw.o finishes loading
ipfw installs rule to protect
against bad packet
Needless to say, probably the best fix here is to use the default rule of
deny. BTW, another possible nasty is as follows: suppose you have your
pccard.conf set up so that it inserts some ipfw rules when a new network
interface is found. If this code runs prior to or during the normal ipfw
startup, then the rules may not reflect your intent, as *they may be
loaded out of order*. This vulnerability applies *even if your default
rule is deny*.
Picture
rc.firewall runs
ipfw.o lkm begins to link
into kernel
pccard probes card, runs ipfw
to allow stuff on the new interface
that assumes rc.firewall has run
to install existing rules
bad packet arrives doing nasty
things to dhclient or some other
pccardd program
ipfw.o finishes loading
ipfw installs rule to protect
against bad packet
In this case, you have to assume that the ipfw rules from either pccardd
or from rc.firewall *may be installed in any order* so must be idempotent
:).
In general, the rc.* files seem carefully arranged to forstall the
execution of potentially vulnerable code prior to the ipfw rule
installation. Clearly, local modifications might circumvent that -- as
does the implicit code execution in pccardd that seems to have been
overlooked.
The problem with 2) is that even if the policy is 'deny' by default, the
ipfw command ordering may weaken the policy for a short window during the
installation of the policy. The ipfw rule 1 workaround you posted handles
this just fine (assuming you avoid any other rule number'd 1). One would
of course need to be careful to document that people must *never* use rule
1, or they might end up with the same problem depending on how multiple
rules with the same number are handled.
So here is another question for those that are more familiar with the
kernel IP code. I am concerned about queueing of packets. It is my
belief that (probably) as long as no daemons are yet listening on any
ports at the ipfw rule installation, then any packets that slip through
the rules due to bad ordering or a default policy of 'accept' will in fact
be dropped because they are unneeded, and will be processed immediatly: if
they have made it to the point where ipfw considers them, they are high
enough in the stack that they will be rejected prior to any process
execution that might involve loading a program to accept them? I think we
are fine, but would like some confirmation of this thought :). The attack
I consider is essentially this:
rc.firewall runs
first few ipfw rules run
packet arrives, is accepted by ipfw
rest of ipfw rules go in
daemon runs
packet is grabbed by daemon for its port
This also matters for the pccard case I describe above where the rule
ordering is munged by the pccardd running ipfw for an inserted interface.
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.981105082421.4653A-100000>