Fork bomb
Template:Short description Template:Redirect Template:Use mdy dates
In computing, a fork bomb (also called rabbit 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.
HistoryEdit
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.<ref name="wabbit">{{#invoke:citation/CS1|citation |CitationClass=web }}</ref>
ImplementationEdit
Fork bombs operate both by consuming CPU time in the process of forking, and by saturating the operating system's process table.<ref>Template:Cite book</ref><ref name="network-dictionary-200">Template:Cite book</ref> 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.<ref name="network-dictionary-200" /> As forked processes are also copies of the first program, once they resume execution from the next address at the frame pointer, they continue forking endlessly within their own copy of the same infinite loop. this has the effect of causing an exponential growth in processes. As modern Unix systems generally use a copy-on-write resource management technique when forking new processes,<ref>Template:Cite book</ref> 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;<ref>Template:Cite book</ref> 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 Template:AnchorTemplate:Anchorecho %0^|%0 > $_.cmd & $_
. In this batch script, %0|%0
is written to $_.cmd
, which is then executed by & $_
.<ref>Template:Cite AV media</ref>
A classic example of a fork bomb is one written in Unix shell Template:AnchorTemplate:AnchorTemplate:AnchorTemplate:AnchorTemplate:Anchor:(){ :|:& };:
, possibly dating back to 1999,<ref>Template:Cite newsgroup</ref> which can be more easily understood as
<syntaxhighlight lang="shell">
fork() {
fork | fork &
}
fork
</syntaxhighlight>
In it, a function is defined (fork()
) as calling itself (fork
), then piping (|
) its result into itself, all in a background job (&
).
The code using a colon :
as the function name is not valid in a shell as defined by POSIX, which only permits alphanumeric characters and underscores in function names.<ref>{{#invoke:citation/CS1|citation
|CitationClass=web
}}</ref> However, its usage is allowed in GNU Bash as an extension.<ref>{{#invoke:citation/CS1|citation
|CitationClass=web
}}</ref>
PreventionEdit
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.<ref>Template:Cite book</ref>
On PAM-enabled systems, this limit can also be set in /etc/security/limits.conf
,<ref>Template:Cite book</ref>
and on *BSD, the system administrator can put limits in /etc/login.conf
.<ref>Template:Cite book</ref>
Modern Linux systems also allow finer-grained fork bomb prevention through cgroups and process number (PID) controllers.<ref>{{#invoke:citation/CS1|citation
|CitationClass=web
}}</ref>