[2448] in bugtraq
Re: fork()
daemon@ATHENA.MIT.EDU (JaDe)
Tue Dec 12 13:30:52 1995
Date: Mon, 11 Dec 1995 10:08:32 -0800
Reply-To: Bugtraq List <BUGTRAQ@CRIMELAB.COM>
From: JaDe <jadestar@NETCOM.COM>
X-To: BUGTRAQ@CRIMELAB.COM
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@CRIMELAB.COM>
In-Reply-To: <Pine.SOL.3.91.951210104255.28802A-100000@clark.net> from "Alex
Leipold" at Dec 10, 95 10:45:37 am
>
> O'm new to the list, so Im not sure if this has been covered, but someone
> can crash any system with a few lines of code. (tested on UNIX, LINUX)
>
<!-- # classic fork bomb elided -->
Actually this usually won't *crash* a Linux box. Usually
it will just make the system comatose-level unresponsive for
a few minutes (until the fork bomp exceeds the user's process
allotment and gets killed).
I've heard that most Unix kernels can be "tuned" (compiled with
specific options) to be much more restrictive on user space
processes -- to prevent this.
I haven't see that covered here un bugtraq -- though I
expect everyone on this list as heard of it and most have
evaluated their system's behaviour when faced with a running
fork bomb (better the sysadmin should crash the machine
intentionally -- right after a backup -- than that he/she should
suddenly get broad-sided).
Clearly this is a denial of service attack that requires shell
access. The general unix security philosophy is that a
sysadmin can't prevent DOS attacks by shell users (without
severely limiting their effective work).
So if you have a user community that might take this sort
of inexcusably anti-social action -- don't issue shell, telnet,
or rlogin/rsh/rexec privileges to them. (And don't think you
can just remove the c compiler to limit this -- PERL and the
shell scripting languages themselves are more than adequate to
mount this attack).
