VX Heaven

Library Collection Sources Engines Constructors Simulators Utilities Links Forum

An Epidemiology of Viruses & Network Worms

Cliff Stoll
Proceedings of 12th National Computer Security Conf., Baltimore, October 12, 1989, pp.369-377
October 1989

[Back to index] [Comments]
Cliff Stoll
Smithsonian Astrophysical Observatory
Harvard - Smithsonian Center for Astrophysics
60 Garden Street
Cambridge, MA 02138
[email protected]

Copyright © 1989 Cliff Stoll.
All rights reserved.
Reproduction in whole or part prohibited without written perliission.


By comparing worms that propagate over the networks, we can learn about the threats to our computing communities. These worms take advantage, of operating system features as well as holes. They provide an adversary with both a denial of service weapon, as well as a means of gathering information. They can be studied with techniques developed for medical epidemics.


In the past year, we've noticed several network security problems. What can we learn from these? How common are they? How many systems can an attack disable? How have people responded to these problems? Is our only worry the denial of service? How vulnerable are our networks? This paper addresses these questions.

IBM Christmas Tree Exec

On December 18, 1987 [4, 10], a program infected the IBM internal network. The software itself was disguised as an electronic mail message, under the name of "Christma Exce". In fact, it was an executable command script, which, when executed by a user, mailed copies of itself to others on the user's mailing list.

This took advantage of an operating system feature: the ability to execute a command shell script which has been received in the mail. The header line instructed the recipient not to unpack the program, but rather to execute the mail message immediately. It relied upon manual execution to replicate itself.

Although called a virus, this program was a manually propagated worm: a program which is copied from one network node to another. Indeed, since the program relied upon the gullibility of users, Bill Rubin of IBM Watson Research Center, considers it a trojan horse [10].

Within a few hours, it had entered many hundreds of IBM mainframe computers around the world. The load upon the individual systems was sufficient to disable many computers until they were re-booted. On a large mainframe, this can take an afternoon.

The program first arrived over Bitnet on December 9. 1987. The shell script instructed the user to execute it to receive a graphic of a Christmas tree on the screen. The first two screens of data were a drawing of a Christmas tree followed by a message, "Browsing this file is no fun at all, just type Christmas from CMS".

But when a user executed that command, the program searched through a user's nicknames files (VM "Names" files), and mailed a copy of itself to each user mentioned in that file. It did not erase itself after mailing itself away -- if it had, it would have been more difficult to track down.

Propagation speed through two different networks

The Christmas Exec worm was first found on the Bitnet network. Within a day, warnings were sent out to Bitnet sites. Gateways to Europe purged copies and thought they had it under control. Unfortunately, a day or two later, the program reached the IBM internal network, VNET.

The VNET outbreak was much worse than on Bitnet. Although Bitnet covers many more sites, only a fraction of them use IBM hardware; all nodes on VNET are IBM sites. Then too, VNET network is much faster -- 56 KBaud, as opposed to Bitnet's 9.6 Kbaud. The program could spread faster there. VNET users often had large Names files, which promoted the worm's spread.

The Bitnet infection occurred early in the day -- systems managers could react during the day to stop it. The Vnet infection. occurring late in the day, occurred while nobody was watching. Finally, the VNET network, as an internal network, is an internal network, and probably was trusted more than a public network like Bitnet.

This Christma Exec was the first network-propagated security problem -- the predecessor to network worms. Worms are not the same as viruses. A computer virus copies itself into another program, and lies dormant until the infected program is executed. A virus cannot execute alone -- it must be linked with a program. A worm, however, is a valid stand-alone program. It copies itself from one computer to another, usually over a network. Strictly speaking, a worm does not infect a disk copy of a program -- it executes within a computer, and when the executing copy is stopped, the computer is clean, unless re-infected from outside.

Of course, this taxonomy is simplistic. A malicious program may have sections of code which are worm-like or virus-like. And the Christmas Exec used a trojan horse to invite users to execute it.

November Internet Worm

On November 2, 1988, a self-duplicating program was released into computers attached to the Arpanet. This program has since been disassembled by several groups [1, 2, 3] and well described in the June 1989 Communications of the ACM1.

Several salient points about November's Internet Worm:

  1. It used multiple attack mechanisms, taking advantage of:
    1. two bugs in network interfaces
    2. common passwords
    3. entries in trusted hosts tables
  2. It duplicated itself without manual intervention -- it was the first autonomous network worm.
  3. The worm was tailored to infect both Sun and Vax computers, but could only run under the Unix operating system.
  4. It was written to evade detection and understanding:
    1. it erased its argument lists
    2. it deleted the executing binary
    3. strings and constants were hidden by a hex mask
  5. Within it, but unexceuted, was code to send messages to another networked computer.

This fifth point is important: as we shall see, other worms have been modelled after this one, and sent messages to central collection points as each new host is infected.

How many systems were infected?

Although the microbiology of the November worm is now well understood, there have been no published epidemiologies describing the extent of the virus's spread. Reports of 6000 infected computers are based on only a guess.

