Fork bomb: Difference between revisions
→Defusing: {{Section OR|date=October 2012}} |
→Defusing: re-removing section as original research (see talk page) |
||
| Line 17: | Line 17: | ||
[[Microsoft Windows]] operating systems do not have equivalent functionality to the Unix fork system call;<ref>{{cite book |first=Mark |last=Hammond |year=2000 |page=35 |title=Python Programming On Win32: Help for Windows Programmers |isbn=1565926218}}</ref> a fork bomb on such an operating system must therefore create a new process instead of forking from an existing one. |
[[Microsoft Windows]] operating systems do not have equivalent functionality to the Unix fork system call;<ref>{{cite book |first=Mark |last=Hammond |year=2000 |page=35 |title=Python Programming On Win32: Help for Windows Programmers |isbn=1565926218}}</ref> a fork bomb on such an operating system must therefore create a new process instead of forking from an existing one. |
||
== Defusing == |
|||
{{Section OR|date=October 2012}} |
|||
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 shell fork bomb shown below: |
|||
<source lang="bash"> |
|||
:(){ :|: & };: |
|||
</source> |
|||
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{{Citation needed|date=November 2010}}: |
|||
<source lang="bash"> |
|||
while (sleep 100 &) do; done |
|||
</source> |
|||
Alternatively, stopping (“freezing”) the bomb's processes can be used so that a subsequent [[kill (command)|kill]]/[[killall]] can terminate them without any of the parts re-replicating due to newly available process slots: |
|||
<source lang="bash"> |
|||
killall -STOP processWithBombName |
|||
killall -KILL processWithBombName |
|||
</source> |
|||
When a system is low on free [[Process identifier|PID]]s (in Linux the maximum number of pids can be obtained from /proc/sys/kernel/pid_max), defusing a fork bomb becomes more difficult: |
|||
<source lang="bash"> |
|||
$ killall -9 processWithBombName |
|||
bash: fork: Cannot allocate memory |
|||
</source> |
|||
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. |
|||
Why not exec killall -9 directly from the shell? Because killall 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: |
|||
<source lang="bash"> |
|||
while :; do killall -9 processWithBombName; done |
|||
</source> |
|||
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. |
|||
<source lang="bash"> |
|||
cd /proc; |
|||
for p in [0-9]*; do read CMDLINE < $p/cmdline; if [[ $CMDLINE == "processWithBombName" ]]; then kill -s SIGSTOP $p; fi; done |
|||
for p in [0-9]*; do read CMDLINE < $p/cmdline; if [[ $CMDLINE == "processWithBombName" ]]; then kill -s SIGKILL $p; fi; done |
|||
</source> |
|||
== Prevention == |
== Prevention == |
||
Revision as of 15:01, 2 November 2012
In computing, a fork bomb is a denial-of-service attack whereby a process continually replicates itself to deplete available system resources.
Implementation
Fork bombs operate both by consuming CPU time in the process of forking, and by saturating the operating system's process table.[1][2] A basic implementation of a fork bomb takes the following form:
set running to true
while running is true
create copy of running process
end
In Unix-like operating systems, fork bombs are generally written to use the fork system call.[2] 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,[3] a fork bomb generally will not saturate such a system's memory.
Microsoft Windows operating systems do not have equivalent functionality to the Unix fork system call;[4] a fork bomb on such an operating system must therefore create a new process instead of forking from an existing one.
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 amount of processes that a single user may own. On Linux, this can be achieved by using the ulimit utility; for example, the command ulimit -Hu 30 would limit the affected user to a maximum of thirty owned processes.[5] On PAM-enabled systems, this limit can also be set in /etc/security/limits.conf,[6] and on FreeBSD, the system administrator can put limits in /etc/login.conf.[7]
See also
References
- ^ Ye, Nong (2008). Secure Computer and Network Systems: Modeling, Analysis and Design. p. 16. ISBN 0470023244.
- ^ a b Jielin, Dong (2007). Network Dictionary. p. 200. ISBN 1602670005.
- ^ Dhamdhere, D. M. (2006). Operating Systems: A Concept-based Approach. p. 285. ISBN 0070611947.
- ^ Hammond, Mark (2000). Python Programming On Win32: Help for Windows Programmers. p. 35. ISBN 1565926218.
- ^ Cooper, Mendel (2005). Advanced Bash Scripting Guide. pp. 305–306. ISBN 1430319305.
- ^ Soyinka, Wale (2012). Linux Administration: A Beginners Guide. pp. 364–365. ISBN 0071767592.
- ^ Lucas, Michael W. (2007). Absolute FreeBSD: The Complete Guide to FreeBSD. pp. 198–199. ISBN 1593271514.