Date: Sat, 23 Nov 2002 22:50:01 -0800 From: David Schultz <dschultz@uclink.Berkeley.EDU> To: Sheldon Hearn <sheldonh@starjuice.net> Cc: Mike Silbersack <silby@silby.com>, "David G. Andersen" <danderse@cs.utah.edu>, freebsd-security@FreeBSD.ORG Subject: Re: File table exhaustion patch Message-ID: <20021124065001.GA2683@HAL9000.homeunix.com> In-Reply-To: <20021122080515.GQ36738@starjuice.net> References: <20021121105204.B75421@cs.utah.edu> <20021121152539.U44884-100000@patrocles.silby.com> <20021122080515.GQ36738@starjuice.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Thus spake Sheldon Hearn <sheldonh@starjuice.net>: > On (2002/11/21 15:29), Mike Silbersack wrote: > > > HOWEVER, we're in a code freeze leading up to 5.0-release, and local DoSes > > aren't a critical bug. > > Is that the official FreeBSD SO team viewpoint on local DoS > vulnerabilities? DoS attacks are incredibly hard to address in general, and I have yet to see a multiuser system that isn't vulnerable to at least several of them. Given that FreeBSD has always been ``vulnerable'' to file table exhaustion, waiting a few weeks isn't going to be the end of the world[1]. My favorite example of a local DoS attack is: while (1) mkdir t && cd t I ``discovered'' this one about a year ago, then found that Dennis Ritchie had pointed it out in the early 1970's. It reliably crashes most systems, often causing massive filesystem corruption. Until someone fixes the scores of known DoS attacks that already exist, I'm not willing to consider any particular attack to be high-priority. [1] These days, the size limit on the file table is administrative anyway, since the table is a hash table. Of course, it doesn't auto-resize if you grow it by an order of magnitude at runtime. 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?20021124065001.GA2683>