From owner-freebsd-security Mon Dec 4 17:38:23 2000 From owner-freebsd-security@FreeBSD.ORG Mon Dec 4 17:38:19 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from faith.cs.utah.edu (faith.cs.utah.edu [155.99.198.108]) by hub.freebsd.org (Postfix) with ESMTP id 9170037B401 for ; Mon, 4 Dec 2000 17:38:18 -0800 (PST) Received: (from danderse@localhost) by faith.cs.utah.edu (8.9.3/8.9.3) id SAA03007; Mon, 4 Dec 2000 18:38:15 -0700 (MST) Message-Id: <200012050138.SAA03007@faith.cs.utah.edu> Subject: Re: [spam score 10.00/10.0 -pobox] Re: Fw: NAPTHA Advisory Updated - BindView RAZOR To: JHowie@msn.com (John Howie) Date: Mon, 4 Dec 2000 18:38:15 -0700 (MST) Cc: dga@pobox.com (David G. Andersen), freebsd-security@FreeBSD.ORG In-Reply-To: <011701c05e5a$bcfb3060$fd01a8c0@pacbell.net> from "John Howie" at Dec 04, 2000 05:28:57 PM From: "David G. Andersen" X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: danderse@cs.utah.edu Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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