What is Fork Bomb, aka Rabbit Virus?

Malicious hackers created a fork bomb, also known as a wabbit or rabbit virus, to execute a denial-of-service attack on the target computer. The fork bomb replication occurs and wreaks havoc on the system's resources. It bogs down the system's performance and can even cause the system to crash owing to a lack of resources.

  • It is a denial of service (DoS) attack that repeatedly uses the fork system call until all system resources have executed a command. Over time, the system becomes overburdened and unable to react to any input.

  • A fork is a Unix and Linux system call that duplicates an existing process (also known as a parent) and makes a new process (aka, a child). This enables two methods to perform distinct tasks at the same time.

  • Unlike other DoS attacks, which often involve overloading network or system software from the outside, a fork bomb employs orders from the inside system it seeks to bring down. It can be self-inflicted at times.

  • An infinite loop that constantly spawns processes is the most basic construction of a Rabbit Virus or Fork Bomb. This process uses a lot of CPU time and resources from the operating system.

  • Fork Bomb is implemented in Unix-like operating systems by executing a fork in an endless loop. It can be done on Microsoft Windows by starting a new process inside an infinite loop.

  • Once a Rabbit Virus has been initiated, it is difficult to halt it. The issue is that many processes are launched in a short period, making it challenging to locate new processes and end them in that time frame.

  • A freeze usually lasts until the computer is rebooted, and regaining control often necessitates a hard reboot. Data will likely be lost. Some processors may include pre-set constraints that eventually grant access to the network to an administrator.

How Does a Fork Bomb Work?

The function name is ":" colon, followed by "( )" parentheses and curly brace " to start a function, then the definition of ":|:&" informs the bash to initiate the ":" function and "|" pipe its output to the same function ":" and transmit the method to the background defined by "&" so that it cannot be killed by pressing "Ctrl + C" Then there's the closed curly brace ", followed by ":;", which iteratively points the function.

To start the bomb, all you have to do is copy or type this code ":():|:& ;:" on the Terminal and press Enter. The performance of your processor determines the length of time it takes for your system to become paralyzed, the number of available processing cores, and the memory size installed. Even while the swap partition's size is essential, the system will typically take too long to reply to you once the bomb begins to use.

Preventing Fork Bombs

Nowadays, most operating systems take precautions to avoid this type of assault. At least one slot is reserved in the Operating System's process table. The fork bomb does not consume the entire process table, and another process can be launched to terminate the other processes.

The entire system can even limit the overall number of processes an individual user can launch in newer Unix-like operating systems. The ulimit command is used to accomplish this.

If you have a multi-user system, the most straightforward approach to protect it from such assaults is to limit the number of processes that each user can have, for example, using PAM.

One can limit the number of processes that users usually can generate to roughly 1000 to 4000. A user can operate on 200-300 processes at once. However, 1000 would be a little lower for persons who multitask frequently.

If you're already logged in, you can prevent the fork bomb by doing the following −

  • To halt the processes of the person who launched the fork bomb, issue a SIGSTOP command.

killall -STOP -u someuser
  • The /etc/security/limits.conf file is used to set process limitations throughout a system. This is the preferable option because the adjustment can be applied to all profiles, reducing the risk of individually modifying each user's profile settings individually.

Even with the current operating systems, there is no perfect strategy to eliminate a fork bomb. The more significant part of fork bomb attack scenarios may be prevented by enforcing standard security best practices and prohibiting unauthorized applications from running as root.