LinuxSecurity.com
Share your story
The central voice for Linux and Open Source security news
Home News Topics Advisories HOWTOs Features Newsletters About Register

Welcome!
Sign up!
EnGarde Community
Login
Polls
What is the most important Linux security technology?
 
Advisories
Community
Linux Events
Linux User Groups
Link to Us
Security Center
Book Reviews
Security Dictionary
Security Tips
SELinux
White Papers
Featured Blogs
All About Linux
DanWalsh LiveJournal
Securitydistro
Latest Newsletters
Linux Security Week: April 21st, 2014
Linux Security Week: April 7th, 2014
Subscribe
LinuxSecurity Newsletters
E-mail:
Choose Lists:
About our Newsletters
RSS Feeds
Get the LinuxSecurity news you want faster with RSS
Powered By

  
Understand: Fork Bombing Attack Print E-mail
User Rating:      How can I rate this item?
Posted by Anand Jahagirdar   
Features Thanks to Anand Jahagirdar for this feature!

As the variety of attacks and threats grow, you need to be prepared. In this HOWTO, get a feeling for the Fork Bombing Attack, what it is, how it works, where it comes from, how to deal with it and more.

Fork Bombing:


Eckie S.

Fork bombing means invoking fork system call infinite times by one or more processes.
It is also defined as Spawning nearly infinite processes by one or more user processes.

E.g. Simple C Loop *: -
while (1) fork ();

It spawns infinite processes which in turn lead to fork bombing.

Fork bombing attack is usually done by a non root user. For example, a non root user, as
an attacker, sends infinite requests to the server for denial of service.

Another example of fork bombing attack is a simple loop

*: - main () {fork() main () ;}

In this case main function calls itself recursively. This loop can make the system crawl.

(* warning: - execute both the loop at your own risk).

Its Effects on the System (Servers) are as follows:

Fork bombing is a Denial of Service (DoS) attack. Infinite processes which are created,
consume a lot of system resources such as CPU time, memory etc and hence server or any
remote host becomes totally unresponsive. Server cannot respond to any other user after
undergoing fork bombing attack. It kills the box completely and machine needs a reboot.
And as we all know that on a server, a single reboot is very costly. It affects the whole
network. Fork bombing is considered as one of the serious attacks in the industry.

Present Solution to Prevent Fork Bombing attack is as follows: -

Linux has provided various resource limits for each user, such as user limit (Ulimit)
for CPU time, number of processes (nproc), memory usage etc. Ulimit is the solution to
prevent fork bombing attack. It defines maximum number of processes allowed (Ulimit u) for
each user.

There are two types of Ulimit. One is HARD limit and the other is SOFT Limit. Non root
user cannot change the hard limit by executing commands like Ulimit u value. But Soft
limits can be changed by executing this command. Hard limit and Soft limit are set by
administrator/root user in {mos_sb_discuss:13} security/limits.conf file. Soft limits can
be raised up to hard limit but they cannot go beyond that. Hard limit is the max limit
while soft limit is the min limit for a particular resource.

Number of user processes created by each user is compared with maximum number of user
processes allowed for that particular user. If that user is crossing his/her Soft process
limit, an Error is returned and he/she is not allowed to create more processes than its
Ulimit. It is desirable that present solution should warn administrator about user crossing
the process limit and trying fork bombing attack.

Actual Code to prevent fork bombing attack is in the file /usr/src/linux-2.6.x/kernel/fork.c.

In this file, the copy_process function compares the number of processes created by a non root user
with maximum number of processes allowed for him/her. If user is crossing the process limit, an error is
returned.

Comparative study of solutions provided by different distributions and Operating Systems
is as follows:

Red Hat, Suse and Ubuntu Linux Distributions provide same solution to prevent fork
bombing attack. They compare number of user processes created at run time with max user
process limit and if that limit is crossed, an error is returned and process creation is
prohibited for that user.

Debian Linux Distribution compares number of user processes created with max user limit
and if user is crossing the limit, an error is returned and all unnecessary processes are
killed.

Unlike Linux flavors, BSD variants provide somewhat different solution to prevent fork
bombing attack. It compares two variables namely nproc and maxproc. nproc is number of user
processes created by user and maxproc = 20 + 16 * MAXUSER. MAXUSER is global variable.

If particular user is creating more processes than maxproc 5 or maxproc, BSD returns
an error and alerts administrator about user crossing process limit. BSD keeps 5 processes
for root user. BSD doesn't allow that particular user to create more processes than maxproc
- 5.

Present Scenario:

Most of the Linux distributions with default settings suffer from fork bombing attack.
In almost all default Linux distributions like Red Hat, Suse, Ubuntu, Ulimit (Max user
limit) is same for both root and non root user. For example in Fedora Core 4, Ulimit u
executed on command prompt will show 3055 for both root and non root user. For Fedora Core
6 Ulimit u will show 8055 for both root and non root user.

