Advent of Computing - Episode 144 - RABBITS

Episode Date: October 27, 2024

:(){ :|:& };:

You just started working a new job as a programmer at the illustrious WidgetCo. It's the 1970s, the very heyday of the widget and sundry item business. Your first few days have been mainly orientation and indoctrination sessions. You're just now finally settling into your cubicle. You're ready to start some actual work, all thanks to a newly issued user account on the company mainframe. This was one of the very first eras where programming was somewhat convenient. Instead of working in batches through the intermediary forces of operators, you could actually just

log into an interactive shell using a real terminal. You didn't even have to deal with paper anymore. Glass teletypes meant you got an honest-to-goodness screen. Times were good. Widget Co. was also a very modern outfit back in those days. Their mainframe, an IBM 300-something or other, ran a fully timeshared operating system. Each employee could act as if they owned the thing, with some guardrails of course. Better still, the system was stable enough and secure enough that you could use it freely without ever worrying about a crash. So there's no harm in poking around on your first day on the computer. You surf through some directories until you start finding binary files to run.

You end up stumbling upon the assembler and some kind of compiler, a linker, a pretty nice looking text editor, all the usual stuff. Then you find a file called Rabbits. You don't remember hearing about this during the orientation, but hey, maybe it's a game. You have some vague recollection about a coworker joking there were, in fact, some games on the system for, quote-unquote, purely research purposes. The only way to really find out what Rabbids would do would be to run it, after all. And, well, it's not like it's going to take down the mainframe.

IBM systems are super stable these days. So you type the invocation and you hit return. And nothing happens. You don't even get back to a prompt. Your terminal just hangs. You can't even exit the program manually. All of a sudden, you hear swearing from the cubicle next to you. Some grumbles and muffled groans from deeper in the office. You hear a phone ringing somewhere. It might be your imagination, but you think you can even hear the far-off ka-chunk sound of a breaker being thrown. It would appear that the mainframe has crashed. This is probably a good time to take your lunch break. Welcome back to Advent of Computing. I'm your host, Sean, and I'm back!

I've finally completed my vacation and I'm back at the central office. I've returned just in time for the final episode of Spook Month, episode 145, Rabbits. Today we'll be discussing something very similar to a virus. Or, at least, some claim it's a virus. That is, the fork bomb. But while I've been away, it seems there's been quite the commotion. The Internet Archive, perhaps the best source of sources on the net, has been hacked. I've seen some comparing it to burning down a library. But luckily, bits don't really burn. The data hosted on the archive still exists, and the archive itself has been intermittently working.

Huge thanks goes out to everyone over there. I know how tough this kind of stuff can be on programmers and other staff. I'm sure they're doing the very best they can under the circumstances. sure they're doing the very best they can under the circumstances. But this does put me in a small pickle. I've been clear in the past that the Internet Archive is a core part of my research process. As of the time I'm writing this, their full text search and lending features still aren't working. Those are features I rely on very heavily over here on the show, so please work with me a little bit. If I miss something this episode, please forgive me. I'm a little off my footing from the very start here, that's not to mention the jet lag. With that said, what are we talking about today? Well, viruses have been a mainstay of spook months

past, and so far we haven't talked about viruses this year. This episode is going to be our dose of the topic, although it might be slightly homeopathic. We're looking at a rumor that I've ran across in the past of a maybe real, maybe virus from the early 70s. Specifically, this is a program called Wabbit, or maybe Rabbit, or Rabbits. This was a self-replicating program that didn't spread to other machines, but just made copies of itself. In doing so, it bogged down and ruined its host computer. If you look at timelines of computer viruses, you'll probably see an entry for Wabbit sometimes around 1974, but sometimes earlier. That, if it has any citation, will probably link to a post on an old ACM forum thread from around 1988. And that's where it all starts.

So what's the meat of the story? Is it real? And can we find some kind of sourcing that backs up the existence of a theoretical Wabbit? Well, let's find out. Allow me to set the stage with a reading from the jargon file. Its entry for Wabbit includes this definition. Quote, file. Its entry for Wabbit includes this definition, quote, a legendary early hack reported on a System 360 at RPI and elsewhere around 1978. This may have descended, if only by inspiration, from a

hack called Rabbits reported from 1969 on a Burroughs 5500 at the University of Washington Computer Center. The program would make two copies of itself every time it was run, eventually crashing the system. End quote. This, perhaps, gives you an idea of how up in the air the story is. When the jargon file sounds cagey, you know you're on shaky ground.