To determine the extent of the worm's spread, I posted notices on the Internet, requesting anecdotal reports from both infected and non-infected sites. To insure widespread distribution of my requests, I posted these requests to several Internet forums, including Risks, Virus-L and TCP-IP forums.

The response to these requests was heartening. I received about 200 reports, of which 75 sites reported infected systems. Because of a lack of standardized reporting procedure, each report had to be separately analyzed to determine:

Most of the positive reports described multiple infections: a single person managed clusters of workstations. When the worm disabled one file-server, it disabled other workstations that depended on that server. The anecdotal reports often did not differentiate between individual computers being infected and multiple computers being disabled.

In October 1988, the Network Information Center's Domain Walking program counted about 60.000 computers attached to the Internet. What percentage of these were infected?

The 75 positive reports cited about 300 infected computers. Since many sites did not report, these reports alone do not determine how many systems were actually hit. However, several sites sent detailed computer generated logs, listing not only which computers attempted to infect their system, but also the times of each connection.

These two sets of reports (the human generated ones and the computer logs) are statistically independent measures of the same population. Indeed, some systems show up in both sets. By analyzing the cross-correlation between the two measures[7]. we can estimate the total number of infected computers. We find that the worm entered about 2600 computers. with a 1-sigma error of 275.

This is a useful quantity -- and contrasts with media reports of 6000 infected computers. This initial report, estimated by Schiller at MIT [1] was only an informal estimate. and was not based on a detailed sampling of the thousands of computers on the Internet. Indeed, one of the most noticeable effects of the November worm was the loss of electronic communications, as managers isolated their systems.

2600 infected computers corresponds to about 4% of the total Internet population. Past studies [18] show a similar rate of insecurity for networked computers.

How fast did the Internet worm spread?

There's other information in the field reports we gathered. By combining the times of first infection, we can graph the number of infected computers as a function of time:

Figure 1

The shape of this curve is important: the rising part of the S curve corresponds to an exponential growth, as would be expected were the program limited only by replication time. In this section, the slope of the curve indicates the e-folding time of the worm. As the curve flattens off, we see growth limited by available systems. A similar shape would be expected in a biological population exposed to a contageous virus [16,17].

With few exceptions, most systems were unavailable for use while infected; this shows an amazing ability to deny service to a wide expanse of users.

Worm of December 1988

On December 23, 1988, a worm was spread in the NASA/SPAN - DOE/HEPNET networks [5]. These networks are crosslinked, and rely upon the Decnet protocol. Almost all systems are Vaxes running the VMS operating system -- a homogeneous population.

Previously, security problems have received wide publicity: In July 1987, the Chaos Computer Club in Germany reported that they invaded several hundred SPAN computers [6]. Unlike these previous attacks, which were manual, the December Worm automatically attacked individual computers on the SPAN network.

This worm, written as a VMS shell script, was not encrypted or obscured -- its techniques were immediately apparent. It would enter a computer through the Decnet Task object -- the software interface which lets outsiders run tasks on the computer.

A VAX/VMS system manager can disable the network Task object, but the operating systems were distributed with this object enabled. Probably a third of the computers attached to the network had this object enabled, and thus were vulnerable.

On a VAX/VMS computer, the task object runs non-privileged programs; in short, it allows a networked outsider minimal access to a system. Such a port would seem to be a "safe" option, since you cannot delete someone else's files from a job running through this interface. System administrators probably felt that the minor risk of this option was well worth the convenience to users.

The December Decnet worm was copied into a non-privileged account from an outside, networked computer. Once it entered a computer, this worm copied the system greeting/banner page, and mailed it to a computer in France. The worm then mailed a greeting to every user on the system, and then attempted to randomnly infect other computers on the network. Each attack took a couple minutes -- within twelve hours, several hundred computers had been infected.

This worm implemented what the November Internet worm only hinted at: it mailed information to a central collection site. Whoever was at that computer could determine which systems were infected and (from the greeting page) what was happening at each site.

Within a month, another worm was launched on a different, private network. Remarkably similar to the December Decnet worm, this one searched for any accounts which had guessable or crackable passwords. Whenever such an account was disovered, the worm mailed the system name, account name, and password to two collection points, in distant parts of the world.

From this, we see that network worms pose dangers beyond simply denial of service. They can be efficient collectors of sensitive information. Even from unprivileged accounts they can steal information and send it to foreign systems, without knowledge of the system managers or users.


What's common to these network worms? Each caused embarrassment to the network administrators, even though some might argue that no damage was done. Two of the worms (Internet and IBM) struck enough computers to effectively disable the networked computers.

Each worm propagated through existing network interfaces. Minor security problems in networking software and protocols can be exploited by worm writers [11]. Some worm writers exploit features intended to make life easier; for example, the finger daemon and Decnet task objects. Alas, future networking software should give strangers less help and privileges.

Even the worry of a worm attack can disable computers. On April 1, 1988, rimors spread of a logic bomb in Sun workstations. Again, on February 14th, 1989, unfounded rumors were heard about a malicious Valentine's Day greeting.

