How Do They Work?
Props for creating the first fork bomb notwithstanding, the methods employed to disable those early machines aren’t likely to work in any modern sense, so it’s time to move on to modern fork bombs!
Thankfully for the majority of unwitting computer users out there, fork bombs aren’t generally spread in the same way as worms or viruses. However, they can (and occasionally do) occur accidentally, particularly in the case of software development. Take, for example, a developer who is creating a client-server application in which the application listens on a given network socket. Improperly implemented, this can theoretically cause an infinite loop which will continually use system resources until the system becomes unstable or inoperable.
While the logical solution to this problem is to terminate the process which began the cascade, it’s often not as simple as it sounds. A fork bomb works by creating a massive number of processes in rapid succession to over saturate the system process table. If this happens, no new applications or services can be started until something else is terminated. Unfortunately, in the time it takes you to terminate an instance of the fork bomb, another has spawned to take its place. Since each instance is launched as a separate process, you would likely have to terminate all running processes simultaneously to kill the attack successfully. More often than not, the easiest way to do this is to reboot the computer, risking data loss.
Perhaps the most elegant fork bomb ever written was introduced by programmer, artist and activist Jaromil (aka Denis Roio) as a piece of open-source art in 2002. His original, almost incomprehensible code was designed to run from the command line on a POSIX-based system and looks like this:
While this code might look like complete gibberish, it’s quite simple. Broken down into a more understandable form, it looks something like this:
Ok, so that’s only a little easier to understand; let’s break it down even further…
In the case of the original example (which you should now understand the elegance of), we are using ‘:’ as an arbitrary identifier for our function. But wait! We aren’t through yet! What about non-POSIX operating systems?
Microsoft Windows Batch
Yep! Go figure; if it can be done on Linux, it can certainly be done on Windows! The Windows batch scripting language exposes users to two different fork bombs: one elegant, one efficient. The elegant form is also one of the most straightforward fork bombs publicized to date:
The more efficient form on Windows looks something like this:
So as long as you don’t run random shellcode you’re safe, right? Wrong! Similar effects can be accomplished through many popular programming languages, as you can see below (I’m not going to keep explaining how they work, you get the idea)…
x86 FASM (Linux)
x86 FASM (Windows)
x86 NASM (Linux)
As you can see, fork bombs are extremely easy to write in virtually any language. Thankfully, while immediate recovery from a fork bomb can be a challenging exercise at best, prevention is feasible. Generally speaking, fork bombs only affect one user… the one who launched the initial process. As such, limiting the maximum number of processes accessible to a given user can prevent a fork bomb from being more than a minor annoyance. If, for example, you limit a user to 30 processes, and the fork bomb maxes out that limit, and your system has sufficient RAM to handle 30 small processes (it really should), you’ll be able to access the command line or task manager and kill the relevant processes.
This is particularly simple to accomplish on UNIX or Linux-based systems. These systems generally allow configuration of user process limits through two methods: a simple command aptly called ulimit, and the nproc line in the file
/etc/security/limits.conf. Again, these allow you to limit the impact of fork bombs, not prevent them completely. There is, however, a less-known option for detecting fork bombs by the operating system itself. Many Linux-based systems have access to a kernel module called rexFBD. While this module is not configured by default, a system admin with sufficient experience should have little trouble recompiling their kernel to implement it.
A similar method for diminishing the destructive value of fork bombs is available on FreeBSD. The system admin can edit their
login.conf to limit the number of processes available for each user on the system individually. Unfortunately, at this time there is no FreeBSD equivalent to the rexFBD kernel module.
As for all the intrepid Windows users out there… try not to run anything stupid. You don’t have any reliable options that I am currently aware of.