The Internet's First Disaster Was Caused by One Line of Defensive Code

On the evening of November 2, 1988, system administrators across the United States started noticing that their machines were slowing down.

Not crashing. Not showing errors. Just getting slower — and then slower, and then unusably slow, as the load average climbed into the dozens and the hundreds. Rebooting fixed it for a few minutes. Then the machine would begin to bog down again.

By the next morning, roughly six thousand computers were effectively out of service. The internet at the time had somewhere around sixty thousand connected hosts, so this was, in round numbers, a tenth of everything. Universities disconnected from the network entirely. Some stayed dark for days, because the standard way to tell people the network was compromised — email — ran on the network.

The thing doing this had been written by a 23-year-old graduate student, and it was not supposed to hurt anything.

Three Doors, All Unlocked

Robert Tappan Morris was a first-year PhD student at Cornell. He was also the son of Robert Morris Sr., a Bell Labs cryptographer who by 1988 was the chief scientist at the National Security Agency's National Computer Security Center. The younger Morris had grown up around Unix internals the way other kids grow up around a family business.

His program was a worm: a piece of software that copies itself from machine to machine across a network without needing a host program or a human to run it. To move, it needed ways in, and Morris used three.

The first was sendmail, the program that handled electronic mail on nearly every Unix system. Sendmail shipped with a debugging mode left enabled in most default installations, and that mode would accept a command from a remote connection and execute it. This was widely known and widely not fixed.

The second was fingerd, a small service that told you whether a given user was logged in. It read incoming data using the C library function gets(), which copies input into a fixed-size buffer without checking whether the input fits. Send more data than the buffer holds and the excess overwrites whatever sits next to it in memory — including the address the program will jump to when the function finishes. Morris sent 536 bytes into a 512-byte buffer, and the last part of it was a return address pointing at his own instructions. This was one of the first uses of a stack buffer overflow in the wild, a decade before the technique became the defining vulnerability class of the internet.

The third was simply trust and bad passwords. Unix systems used rsh and rexec to let machines log into each other without a password, on the theory that if you trusted a user on machine A, you trusted them on machine B. The worm walked those trust relationships. Where it needed a password, it guessed — against the username itself, simple permutations of it, and a built-in dictionary of 432 common words that Morris had compiled. On a network where password hashes were readable by any user, that was enough surprisingly often.

None of these were exotic. All three were known problems that the community had decided were tolerable, because the network was small and everyone on it was, roughly speaking, a colleague.

The Safeguard That Broke Everything

Morris understood that a worm which infected the same machine repeatedly would be obvious. So he wrote a check: before installing itself, the worm would ask the target whether a copy was already running there. If yes, the new copy would exit.

Then he thought about it from the other side. If the check were that simple, any administrator could defeat the entire worm by writing a small program that always answered "yes, I'm already infected." The worm would politely decline to enter, everywhere, forever.

So he added a coin flip. Roughly one time in seven, the worm would ignore the "already infected" answer and install itself anyway.

That single decision is what turned an experiment into an outage.

The math is unkind. On a heavily targeted machine — one sitting on a well-connected network, receiving infection attempts constantly — one in seven attempts succeeding is not a small leak. It is a steady accumulation. Copies piled up. Each copy consumed processor time trying to spread to other machines. The load climbed until the system could do nothing else, and the machines under the heaviest attack were the important, well-connected ones that everything else depended on.

The worm did not delete files. It did not steal data. It did not corrupt anything. It just ran, thousands of times over, on machines that could not tell it to stop.

Two Days in the Basement

The response was ad hoc, because there was nothing else. There was no incident response team to call, no vendor advisory system, no coordinating body of any kind.

What happened instead was that groups at Berkeley, MIT, and Purdue got copies of the binary and started taking it apart, in some cases working through the night in shifts. They shared findings over the few network paths still functioning and over the telephone. Within about two days they had reverse-engineered the propagation methods, published the fixes — patch sendmail, recompile fingerd, change passwords — and the outbreak was contained.

Morris, meanwhile, had realized within hours what he had done. He asked a friend at Harvard to post an anonymous message to a Usenet group explaining how to stop the worm, along with an apology. The message was too little and, on a network that was falling over, arrived too late for most people to see it.

He had released the worm from MIT rather than Cornell, specifically to obscure where it came from. That detail did not survive contact with investigators, and it did not help him in court.

The Precedents

Two institutions came out of those two days.

The first was CERT/CC — the Computer Emergency Response Team Coordination Center, established at Carnegie Mellon University weeks later with DARPA funding. Its purpose was to be the phone number that did not exist on November 2nd. Nearly every national CERT and corporate incident response function in the world traces its lineage to that decision.

The second was the first felony conviction under the Computer Fraud and Abuse Act. The CFAA had been passed in 1986 and never seriously used. Morris was convicted in 1990 and sentenced to three years' probation, 400 hours of community service, and a fine of just over ten thousand dollars. Prosecutors had sought prison time.

The case established that intent to cause damage was not required. Morris had not meant to bring down a tenth of the internet; he was convicted anyway, on the theory that unauthorized access plus resulting damage was sufficient. That interpretation has shaped American computer crime prosecution ever since, and it remains genuinely contested — the CFAA's breadth has been criticized for decades as sweeping in behavior no one would call hacking.

Morris himself did fine. He finished his doctorate, co-founded Viaweb with Paul Graham, sold it to Yahoo in 1998, and became a professor of computer science at MIT — where his office is a short walk from the machine he used to launch the worm.

What It Actually Proved

The Morris Worm is usually told as the story of the first internet worm, which is nearly true and not the interesting part.

The interesting part is that every technical failure in it was a known, accepted, documented weakness. Sendmail's debug mode was not a secret. gets() was understood to be unsafe. Password guessing was not a novel idea. The internet of 1988 was insecure because its users had collectively decided that security was not the pressing problem, and they were right up until the evening they were wrong.

And the largest single cause of damage was not any of the exploits. It was the reinfection rule — a safeguard, added deliberately, by an author trying to be careful. He reasoned about an adversary who would lie to his worm, built a defense against that adversary, and never worked out what the defense would do at scale.

That is a failure mode that has not gone anywhere. The retry logic, the fallback path, the safety valve — the code written to handle the case that should never happen is the code that gets the least testing and does the most damage.

The Morris Worm: A Cybersecurity Turning Point covers the whole episode — the network before it, the student who built it, the two days that stopped it, the trial that followed, and the security industry that exists because of it.