Fork Bomb

Late 1970s. Two interns are reading system call manuals; we're on a v6 Unix system, running on a PDP-11/45.

Like many bad ideas, it starts with an innocent question: "What happens if we recursively fork?"

Five minutes and a couple of C compiles later, we're sitting at the DEC printing console watching the system panic. The sysadmin comes running in a minute later.

"What did you THINK would happen?"

We explained that we didn't know, and we wanted to find out. He rebooted the system, fixed up a couple of busted inodes with ncheck and clri and so forth (this, children, was in the days before fsck...) and went back to his meeting, grumbling "... (inaudible) interns..."

And that's when I got seriously interested in how kernels worked.

When I was taking an operating systems class I wrote a fork bomb to play with:

    ~ $ gcc fork-bomb.c
    ~ $ ./a.out

I saw that it did indeed crash my lab machine, and when it rebooted I went on with my life.

Our CS lab had a central server which served a lot of important functions and also was the terminal server you could SSH into when working from your dorm. All of these had shared home directories.

Late one night working from my dorm before a big project was due I ran:

    project $ gcc project.c
    project $ ~/a.out  # note the '~'

And forkbombed the central server. A lot of people were pretty mad at me.

Lessons learned:

* People should not be logging into the central server to do their work, or it should at least have nproc limits

* Always name your executables (gcc foo.c -o foo)

* Don't leave bombs lying around

I got nerd sniped on a chan board one time by a fork bomb that looked like this:

    eval $(echo "I<RA('1E<W3t`rYWdl&r()(Y29j&r{,3Rl7Ig}&r{,T31wo});r`26<F]F;==" | uudecode)

Classic stuff. So I'll just remove the eval and subshell and let echo through to uudecode so I can see what this mess will do.. aaaaaaaand there goes my system.

I'd neglected to see the backquoted strings in the mess. This one had some layers!

Story time: I once worked part time with a company, and their DBA was doing a project to look up all the IP addresses that had been logged into one of their database tables. For every address he was running a bash script to do the reverse lookup.

This was going to take a few days to run, largely because it was forking 10-20 times for every IP address, most of the lookups themselves were fairly quick (though some weren't). I explained to him that forks are fairly expensive operations, and every line in his shell script was 1+ forks.

I thought this would be an easy win, I picked up a multi-threaded DNS lookup tool and showed him that it could look up a thousand addresses in < a second. "Oh, so I can just replace the "nslookup" with this other program in my script?"

I explained that he would need to make a file with all the IP addresses he needed to look up, I'd run the program on a server at our data center (to not clog the office T1), and then I'd give him back a file containing "address,name".

"Oh... So I'd have to correlate each address to a name myself? I can't do that, I need to run this script." In my head I said "You're the DBA, how can you NOT correlate this data?"

In college 20 years ago some student hit "reply all" on some random email to complain about something and thus started a 2 day long chain of emails of people arguing with the person and others yelling at everyone for hitting "reply all" And so thought it was a good idea to reply with a link that said something like "go here to make the emails stop" which was just my picture making a stupid face and some javascript I made that would open 2 more identical windows, then those 2 would execute until something crashed. It was amazing I didn't get in trouble for it and some guy at the 7-11 recognized me. Highlight of my life.

Working at a big bank in the early 90's we all had Sparks on our desks. If you walked away without your screen locked, you might come back to find 'ls' aliased to a fork bomb or 'rm -rf *' or something else fun. The guy who sat next to me was truly a master. He would start with aliasing cat, more, ls, cd and then alias itself.

The other fun trick was finding someone who had left xhost+ open and while a boss was at their desk, popping open NSFW pictures on their screen in an xv window.

A new guy was working on a shell script that somehow wound up forking copies of itself. This was in the early 90's on HP workstations that were attached to a cluster server and relied on it for disk and other services, and he was running his script there. All of the connected workstations froze up.

When my workstation locked up, I stood up and heard a commotion coming from his cube. He was on the phone with one of our sysadmins, desperately trying to kill the processes via his non-functional terminal. I asked for the phone, and told the sysadmin (who still had a functioning terminal) to rename "sh" to something else for a second.

Boom! In just a few seconds all of the processes died out.

I said "Thanks", handed the phone back and went back to my cube while he just stared at me slack-jawed.

My most memorable fork-related cockup was in 1999ish. I was working on a program to purge cache entries from a web server’s front-end proxies when users uploaded or deleted files. At one point I redid the restart/daemonize logic and I got a condition backwards. The result was that when the daemon received a restart signal it went into a loop, repeatedly forking - but it wasn’t a fork bomb: the parent immediately died and the child looped to fork and die, etc., so only one was running at a time.

In most situations this would have been OK, but it was running as root on a production server. So I could not (for example) kill all my processes with kill -9 -1 because that would have killed the machine.

So the pid of my errant program was counting up quite fast. I tried finding it in the output of ps then running while !kill $pid; do :; done for a slightly bigger $pid, hoping that my program would be killed when its pid reached $pid - nope, it won the race, and forked right past the kill loop. I tried rewriting the kill loop in C and the problem program still won the race.

In the end I needed to run several copies of the C kill loop on consecutive pids in order to kill the problem program as it forked through the kill zone. The collateral damage was only a few ftp login attempts...

I did this inadvertently in the 80s on an Encore Multimax, a parallel computer base don NS 32k processors. I was writing a parallel program in assembly that had to call fork() in a loop to spawn a few child processes. I did not realize that register contents are not copied over to the child process after a fork call and the loop counter was in a register. They had to actually power down the system to get it out of this state :-)

