The first fork bomb has been effectively lost to history. However, there are two likely candidates for that unfortunate distinction. The earlier of the two was an attack called RABBITS. Little information is available about the original RABBITS attack, other than that it was let loose, so to speak, in 1969 on a University of Washington Burroughs 5500. Given the Burroughs 5500 was a punchcard-based system, I’d love to have gotten a chance to see how they pulled it off!

The second option for first fork bomb (and the more likely candidate in my opinion) was a 1978 attack called wabbit which ran on the IBM System/360 series computers. While insufficient information is known about RABBITS to conclusively call it a fork bomb, wabbit is known to have been one. Effectively, it created two copies of itself at each run causing a cascade reaction which would eventually disable the system.

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…

…whew…

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?

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)…

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.