The Morris Worm: The Night the Internet Learned to Distrust Itself

For twenty years I ran the night side of a data center, and the first rule of that job is that you trust the machine in front of you. You trust that the server is running your code and not somebody else’s, that the network carries your traffic and not a stranger’s, that the box on the desk does what the manual says. Take that trust away and you can’t do the work at all, because every command becomes a question you have no way to answer.

On the night of November 2, 1988, a few thousand system administrators lost that trust all at once, and the field I would spend my career in was born out of what they felt that night.

I have a lot of respect for the people who worked that night, and very little patience for anyone who treats the Morris worm as a quaint bit of trivia. Every weakness it used is still turning up in production systems, at companies that should know better, and the people who pay for it are the operators who get the phone call in the middle of the night.

What kind of program was the Morris worm?

The Morris worm was a small program, written in C, that copied itself from one computer to another across the early internet without anybody’s help. A virus needs a host program to ride inside and a person to run it. A worm needs neither. It moves on its own, finds the next machine on its own, and lets itself in on its own. The Morris worm was the first one to do that across the internet at a scale anybody noticed, and it was the first to make the national news.

Robert Tappan Morris, a 23-year-old graduate student at Cornell, wrote it. His father was a cryptographer at Bell Labs who later worked at the National Security Agency, so the son grew up around computers and was good with them, especially the Unix systems that ran most of the network. By his own account, he didn’t build the worm to wreck anything. He built it to answer a question: how big is the internet, really? A program that could copy itself to every machine it could reach would, in effect, count them.

He released it around half past eight in the evening on November 2. To hide where it came from, he launched it from a machine at MIT instead of from Cornell.

Within twenty-four hours it had reached an estimated 6,000 of the roughly 60,000 computers connected to the internet, close to ten percent of everything online. Machines at Berkeley, Harvard, MIT, Princeton, Stanford, Johns Hopkins, NASA and Lawrence Livermore National Laboratory slowed to a crawl and then stopped. A student at Berkeley sent a message that night that has stuck to the story ever since: we’re currently under attack.

What line of code made the Morris worm so damaging?

The damage came from one setting, and it’s a lesson I watched play out in operations a hundred times over the years.

Morris knew a careful administrator might try to defend against his worm by teaching a machine to fake being infected, so the worm would skip it. To stop that trick, he told the worm to copy itself onto a machine sometimes even when the machine claimed it already had a copy. He picked a rate: one time in seven, roughly, install anyway.

That number was too high. On a busy machine, the worm landed again and again, each copy running at the same time, each one hunting for new targets and eating processor time. A single computer could end up running dozens of copies of the worm at once, and the load ground it to a halt. The thing that made the worm famous was a fraction, one in seven, set a little too generous, on a program built to keep trying. The damage was a rounding error in the design.

I spent my career watching small numbers do large harm. A backup retention set one day too short. A timeout set a few seconds too long. A permission granted to a group instead of a person. The Morris worm is the founding example of the pattern, and the pattern is this: the break-in is rarely the interesting part. The interesting part is the ordinary setting that turns a contained event into a disaster.

How did the Morris worm get in?

The worm didn’t use one trick. It used several, and it tried them in turn until one worked. That’s exactly why it spread so fast. If the front door was locked, it went to a window.

It exploited a debug feature left switched on in sendmail, the program that moved email between machines.

It attacked a program called fingerd, a tool that let people look up who was logged into a machine. It fed the program more data than the program expected and overflowed its memory. That technique, the buffer overflow, went on to become the single most common class of software vulnerability for the next thirty years. And it simply guessed passwords, carrying a built-in list of common ones and trying them against user accounts, because it knew people reused weak passwords across machines they trusted.

Look at that list with modern eyes: a feature nobody turned off, a program that trusted its input, and passwords that were weak and reused.

Those three failures didn’t stay in 1988. I wrote policy against every one of them for twenty years, and I was still writing policy against them the week I left. It galls me that the tools have changed beyond recognition and companies are still leaving the same three doors open.

