From Wikipedia, the free encyclopedia

Concept behind the fork bomb, the processes are recursively forked until a denial of service or a crash

The fork bomb is a form of denial of service attack against a computer system that implements the fork operation, or equivalent functionality whereby a running process can create another running process. It is considered a wabbit as fork bomb programs typically do not spread as worms or viruses. It relies on the assumption that the number of programs and processes which may be simultaneously executed on a computer has a limit.

A fork bomb works by creating a large number of processes very quickly in order to saturate the available space in the list of processes kept by the computer's operating system. If the process table becomes saturated, no new programs may be started until another terminates. Even if that happens, it is not likely that a useful program may be started since the instances of the bomb program are each waiting to take that slot themselves.

Not only do fork bombs use space in the process table, they each use processor time and memory. As a result of this, the system and existing programs slow down and become much more difficult (slow), or even impossible, to use.

Canonical forkbombs include this one on Unix (Explanation):

:(){ :|:& };:

Or in Microsoft Windows using a batch file:

:s
start %0
goto s

Or using Perl:

(forking using the Perl interpreter):
 perl -e "fork while fork" &

Or in C:

#include 

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

Once a successful fork bomb has been activated in a system it may not be possible to resume normal operation without rebooting, as the only solution to a fork bomb is to destroy all instances of it. Trying to use a program to kill the rogue processes normally requires another process be created, which may not be possible if there are no empty slots in the process table, or space in memory structures.

One way to prevent a fork bomb is to limit the number of processes that a single user may own. When a process tries to create another process and the owner of that process already owns more than the maximum, the creation fails. The maximum should be low enough that if all the users who might simultaneously bomb a system do, there are still enough resources left to avoid disaster. Note that an accidental fork bomb is highly unlikely to involve more than one user.

Unix-type systems typically have such a limit, controlled by a ulimit shell command. With a Linux kernel, it is the RLIMIT_NPROC rlimit of a process. If a process tries to perform a fork and the user that owns that process already owns more than RLIMIT_NPROC processes, it fails.

Note that simply limiting the number of processes a process may create does not prevent a fork bomb, because each process that the fork bomb creates also creates processes. A distributive resource allocation system in which a process' resources are a share of its parents resources would work, but distributive resource systems are not in common use.

Another solution involves the detection of fork bombs by the operating system, which is not widely practiced although has been implemented in the form of a kernel module for the Linux kernel [1].

Even with the above precautions, fork bombs can still have disastrous effects on a system. For example, if a server has 24 CPUs and allows ordinary users to have up to 100 processes, a fork bomb can still saturate all 24 CPUs even after it can no longer multiply. This can make the system completely unresponsive, to the point where an admin cannot log in to fix the problem.

• Definition of 'fork bomb' in the Jargon File