Fork Bomb (en.wikipedia.org)

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.

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

    while true

        try:
            os.fork()

        except Exception as e:
            continue

    $ cat nice.sh
    rm -rf $HOME
    $

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.

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

for {

  go main()

}

   fork while fork

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"

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.

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 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.

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

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.

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?"

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

ulimit is your friend.

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

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.

  echo "ponysay remember to log out" >> .profile

  echo "ponythink i should always log out" >> .profile

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

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.

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

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

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

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

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

   #!/bin/sh
   perl -e '1 while push @big, 1` &
   $0 &
   $0

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.

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