Bug 45846 - Fork bomb exploit not prevented by user limits
Summary: Fork bomb exploit not prevented by user limits
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 8.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-06-25 17:14 UTC by Chris Travers
Modified: 2008-08-01 16:22 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-09-30 15:39:02 UTC
Embargoed:


Attachments (Terms of Use)

Description Chris Travers 2001-06-25 17:14:29 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9)
Gecko/20010505

Description of problem:
The following code will cause Linux to hang--

#include <sys/types.h>
#include <unistd.h>

int main (){
    while (1) fork ();
    return (0);
}

This will exhaust the process table.

How reproducible:
Always

Steps to Reproduce:
1. write the following program as DoS.c:
#include <sys/types.h>
#include <unistd.h>

int main (){
while (1) fork ();
return (0);
}

2. compile using gcc -oDoS DoS.c

3. Run ./DoS
	

Actual Results:  X hangs, Apache won't server pages, ssh won't accept new
connections, new users cannot log in, existing users cannot execute most
shell commands.  Top hangs, and when DoS is suspended, a look at the Proc
file system indicates that well over 2000 processes are running (top won't
list it because it contains too many processes).


Expected Results:  System might slow down but it should not be possible for
an unprivaleged user to lock up the system with a malicious program.


Additional info:


Also, memory limitations per user might be harder to impliment but might be
helpful too(think of using malloc in the previous program!).

Comment 1 Ed McKenzie 2001-06-27 02:56:13 UTC
Kernel RSS limits aren't yet implemented, but better pam defaults for users is a
good idea.  I think RH has the opportunity to take the lead here. :)

BTW, the reason top won't display 2000 processes is because /proc has pretty
severe performance issues when more than 10-20 processes are running.  Normally,
ps is pretty slow as compared to *BSD, but if you have many processes running,
it'll slow down to about two or three PIDs per second. :-/

Comment 2 Alan Cox 2002-12-18 13:54:06 UTC
Later Linux does per user total process limiting. However I'm leaving this open
as one of my test sets I see a kernel hang for some other reason. Also to remind
us that eventually we need to get the O(1) scheduler updated to do fair share
(fair share means that each user gets a share of the CPU not each task, so the
more you
fork the less time *your* processes get not everyones)

Alan


Comment 3 Bugzilla owner 2004-09-30 15:39:02 UTC
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
persists.

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/



Note You need to log in before you can comment on or make changes to this bug.