Date: Mon, 4 Dec 2000 18:38:15 -0700 (MST) From: "David G. Andersen" <dga@pobox.com> To: JHowie@msn.com (John Howie) Cc: dga@pobox.com (David G. Andersen), freebsd-security@FreeBSD.ORG Subject: Re: [spam score 10.00/10.0 -pobox] Re: Fw: NAPTHA Advisory Updated - BindView RAZOR Message-ID: <200012050138.SAA03007@faith.cs.utah.edu> In-Reply-To: <011701c05e5a$bcfb3060$fd01a8c0@pacbell.net> from "John Howie" at Dec 04, 2000 05:28:57 PM
next in thread | previous in thread | raw e-mail | index | archive | help
Lo and behold, John Howie once said:
>
> I'm afraid I disagree - this is not purely a daemon problem. I wonder if you
> had time to read the whole advisory for the FreeBSD information near the end
> of the report (I've included it below).
> > > > affected. The daemons targeted in this
> > > > testing are not necessarily at fault for
> > > > the problems encountered.
That's where there may be some disagreement. I personally feel that a
base system should provide more resource isolation between daemons than
FreeBSD, Linux, and most other operating systems do, but that's a matter
of opinion. ;-)
> > > > NFS:
> > > > Stopped functioning after 964 packets to
> > > > the NFS port. While the rest of the system
> > > > did not seem affected, the connections did
> > > > not time out.
This is the same problem as with SSH.
> > > > BIND:
> > > > Took 961 TCP connections before the kernel
> > > > reported "file table is full", and TCP
> > > > services failed. UDP DNS seemed
> > > > unaffected. These connections look a long
> > > > time to time out, at least an hour.
Unsurprising that UDP DNS was unaffected. There's no way for an
attacker to connect and say, "Oh, hang on, I'll send you the rest of that
in a bit."
> If a daemon becomes unusable because it is subject to attack then that is,
> while not ideal, at least tolerable. When the whole system becomes unusable
> that points to problems in the kernel.
Nope. It wasn't a kernel problem you were encountering - it was a
systemwide resource limit being reached. It's not that there's a _bug_ in
the kernel, it's that the processes file table limits weren't isolated
from each other. The right solution to this is more isolation of
different processes (e.g. resource control).
Like I said above: This isn't a bug in the sense of "a bad
implementation" so much as a question of how the resource control can be
done. As the advisory itself points out, this can be fixed by:
a) Fixing the daemons to rate- and connection-limit themselves.
b) Using tcpwrappers to do the above
c) Providing a general, happy OS mechanism to provide resource
controls at a fine granularity between applications.
You can probably figure out which of these I think is the best
solution, but just in case, I'll give you a hint: (c). Not many
operating systems do this these days; see the maybe-about-to-be-released
Flask kernel (NSA/TIS) for an example of a great way to do it.
Of course, the problem is really more interesting than I've let on to so
far: What one _really_ wants to do is start rate-limiting some clients
without affecting the others (e.g. at an OS level, I can easily protect
NFS from SSH, but I want to protect good web clients from the
bad). That's where both RW's stuff and some networks research comes
in; either use less state and be better about cleaning up (RW), or
automatically stuff the "bad" clients in separate resource containers
(see "Resource Containers" by Pai et al. at Rice). I don't propose that
this is a functioning solution yet.
> too. I first came across this kind of attack in 1991 and I am sure that it
> has been demonstrated in practice long before that.
Of course. It's just slicker version of:
while (1)
telnet www.foo.org 80 > /dev/null &
... I probably needn't bother pointing out that:
a) It could be made better (exercise left to the reader;
please don't.)
b) It's fairly easy to detect and defend against a particular
attacker because it requires the use of identifiable and
relatively static IP addresses (blocking a few /16s would
likely fix any given victim's problems for a while)
The same problem has been seen before:
- Syn floods
- IP Fragmentation attacks (jolt)
- ...
I kinda like this one because it takes the attacks back into the arena
where it affects actual servers (a more sophisticated attack could, for
instance, cause a server to allocate even more resources; with sendmail,
for instance, you might get more memory waste if you start sending
a the DATA portion and then hang the connection, and so on). It's a nice
reminder that the applications matter as well as the OS.
-Dave
--
work: dga@lcs.mit.edu me: dga@pobox.com
MIT Laboratory for Computer Science http://www.angio.net/
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?200012050138.SAA03007>