In both cases hard and soft limit are same. Just simple C program: - while (1) fork ();
executed on most of the Linux distributions with default settings takes down the machine.

{mos_sb_discuss:13}

Administrator responsibility:-

Root/administrator user on remote server or Host needs to set the Ulimit to prevent fork
bombing attack. Ulimit are set in /etc/security/limits.conf file. To set Ulimit for
number of processes, option provided is nproc. Hard and soft limit need to be set for that.

For example:

@root nproc hard 5000
@root nproc soft 4000
@anand nproc hard 2000
@anand nproc soft 1000

These settings in /etc/security/limits.conf file definitely prevent fork bombing attack.
It is always suggested that number of non root user processes should always be less than
root user.

Ulimit can be set for groups also.

For example:

@root nproc hard 5000
@root nproc soft 4000
@students nproc hard 2000
@students nproc soft 1000

In this case students group have hard Ulimit as 2000 and soft Ulimit as 1000.

Problems with present solution: -

There are certain problems with the present solution of fork bombing attack.

For example if any non root user has more process limits than root user, and if

that user does fork bombing attack it will kill the box. If following values are set in

/etc/security/limits.conf file as per user need.

@root nproc hard 5000
@root nproc soft 3000
@anand nproc hard 6000
@anand nproc soft 4000

And if non root user (anand) does fork bombing attack, it will take down the machine completely.

Even if root user and non root user have same process limits and if non root user does
fork bombing attack he will be successful.

Consider another case: if two users having Ulimit as 5000 each and {mos_sb_discuss:13} root has

Ulimit as 6000 then in that case, if those two users do fork bombing attack at
the same time, it will kill the box completely.

The administrator has to be very wary about the process limits that he/she is setting
for each user. If user is not trusted enough he/she may misuse the limits as discussed
above.

In one rare case, if an attacker gets root privileges and if he does fork bombing
attack on remote machine, he will be successful. Because kernel won't check Ulimit for
root user, limits are checked only for non root user. If attacker gets root privileges he
could do much more damaging things rather than doing fork bombing attack.

Finally I would like to conclude that Ulimit is really a good solution to prevent
fork bombing. In fact it prevents most of the fork bombing attacks, but it's not a complete
solution. I think a more improved solution to prevent fork bombing attack and to overcome
the problems related with present solution is needed. Solution provided by BSD operating
system should also be considered.

Acknowledgement: -

I am very thankful to Mr. Kedar Sovani and Mr. Chirag Jog for their support and guidance, which they have

provided me at various stages.

Comments
comparison of root and user limitsWritten by jrsmeets on 2007-09-08 03:03:44
Dear Anand, 
 
please explain why the root limit has to be greater than the user limit. 
 
The user limit should be such that the total of user processes should not be large enough to bring down a machine. This has nothing to do with the number of processes that root can run. 
 
Furthermore suppose you try out with your example script how much processes a machine can handle. Does this give you a good hint as to how high the ulimit should be? Seems to me that the process size is also an issue. Meaning that the ulimit on memory should also be considered. 
 
/Rob Smeets 
Comparison of root and user limitsWritten by anand.jahagirdar on 2007-09-13 02:41:16
Hi Rob, 
I agree with you. according to logic implemented to prevent fork bombing attack it is "Not Necessary" for root user to have greater number processes than other user, 
Beacause preventive code is checking for individual ulimits with total number user processes created by that particluar user at run time.  
according my observetions which i have mentioned in my article, i will "Suggest" it is "Always Better" for root user to have greater number of processes than other user.  
 
Anand

Only registered users can write comments.
Please login or register.

Powered by AkoComment!

 
< Prev   Next >
    
Partner

 

Latest Features
Peter Smith Releases Linux Network Security Online
Securing a Linux Web Server
Password guessing with Medusa 2.0
Password guessing as an attack vector
Squid and Digest Authentication
Squid and Basic Authentication
Demystifying the Chinese Hacking Industry: Earning 6 Million a Night
Free Online security course (LearnSIA) - A Call for Help
What You Need to Know About Linux Rootkits
Review: A Practical Guide to Fedora and Red Hat Enterprise Linux - Fifth Edition
Yesterday's Edition
Partner Sponsor

Community | HOWTOs | Blogs | Features | Book Reviews | Networking
 Security Projects |  Latest News |  Newsletters |  SELinux |  Privacy |  Home
 Hardening |   About Us |   Advertise |   Legal Notice |   RSS |   Guardian Digital
(c)Copyright 2014 Guardian Digital, Inc. All rights reserved.