Things only get more confusing the more you look into Wabbit. Here's the ACM forum post I mentioned earlier, written by one Bill Kennedy. Someone asked for a virus dated prior to 1984. Back in 1974, I was working at a large firm with no fewer than three 360s lashed together. And a bright young fellow wrote a program named Rabbit. When Rabbit was submitted, it had found a way of taking a copy of itself and tossing it back twice into the ASP input job stream. One of ASP's famous qualities was how it got stingier and stingier about talking to its console when it began to get constipated. Needless to say, Rabbit constipated it so it was harder to kill the longer it ran. The bright young fellow was, justifiably, discharged. End quote. So there was a program called something something A-B-B-I-T, maybe with an S.

It was written in 1969, or 74, or 78. It may have inspired other such programs. It ran on an IBM 360, or maybe a Burroughs. There are even some that claim to have seen or heard tell of a similar program in 1973? Let's start by understanding what Rabbit is and work from there. That should give us some insight in our quest. In a word, this program is a fork bomb. The program starts up and then forks, making a second copy of itself in memory.

That copy starts up and then forks, making a second copy of itself in memory. That copy starts up and then forks, making another copy of itself in memory. This continues until the programs are all stopped, or the computer runs out of resources and stops. Forking here is a very specific operation. Normally, when you run a program, you're just starting up a single little program. It runs on its own, all alone, eating up memory and CPU time as the operating system sees fit. That's fine, but it's not very efficient. There are a number of different ways to kick things up a notch and parallelize your code. Sometimes, it's just more efficient to get the computer to do two things at once.

You can do that by forking off a child process. Forking is basic here. It usually just spins off a copy of your program that's somehow noted as being a child of the main program. This is noted so that the main process can control the child processes. In practice, you're supposed to have some code in place that figures out if the process running is a parent or a child and then acts accordingly. The parent usually wants to start up, figure out what work needs to be done, and then create a few child processes to handle those tasks. Those child programs start up, see that they are in fact children and not parents,

and then look for any work that was assigned to them. This is pretty slick, but it can go very wrong in very many different ways. It turns out that parallelization is actually one of the hardest things to program for. If your child process doesn't properly detect their child-ness, then they could assume the role of a parent and make their own new processes. Those processes, copied over with bad code and all, can then spawn still more children. Eventually you get a runaway reaction, and there are just too many processes for the computer to keep up. This grinds to a halt.

That's exactly how a fork bomb works. The behavior can be a pretty simple bug, or it can be malicious. Parallel programming is hard, so it's really easy to make mistakes. A fork bomb can just develop naturally as you try to come to grips with the machine, or it can be introduced by a mischief maker. The accidental aspect here makes tracking down the origin point particularly difficult. The first fork bomb was probably created by the first person to try their hand at parallel programming. They would have noticed the mistake, probably had to restart the machine, and then

continued on with their life a little bit wiser. But what about intentional fork bombs? According to the jargon file, this phenomenon starts in 1969 at the University of Washington Computer Center. This, it turns out, is almost impossible to verify. Don't you love folkloric accounts? The definition of rabbit doesn't show up in the jargon file until the 1990s, so we're already a good distance away from the time period here. Some details do line up, however. UW definitely had a Burroughs 5500 in this era, so the setting existed. However, we have no corroboration of this 1969 story. This leads to the possibility that Rabbit may be something of a myth, or at least, the early versions could be somewhat mythological. Let me explain by way of analogy.

The jargon file gives us a few synonyms for rabbit and wabbit. These include the aforementioned fork bomb and a little something called the cookie monster. Now, what is cookie monster, you may ask? It's yet another fork bomb, with a twist. Or, at least, it may be a fork bomb in certain incarnations. Once again, little cagey. So, check this out. Cookie Monster was, supposedly, a program that would run and prompt the user with, I want a cookie. If the user didn't reply correctly, it would fork, or otherwise cause mayhem and lock you out of your terminal session. The Cookie Monster actually did exist. According to the jargon file, the real program went by the name Cookie Bear.

This program originated on Multics systems at the very end of the 1960s. It went on to inspire similar hacks, often by similar names, on many other systems. similar hacks, often by similar names, on many other systems. It appeared at least on machines running TOPS-10, ITS, and GCOS. There was no such thing as portable code between these systems, so the cookie monster would have spread by programmers adapting the idea to new platforms. Maybe you would hear about the mythical cookie monster in a bar or from a co-worker or from a friend of a friend and decide, hey, that'd be funny to pull on my buddies back at work. We know about Cookie Monster because the history of Multics, where it originated, is very well documented. There's this whole site, multicians.org dedicated to it we have lots of detailed

interviews and accounts written by folk who worked on or worked with multics plus we're looking at a pretty restricted scene here not all that many people were using multics in the wild as it were so we have this closed ecosystem that's very well known and well accounted for. In that way, at least document-wise, it's similar to the ITS operating system we discussed earlier this month. Rabbit could have followed a very similar path as the cookie monster, just in the wild instead of inside a walled garden. That makes it very hard to trace exact details, and it would have meant that rabbit programs popped up all over the place. That lines up pretty well with what we see here. It's easy to find accounts of people writing or running into rabbit programs, or hearing about stories from friends of friends that saw rabbit programs.