In high school we had access to the Univac 90/70 at the local college. It supported interactive use via dial up terminals and batch jobs. There were exactly two slots in the batch queue. I wrote an assembler program which created a last-chance exit handler and then went to sleep. In the exit handler, it spawned two new copies of itself in the batch queue. Eventually the operator (who wore a NORML pin on his blue jean jacket) noticed a job was stuck in one of the active slots. So he killed it.

Later, he came out of the machine room and asked me to look at something. There were a whole bunch of stalled batch jobs and two jobs sleeping in the active slots. I calmed him down and showed him the equivalent of "kill -9" and promised never to do it again.

I accidentally wrote a fork bomb in a shell script last week. It went like this:

    foo() {
       echo "$1" | foo
    }

Then called foo later. The 2nd occurrence of foo was a typo for something with a very similar name. Took me a few reboots before I realized this.

I find this a bit more interesting than the cited shell example because it does not involve the & token. Just pipes.

Not necessarily a fork bomb but had similar effects:

- Boss asks me to write a script to check X resource

- Script is done and takes around 30 seconds to run

- Boss neglected to tell me script was schedule to run once a minute

- As load increased, script started to take more than 60 seconds to run

- Since we are running script every 60 seconds, we start having multiple copies of the script

- Server goes down

#funtimes

Iirc, Champaign-Urbana had a C fork bomb source code spray painted on an underpass wall. I suppose it relied on a passing victim to enter it into their own computer ;)

A Python fork bomb was my first major achievement in college. Four lines of code took out a server. I'd like to claim it was a great achievement in hacking but nope, just trying to grok concurrency and failing hard.

In the very early days of the Internet I was running a small ISP and I ran a fancier version of this:

    for word in `cat /usr/share/dict`; do whois "$word.com"; done

and shortly got a phone call from Network Solutions, "What the hell are you guys doing? You're hammering us?"

This was a right of passage for CS students when I was in school - to (usually) accidentally write one when trying to implement some server or service. Fortunately most "modern" UNIX systems at our school by then (mid 1990s) had per user process limits so you'd just screw yourself up.

I accidentally took down Netcom with a fork bomb in the early 90's. They quickly discovered the problem and had the system back up within about 10 minutes, after which I found that I could no longer log in because they had banned my account.

I called them up and explained that it was an accident, but also asked why they did not enforce quotas on user accounts to prevent such things. They thanked me and re-enabled my account right away.

In college in an OS course about 20 years ago, we tried fork-bomb on HP-UX, AIX, Solaris, Linux and MINIX (2.0)(they have FreeBSD now). On some OSes, it created a boat-load of zombie processes.

