fork-bomb is a malicious or mistakenly written program that creates its copies endlessly (using the fork () system call), which usually also begin to create their own copies, etc.
The execution of such a program can cause a large load on the computing system or even a denial of service due to a lack of system resources (process descriptors, memory, processor time), which is the goal.
The classic fork bomb program (written in C ) looks like this:
#include <unistd.h>
int main ()
{
while ( 1 )
fork ();
}
Similar cases of leaking system resources are programs that generate zombies and orphan processes . However, if most fork bombs are intentionally created, then these problems are usually the result of a programmer’s carelessness or incompetence.
Content
Description
The fork bomb generates a large number of its own copies and thereby tries to fill the free space in the list of active processes of the operating system . After filling out the list of processes, it becomes impossible to start a useful program. Even if any other process stops working and the place in the list of processes becomes free, the start of a useful program is unlikely, since many other copies of the fork bomb are already waiting for the opportunity to launch their next copy.
In addition to filling out the list of processes, strategies for filling virtual memory, processor time, sockets, and other system resources are also possible. Exhaustion of these resources results in a slowdown or practically shutdown of the operating system and / or useful programs (computer freezing ).
Fork bomb can be obtained as a result of an error in good programming. For example, a program listening on a network port may, upon receiving a network packet or establishing a connection, fall into an endless loop of creating its own copies to process a packet or connection. A simple programming error can lead to a memory leak or to consequences that are characteristic of the results of the fork bomb.
Examples of fork bombs in different programming languages
C : [1]
#include <stdlib.h>
int main ( void )
{
for (;;) {
system ( "start" );
}
}
Bash : [2]
: () { : | : & } ; :
Perl :
fork while fork
Python :
import os
while True :
os . fork ()
Ruby :
fork while fork
The second option:
loop { fork }
PHP :
<? php
while ( true ) {
pcntl_fork ();
}
Microsoft Windows batch file :
: s
start % 0
goto : s
Second option
start % 0 % 0
VB.NET Option
Do System . Diagnostics Process . Start ( System . Reflection . Assembly . GetExecutingAssembly (). Location ) Loop While True
Go :
package main
func main () {
for {
go bomb ()
}
}
func bomb () {
go bomb ()
}
Pseudocode :
alg ProgramX bye truth nts Call ProgramX kts con al ProgramX
Difficulty of Elimination
In the event of a successful operation of the fork bomb, it becomes difficult or practically impossible to restore the computer to normal operation without rebooting , since the only way to stop the fork bomb is to simultaneously stop all working copies of the fork bomb. In most operating system implementations, calling a command to terminate a process requires starting a new process, which is impossible under conditions of a successful fork bomb.
However, in practice, some fork bombs do not require such drastic measures and can be destroyed without the need for a reboot. Consider, for example, the case of the bomb from the example above:
: () { : | : & } ; :
The peculiarity of this code is that it does not go in cycles after an unsuccessful generation of its copies, but terminates. As a result, the list of processes is constantly on the verge of filling: one of the copies of the fork bomb is completed, and the vacated space immediately engages in the newly created process from another copy of the fork bomb. It becomes possible to compete with the fork bomb to capture a place on the process list. Then it is possible, sooner or later, to launch a command to destroy all copies of the bomb bomb at the same time, or to launch a safe program that will gradually “win back” a place in the process list until the last fork bomb process is completed. An example of such a secure zsh program:
while ( sleep 100 & ! ) do ; done
Prevention
One way to prevent the negative effects of fork bombs is to force a limit on the number of processes that the user can start at the same time. The amount of virtual memory allocated and other system resources may also be limited. When the maximum available processes has been exhausted, an attempt by the process to create a new process will fail. The maximum of processes to be launched should be such that it allows you to run a reasonable useful number of programs, but does not lead to a system crash while simultaneously launching a fork bomb from all users of the system.
It should be noted that limiting the number of processes in itself does not prevent the launch of the fork bomb, but is only aimed at minimizing the possible harm in case of its operation.
Another solution to the problem is the intelligent recognition of fork bombs using the operating system itself, but this solution has not been widely used.
There is such a difficulty that if a fork bomb takes up all available processor time, then the results of its operation can be disastrous not only on a single-processor, but also on a multiprocessor system, even if the number of processes is limited. For example, if the number of processors is 16, and the maximum number of running processes is 100, then on each processor there will be an average of 6-7 working instances of the fork bomb devouring processor time. To solve this problem, a restriction on binding to processors is applied.
See also
- fork () - system call of Unix-like operating systems (according to the POSIX standard)
- Zombies and orphan processes - similar cases of leaking system resources
Notes
- ↑ one of the most elegant examples of fork bombs, created by Markys'om
- ↑ one of the most elegant fork bomb examples created by Jaromil