A Taste of Computer Security

© Amit Singh. All Rights Reserved. Written in June 2004

Digital Life: Worms

In this era of "networked by default" computers, the line between typical definitions of a virus and a worm is getting blurred.

In 1975, science fiction writer John Brunner wrote about "worms" in a computer network in his book The Shockwave Rider.

I guess you all know about tapeworms ... ? Good. Well, what I turned loose in the net yesterday was the father and mother — I'll come back to that in a moment — the father and mother of all tapeworms.


It consists in a comprehensive and irrevocable order to release at any printout station any and all data in store whose publication may conduce to the enhanced well-being, whether physical, psychological or social, of the population of North America.


My newest — my masterpiece — breeds by itself.


And — no, it can't be killed. It's indefinitely self-perpetuating so long as the net exists. Even if one segment of it is inactivated, a counterpart of the missing portion will remain in store at some other station and the worm will automatically subdivide and send a duplicate head to collect the spare groups and restore them to their proper place.


Incidentally, though, it won't expand to indefinite size and clog the net for other use. It has built-in limits.

— John Brunner
The Shockwave Rider (1975, Ballantine Books, New York)

The Early Worms

Researchers John Shoch and Jon Hupp experimented with "worm" programs in 1982 at the Xerox Palo Alto Research Center. The computing environment consisted of over 100 Alto computers connected using the Ethernet. A worm was simply a multi-machine computation, with each machine holding a segment of the worm. The segments on various machines could communicate with each other. If a segment was lost (say, because its machine went down), the other segments would search for an idle workstation on which to load a new copy so as to replace the lost segment — self-repair!

It is interesting to note that all the worm pioneers were John's: Brunner, Hupp, and Shoch.

Good Worms

The idea behind these worm experiments was not that of mischief. With the worm mechanism in place, the researchers intended to create useful programs that would utilize any otherwise idle machines. Nevertheless, even though the aberrant potential of worms was clearly identified, they were not perceived as a real security risk. Comparatively, viruses and self-replicating trojan horse programs were considered a bigger threat to security.

Some of the useful things these worms were meant to do included reclaiming file space, shutting down idle workstations, delivering mail, and so on.

Such "good" worms exist even today. While these worms aim to fix, or prevent, the damage inflicted by "bad" worms (or attempt even general bugfixes), both kinds are surreptitious, and use a system's resources illegitimately.

Good Worms?

A program called Creeper was written as a demonstration of relocatable computation. Creeper moved through the ARPANET, attempting to find a Tenex, where it would start to print a file. It would stop after a while to find another Tenex, and move itself and its state to this new machine. A subsequent, enhanced version of Creeper could replicate itself occasionally. A program called Reaper was written to move through the ARPANET to find and remove instances of Creeper.

In their positive connotation, worms represented essentially distributed computing.

The Morris Worm

A Cornell University graduate student named Robert Tappan Morris, Jr. programmed and "unleashed" a computer worm on Thursday, November 3, 1988. The Morris worm had many firsts, mostly dubious, to its credit as a computer worm. It was the first (worm) to:

The Morris Worm only infected Sun 3 systems and VAX computers running variants of Berkeley UNIX. It exploited multiple vulnerabilities to gain entry into a system:

The worm exploited a buffer overflow in the finger daemon. It did so via a use of the gets() function in fingerd by passing in a specially crafted 536 byte buffer containing "shell code". The saved program counter in the stack frame for the main() function was overwritten, causing the following function to be executed:

execve("/bin/sh", 0, 0)

Note that the worm only used the buffer overflow exploit for the VAXen (and not the Sun systems).

The worm looked for machines running the sendmail program with the DEBUG command allowed. The DEBUG option allowed sendmail to be tested by running programs to display the state of the mail system without sending mail or establishing a separate login connection. Using the DEBUG command over an SMTP connection, it was possible to specify a set of commands that would be executed on the host.

The worm tried several ways to discover user passwords on a local machine: null passwords, passwords deduced from the user's GECOS information, a dictionary attack using its own 432 word dictionary, and the UNIX online dictionary.

Thus, the worm had logic to propagate itself, and logic to infiltrate systems. Today's worms usually have the same basic structure.

The Morris Worm led to an increased security awareness in the industry. An important outcome was the formation of the Carnegie Mellon Computer Emergency Response Team (CERT) in November 1988. Today, the CERT Coordination Center (CERT/CC) is a major reporting center for Internet security problems.

Today's Worms

With names such as Sasser, MyDoom, Sobig, Blaster, Code Red, and so on, today's worms often have a devastating effect on the Internet, causing damage in a variety of ways:

Email-sending worms are allegedly of great interest to spammers, as they allow spammers to use the victims' machines for sending spam while hiding their own tracks.

<<< Digital Life: Viruses main Viruses on Unix >>>