From owner-freebsd-security Mon Dec 4 17:22: 3 2000 From owner-freebsd-security@FreeBSD.ORG Mon Dec 4 17:22:01 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from secure.smtp.email.msn.com (cpimssmtpu07.email.msn.com [207.46.181.28]) by hub.freebsd.org (Postfix) with ESMTP id 1E7B537B401 for ; Mon, 4 Dec 2000 17:22:01 -0800 (PST) Received: from x86nts4 - 216.103.48.12 by email.msn.com with Microsoft SMTPSVC; Mon, 4 Dec 2000 17:22:00 -0800 Message-ID: <011701c05e5a$bcfb3060$fd01a8c0@pacbell.net> From: "John Howie" To: "David G. Andersen" Cc: References: <200012050043.RAA27046@faith.cs.utah.edu> Subject: Re: Fw: NAPTHA Advisory Updated - BindView RAZOR Date: Mon, 4 Dec 2000 17:28:57 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1800 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org David Andersen wrote: > This isn't a FreeBSD failure per se, but a resource control > failure. Whether you want to point a finger at FreeBSD, ssh, or the > operator of the box is entirely up to you. :-) > 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). > > > ------------------------------------------- > > > > > > FreeBSD - FreeBSD 4.0-REL > > > > > > In testing FreeBSD, a few specific > > > daemons/ports were targeted. For some, the > > > stability of the system as a whole can be > > > affected. The daemons targeted in this > > > testing are not necessarily at fault for > > > the problems encountered. > > > > > > SSH: > > > Became unusable after 495 connections to > > > the ssh port. Each connection started an > > > instance of the daemon which quickly > > > exhausted available file handles; the > > > system reports "too many open files in > > > system". After approximately 30 minutes > > > the connections start timing out and the > > > system becomes usable again. > > > > > > 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. > > > > > > 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. > > > > > > Note: These services/ports can be > > > similarly affected on other Linux and UNIX > > > variants. > > > > > > ------------------------------------------- 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. Note that the tone of the report seems to imply that this kind of attack is new, it is not. It has been around for some time but not widely employed. All it took was for someone 'not in the know' to re-discover and publicize how the attack could be carried out without crippling the attacker's machine 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. john... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message