And the deepest assumption the worm exploited was trust between machines. A few thousand researchers who knew each other built the early internet, and they designed the systems to cooperate, to let a request from another machine in because another machine was, by definition, a colleague.

The worm didn’t break that trust so much as walk straight through it. Every machine it reached had its own configuration telling it to be helpful to strangers.

The morning after

By the next morning, administrators across the country were doing the only thing that worked: pulling their machines off the network entirely.

That was the tragedy of it. The single most connected experiment humanity had ever built defended itself by disconnecting, node by node, until the thing that made it valuable was gone. Email stopped moving for days. People drove to each other’s campuses to share fixes, because the network they’d have used to share them was the thing under attack.

A team at Berkeley and others worked through the night taking the worm apart and writing the steps to kill it and keep it out. There was no procedure for any of this. Nobody had a playbook for a self-spreading program, because there had never been one. They were inventing incident response in real time, at three in the morning. That’s the only time anybody ever really invents it.

Purdue’s Eugene Spafford wrote a technical autopsy of the worm that people still read, and the government asked Carnegie Mellon to stand up a permanent group so that next time there would be somebody to call. That group became the CERT Coordination Center, the first organization in the world dedicated to coordinating the response to computer emergencies.

Before the Morris worm, there was no such thing as a place to report that your network was under attack. After it, there was. The alarm box on the corner got installed because a building had already burned.

What happened to Robert Morris?

The FBI investigated, and Morris became the first person convicted under the Computer Fraud and Abuse Act, a 1986 law that until then had never been tested in a courtroom. In 1990 a jury found him guilty. He drew three years of probation, 400 hours of community service, and a fine of just over $10,000. No prison.

The case set a precedent that still gets argued about.

The court held that releasing the worm was a crime even though Morris hadn’t meant to cause damage, because he had knowingly reached into machines he had no authorization to touch. Intent to explore wasn’t a defense. The access itself was the offense. Every hacking prosecution since has stood partly on that ruling, and the debates over how far the CFAA reaches are debates about a line first drawn around this worm.

Morris himself did fine. He finished his education, co-founded a startup that Yahoo bought for around $49 million, became a professor at MIT, and helped start the venture firm Y Combinator.

The first person convicted of a major computer crime in the United States went on to a distinguished career in the same field, and I don’t hold that against him or the system. The people who understand how to break these things and the people who understand how to build them are very often the same people, and I’d much prefer they spend their careers building. Keep that in mind as you read the rest of this series.

Why does a 1988 worm still matter?

Because it broke an assumption that every attack in this series breaks again in a new costume. Before that November night, the internet was a trusting place because it could afford to be. Everyone on it was a colleague, the machines were built to cooperate, and the idea that the network itself could be a weapon simply hadn’t occurred to the people using it.

The Morris worm was the moment that assumption died, and Morris didn’t need malice to kill it. He only had to prove that trust at scale is a vulnerability at scale. A network built so that every machine helps every other machine is a network where one clever program can ride that helpfulness to every corner at once.

That’s the thread this whole series pulls on. In the articles ahead, the target is a nuclear enrichment plant sealed off from the internet entirely, and the attackers cross the gap anyway. The target is a militant group that threw away its smartphones for simple pagers, and the pagers were rigged before they arrived. The target is eighteen thousand organizations that installed a routine software update from a vendor they trusted for years.

Every one of those stories is the Morris worm again, wearing better clothes. Something the victim was sure it could trust turned out to be the way in.

The names change: air gap, supply chain, trusted update, trusted contractor, trusted maintainer. Underneath every one of them is what a few thousand administrators learned on November 2, 1988, watching their machines freeze. Nothing is isolated, and the wall you’re counting on is only as good as your last test of it. I think any executive who still approves a system because the diagram says it’s walled off is repeating the mistake of 1988, with nearly four decades of warnings to ignore.

For the rest of the story, keep going through the series below, and for the wider view of security and the writers and executives who need to understand it, the cybersecurity hub collects the rest of my work on this.

Frequently Asked Questions