This also opens up the possibility that the original Spark could have been an urban legend. Someone could have come up with the story of Rabbit, promulgated it on some kind of early messaging system, or just even told the story to someone late night over a couple of beers, a programmer got a few ideas and made it real. As for accounts of Rabbit's existence, well, it kind of does show up everywhere. There's the three possible start years I mentioned earlier. I've seen one account of some dude writing a Rabbit program in BASIC in 1972. There was a spate of newspaper articles in 2004 warning of the dangers of hackers slinging around fork bombs and Wabbits.

The most common fork bomb, a simple Unix one-liner composed entirely of punctuation, was written as a piece of code poetry sometime in the 2000s. It really does show up everywhere. So I think it's very likely that early reports may not all be trustworthy, but at the same time, the program is so simple, it could have appeared almost anywhere at almost any time. A complicating factor is the name. From what I've gathered, rabbit appears to be the oldest name for this type of program. That is, of course, a reference to breeding like rabbits. Or, perhaps, if you enjoy some blue humor, forking like rabbits. In some places, this gets corrupted to wabbit,

which the jargon file speculates is a reference to Elmer Fudd. The term forkbomb is the newest name used here, and it tells us something important. You see, the word fork isn't a 100% generic term. see, the word fork isn't a 100% generic term. It's more specifically what Unix calls the whole child process creation operation. It appears that the name switched from rabbit or wabbit to fork bomb as Unix was rising to prominence in the mid-70s. This means that we can put a place and date on those stories based on the language used. If the story is about rabbits, it's older or set on some non-unix system. That basic account I mentioned uses the term rabbit, so it's not a story about unix.

The newer formulation is called a fork bomb because it's living in the nix future. The final question is, could rabbits actually take down a mainframe? Just how dangerous are these programs? The simple answer is yes, and they're pretty dangerous. As the bomb spawns more processes, it uses up all the computer's resources. Now, there's a question of which resource gets saturated first, memory or processor cycles. If you have a beefy machine with not much memory, then it's possible you run out of memory first, since each fork makes a copy of the program in memory. You could also theoretically build a fork bomb specifically to be large, so when it gets copied it takes up a lot of memory.

If you have enough memory space, then you get into a situation where the process space gets overloaded. In multitasking systems, each process is supposed to get some equal share of the processor's time. As more processes enter the picture, each process gets a slimmer and slimmer share of that time. If you load up thousands and thousands of processes, then each program gets almost no time. The share is just too slim to be useful. Thus, the machine grinds to a halt. You're effectively locked out of the computer. There are some preventative measures, but none are completely effective. One is to limit the number of concurrent processes any one user can run. That can prevent a fork bomb from crashing an entire mainframe. With this limit in place,

a fork bomb simply reaches that upper bound, and then it stops, since it isn't allowed to start new processes. But that doesn't help the user that ran the fork bomb. And usually these kinds of tricks are meant to be played on a user. Someone accidentally stumbles on a bomb and then they're screwed. That user can't start any new processes because they've hit their limit, so they are effectively locked out of the computer. It's also hard to detect fork bombs before they execute. Or perhaps the correct term here is non-trivial. There are some known patterns that fork bombs follow. But there are also a nearly infinite number of ways to make a new rabbit. Plus, there's this neat little proof that shows it's actually impossible to figure out

exactly what a program does just by analyzing its code. Barring some radical shift in computing, rabbits will be spawning for a long, long time. Alright, thus ends our discussion of rabbits. Or wabbits? Or fork bombs? Whatever you call them, we're done with them. So what have we learned? Well, maybe not that much, actually. The story of rabbit programs seems to, well, really stretch back into the digital mists. Some say they were first created in 1969. Some say they appeared later. I'm personally inclined to say they've existed since the first multitasking programs spun up. Whatever the case is, these types of programs have definitely struck a chord amongst hackers and programmers. They have been widely copied, adapted, and styled upon up into the modern day.

Fork bombs aren't exactly viruses, but they share many features. While a rabbit doesn't migrate between machines, it is self-replicating. It can act almost alive, just like a virus. And the fascination around the fork bomb is very similar to the obsession around viruses. I'll include a fork bomb in the description, so if you want to ruin a computer at home, I'll include a fork bomb in the description, so if you want to ruin a computer at home, well, it's pretty easy to do. This is also where we end Spook Month for 2024. I hope you've all enjoyed the change of pace this month.

If you haven't, well, we will be back to regular service in just two weeks. I'm already starting up the next full-length episode. I've carried out a lot of the research while I've been on very long flights. And just as a little spoiler, we're going to be going to Germany for this episode. Thanks for listening. You know where to find me. Stay spooky and have a great rest of your day.