thumb|upright=1.3|right|The concept behind a fork bomb – the processes continually replicate themselves, potentially causing a denial of service

In computing, a fork bomb (also called rabbit virus or hydra virus) is a denial-of-service (DoS) attack wherein a process continually replicates itself to deplete available system resources, slowing down or crashing the system due to resource starvation.

History

Around 1978, an early variant of a fork bomb called wabbit was reported to run on a System/360. It may have descended from a similar attack called RABBITS reported from 1969 on a Burroughs 5500 at the University of Washington.

Since 2011 Linux has a default nproc limit that can be listed with ulimit -u to mitigate fork bombs and related issues.

Implementation

thumb|Demonstration of a fork bomb in [[Arch Linux]]

Fork bombs operate both by consuming CPU time in the process of forking, and by saturating the operating system's process table. A basic implementation of a fork bomb is an infinite loop that repeatedly launches new copies of itself.

In Unix-like operating systems, fork bombs are generally written to use the fork system call. a fork bomb generally will not saturate such a system's memory.

Microsoft Windows operating systems do not have an equivalent functionality to the Unix fork system call; a fork bomb on such an operating system must therefore create a new process instead of forking from an existing one, such as with batch <code>echo %0^|%0 > $_.cmd & $_</code>. In this batch script, <code>%0|%0</code> is written to <code>$_.cmd</code>, which is then executed by <code>& $_</code>.

A classic example of a fork bomb is one written in Unix shell <code>:(){ :|:& };:</code>, dating back to at least 1999, which can be more easily understood as

<syntaxhighlight lang="shell">

fork() {

fork | fork &

}

fork

</syntaxhighlight>

In it, a function is defined (<code>fork()</code>) as calling itself (<code>fork</code>), then piping (<code>|</code>) its result into itself, all in a background job (<code>&</code>).

The code using a colon <code>:</code> as the function name is not valid in a shell as defined by POSIX, which only permits alphanumeric characters and underscores in function names. However, its usage is allowed in GNU Bash as an extension.

The traditional C implementation (using the POSIX headers) is:

<syntaxhighlight lang="c">

  1. include <unistd.h>

int main() {

while (true) {

fork();

}

}

</syntaxhighlight>

This repeatedly calls the <code>fork()</code> function, duplicating the current process, in the header unistd.h|. Various forms of such a fork bomb have been created.

Prevention

As a fork bomb's mode of operation is entirely encapsulated by creating new processes, one way of preventing a fork bomb from severely affecting the entire system is to limit the maximum number of processes that a single user may own. On Linux, this can be achieved by using the ulimit utility; for example, the command <code>ulimit -u 30</code> would limit the affected user to a maximum of thirty owned processes.

On PAM-enabled systems, this limit can also be set in <code>/etc/security/limits.conf</code>,

and on *BSD, the system administrator can put limits in <code>/etc/login.conf</code>.

Modern Linux systems also allow finer-grained fork bomb prevention through cgroups and process number (PID) controllers.

See also

  • Zip bomb
  • Billion laughs attack
  • Deadlock (computer science)
  • Logic bomb
  • Time bomb (software)
  • ReDoS
  • Denial-of-service attack

References