[11941] in bugtraq
socket buffer DoS/administrative limits (fwd)
daemon@ATHENA.MIT.EDU (Brian F. Feldman)
Fri Sep 17 16:33:31 1999
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-Id: <Pine.BSF.4.10.9909171235380.64357-100000@janus.syracuse.net>
Date: Fri, 17 Sep 1999 12:35:50 -0400
Reply-To: "Brian F. Feldman" <green@FREEBSD.ORG>
From: "Brian F. Feldman" <green@FREEBSD.ORG>
X-To: bugtraq@securityfocus.com
To: BUGTRAQ@SECURITYFOCUS.COM
---------- Forwarded message ----------
Date: Fri, 17 Sep 1999 12:32:01 -0400 (EDT)
From: Brian F. Feldman <green@FreeBSD.ORG>
To: hackers@FreeBSD.ORG
Subject: socket buffer DoS/administrative limits
Yes folks, it's that time again: time for more administrative limits!
I've worked out a resource limit (for FreeBSD in this case, but not
non-portable) which allows prevention of DoS by mbuf starvation. Others
are working on making the networking code more resilient, while this is
a general resource limit which can be used in any case.
I've chosen the name "sbsize" (RLIMIT_SBSIZE) for this. Here's what
happens with the limit in action (note that the pdksh in use has been
patched to include the ulimit):
{"/home/green"}$ ulimit -b 2000000 ; ulimit -a | grep sbsize
sbsize(bytes) 2000000
{"/home/green"}$ ./testsockbuf
socketpair: No buffer space available
14 sockets had been allocated
And another DoS attempt has been foiled with administrative limits :)
I'm sorry for not having something working sooner, but I ran into the problem
of my KASSERT() being tripped, which ended up being caused by me not
grokking an evil local define (look for "#define (snd|rcv) "...) correctly.
After fixing that, everything is wonderful.
The patch, which applies to FreeBSD 4.0-CURRENT, and should be easily
portable or backportable, can be found at:
http://www.FreeBSD.org/~green/sbsize4.patch
--
Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! /
green@FreeBSD.org `------------------------------'
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