Another one was the malloc() bomb (sometimes combining with the fork-bomb to be the malloc-fork-bomb(). On some modern OSes, you have to actually initialize memory to something other than zeroes and keep a pointer to them to prevent aggressive compression and heap compaction.

Finally, running John the Ripper when they still ran NIS and getting the passwords of 26 lecturers and professors in 30 seconds by simply taking the output from getent passwd.

PS: Back in the day, before people lost their minds and over-criminalize nothingburgers, I almost got Aaron Schwartz'ed when I setup a web proxy in the computer lab to access some payware documentation off-campus that was IP locked. Thankfully, they use Postgres instead of Redwood Shores'-ware now.

In college we had a project to implement a shell that supported pipes. All students developed on a school server. This project was famous for students inadvertently fork-bombing the server. Part of the difficulty of this project was writing and testing your code while not fork bombing and working around other students who had.

Slightly unrelated, but what amazes me is the fact that every living organism, in a nutshell, is a fork bomb.

I have bash fork bomb engraved on my AirPods pro; it is a great conversation starter.

In the late '90s, I was working for CMU as a programmer and general-purpose janitor for the Andrew system, the campus computing environment. Students frequently worked on a pool of shared machines, particularly for a class like Operating Systems that required Unix. (Yalnix did not run on Linux at the time.) The shared machines had no per-user quota, and generally, abuse wasn't a problem.

But one semester, the OS class added a new first assignment: write a shell. It took about a day or two, but after the second or third accidental fork bomb, a generous per-user process limit was imposed.

You could really be a jerk and do this...

    while true

        try:
            os.fork()

        except Exception as e:
            continue

I think everybody discovers, and then has fun with, this in their first Systems course on the shared school servers. In mine I discovered something much more fun: https://linux.die.net/man/1/talk

I found some ascii art of the trollface (https://i.kym-cdn.com/entries/icons/original/000/000/091/Tro...) and saved it to a file, then wrote a script that would find user $1 and infinitely "talk" trollfaces at them, making their terminal completely unusable. Then I'd run it against my friends when we were working in the computer lab :)

Shared Unix systems are rife with prank opportunities

I wanted to try this out, but I didn't want to kill my daily driver. I fired up a Raspberry Pi 3. perl -e 'fork() while 1;' took it down in about two seconds. I couldn't even switch to a different TTY to kill the processes.

Btw..

-- No warranty, may break the universe and eat your children --

:(){:&;:};:&

    int*f(int n){char*p,*r=malloc(n);for(p=r;r&&n--;)*p++=n;return r;}int main(){int i=10;sleep(1);do printf("&%1d",i[f(1<<20)]&1),fork();while(--i);main();}

Here's others that aren't mine in a zillion languages:

https://github.com/aaronryank/fork-bomb

In grad school some of my lab mates accidentally fork-bombed UT Austin’s entire CS department compute cluster. Someone had written this weird re-entrant shell script that would, depending on arguments, either submit a batch of jobs to the cluster or actually run a job.

Unfortunately the script was called with the wrong arguments, leading to the cluster submitting jobs recursively back to itself until the entire thing went down.

Good times.

We were rewriting a program from multithreaded to multiprocess execution. But instead of launching a slave, the master launched another master.

I used to build .bat(ch) scripts that would do this to crash the computers in middle/jr/high school to get out of schoolwork.

With limited computers in the computer lab this was especially efficient if you set them to open, spawn, and replicate on startup. The old systems could barely handle it and would just error out and the cycle continued.

Here's a fun one (not a fork bomb):

  int main() {
    printf("choo");
    fork();
  }

This remember me a program I wrote in high school in Pascal.

I think it was like this: Program Bomb uses crt,graph; Var Graphics,Mode: smallint; begin Graphics:=Detect; Mode:=detectMode; while(1!=0) InitGraph(Graphics, Mode,'');

It killed an old PC with Windows 2000

I like fork bombs that actually limit or halt the system. Creating a sub-process of some kind in language X usually boils down to multiple processes getting killed/stalled or - if there is one - a VM to crash. Meh.

Example: JavaScript vs "%0|%0"

> The trick here is that : is used as a function name, which is possible because the colon is not a reserved character in Bash as it is in most other languages.

There is an additional subtlety in that : is the null command, which is being redefined.

Did not find go in the examples, so here is how you do it:

for {

  go main()

}

Forkbombing was one of the first things that piqued my interest in CS! It can be written so tersely yet effectively: :(){ :|:& };:

ulimit is your friend.

I have the shell one as a t-shirt and it is fun to see who "gets it" when I wear it to work.

I liked the bash one liner so much I got it as a tattoo. I get asked about it all the time.

why does shell/bash needs to call the bomb twice?