Diversity is important. Networks which have a single type of operating system are much more vulnerable than heterogenious networks. Bureaucracies will forever urge a single, standardized computing system, yet a diversity of operating systems insures survival against viruses and worms. Universally adopting any one standard -- Unix, VMS, TCP/IP or OSI -- will only make worms more destructive.

Can Worms be Good?

Workers at Xerox PARC [15] have developed ways to use distribute updates to databases using techniques similar to network worms. Suppose you have many small networked computers, each with an identical database. We need to update each of these database every week or so, say with new prices or stock information.

A central computer could call into each computer, and update each database. Alternatively, each computer could send the new database to a nearby networked node, after making sure that the nearby computer has not yet been updated. The new data spreads through the network as an epidemic. Such a database updating scheme is akin to a network worm; the developers used epidemiolgical techniques [16, 17] to develop these algorithms.

These epidemic algorithms are important developments in the use of networks and distributed databases. We can expect to see them commercialized in the next few years.

However, such database updating techniques are a far cry from the malicious worms described here. The protocols are agreed upon in advance, the software is designed for the purpose, and the network traffic load is small. They are "invited" into only limited numbers of computers, and designed to ignore other computers. Research into epidemic database techniques does not require experimenting with network worms or viruses.

Directions for future work

Much computer security research is directed towards securing isolated, multi-user computers [13]. Security problems, however, seem to show up on networked computers [12, 14]. In contrast to the Orange book, computers -- especially personal comnputers and workstations -- are often used by a single person. Communication is through networks, rather than mediated through an operating sytem. The very model used to write the Orange book is inappropriate and dated.

Viruses tend to be seen on personal computers, although Cohen's original experiments were on mainframe Vaxes. Worms can run only on networked systems. which today only extensively link large computers together. In the future, we can expect personal computers to be more widely networked, opening them up to such infections. Equally worrisome: financial markets, such as stock exchanges and commodities exchange markets, are being opened to networks [9], as are telephone systems.

Providing security in these environments is challenging. Simple user authentication -- whether by password, passcard, or biometric -- is inadequate. Programs themselves are difficult to assess for logic bombs and viruses.

We need ways to certify programs against tampering. Some methods to prove that a program has not been tampered with include embedded checksums and cryptographic certification. How can I distribute software, with each user certain that it has not been infected? Future research must address these questions.

For too long, computer security has been directed towards the creation of high-sccurity, bulletproof systems. Real world computers are compromises in many ways; security is but one of these. We must find non-intrusive ways to allow the power of networking while maintaining the integrity of each computer.


  1. Eichin, M.W. and Rochlis, J.A., "With Microscope and Tweezers: An analysis of the Internet Virus of November 1988". CACM 32, June, 1989.
  2. Seeley, D. "A Tour of the Worm" in Usenix Winter 1989 Conference Proceedings. San Diego, Page 287.
  3. Spafford, E., "The Internet Worm Program: An Analysis" Computer Communication Review Vol. 19, page 1, January 1989.
  4. Internet Risks Forum, 7-22 IBM Christmas Tree Virus, December 1987.
  5. LA Times "NASA Computers Infected" 26 December 1989.
  6. Sehmemann. S. "West German Computer Hobbyists Rummage NASA Files", NY Times Sept 16, 1987.
  7. Bevington, Philip R. Data reduction and error analysis for the physical sciences, New York: McGraw-Hill, 1969.
  8. Markoff, ,4. "Computer Snarl: A Back Door Ajar" NY Times Nov. 7. 1988.
  9. Wall Street Journal Feb 3, 1989, "Chicago Commodities Exchange to Network".
  10. Rubin, Bill. "Report from the Front - The Christma Exec", Proceedings Share '72 IBM Users Group Conference, Los Angeles, CA, Feb. 28, 1989.
  11. Bellovin, S.M. "Security Problems in the TCP/IP Protocol Suite", Computer Communication Review, Vol. 19, page 32, April 1989.
  12. Stoll. C. "Stalking the Wily Hacker", CACM Vol. 31, pg 484, May 1988.
  13. National Computer Security Center. Orange Book, CSC-STD-001-83
  14. Stoll, C. The Cuckoo's Egg, Doubleday, NY. 1989.
  15. Demers, Gealy, Greene, et. al. "Epidemic Algorithms for Replicated Databse Maintenance", Xerox Palo Alto Research Center, February 7, 1989 (Also in Proceedings of the Sixth Annual ACM Symposium on Principles of Distributed Computing, Vancouver, August 1987)
  16. Bailey, N. "The Mathematical Theory of Infectious Diseases," 1975.
  17. Fraunethal, J. Mathematcal Modeling in Epidemiology. 1980.
  18. Stoll, C. How Secure are Computers in the USA, Computers and Security, Jan. 1989.

1 These papers are models of workmanship and rigor; yet the authors are academics without support to study computer security.

[Back to index] [Comments]
By accessing, viewing, downloading or otherwise using this content you agree to be bound by the Terms of Use! aka