A formal definition of computer worms and some related results

Computers & Security, 11 (1992) 641-652
A Formal Definition
of Computer Worms
and Some Related
Results
F. 6. Cohen*
ASP,P.O.Box81270,Pitt.sburgh,PA1521?, USA
In this paper, we propose a formal definition of ‘computer
worms” and discuss some of their properties. We begin by
reviewing the formal definition of “computer viruses”, and
their properties. We then define “computer worms” as a sub-
class of viruses, and show that many of the interesting ptop-
erties derived for viruses hold for worms. Finally, we
summarize results, draw conclusions, and propose further
work.
Keywords: Computer viruses, Computer worms.
1. Background
A n informal definition of “computer viruses”
was first published in 1984 b
was soon followed by his forma r
Cohen [l], and
definition first
published in 1985 [2] based on Turing’s model of
computation [3]. An alternative formal definition
was proposed by Adleman [4] in 1989 based on set
theory. In each of these cases, detection of viruses
was shown to be undecidable, and several other
results were derived.
These definitions were quite general in scope, and
covered a broad range of replicating programs,
possibly including the as yet only poorly defined,
but widely used term *worm”. Unfortunately, the
*Funded by ASP, P.O. Box 81270. Pittsburgh, PA 152 17, USA.
lack of an adequate and standard definition of
worms has created numerous misinterpretations
and wasted time, and few of the results on worms
have gone beyond the speculative phase. In this
paper, we address this problem.
We begin here with an informal discussion by
presenting a pseudo-code example of a very simple
virus:
v: = [F = RANDOM-FILE-NAME; COPY v TO F;]
This virus simply replicates into files with random
names, and is unlikely to be successful in any
current computing environment because the
chances are very poor that any of the replicas will
ever be run. Even if they were run, they would not
perform the functions the programs they replaced
performed prior to replication, and thus would be
rapidly detected. Since these replicas are of no
practical value, they would likely be destroyed.
More purposeful viruses, both malicious and
benevolent, have been shown to be quite powerful,
primarily due to their prodigious reliability and
ability to spread. Viruses have also caused quite a
problem in some environments.
The first published scientific references to com-
puter worms that we are aware of came from
0167-4048/92/$5.00 0 1992, Elsevier Science Publishers Ltd. 641

E B. Cohen/A Formal Definition of Computer Worms
Shoch and Hupp [S], who described several experi-
ments with
4
rograms which replicated segments of
themselves or parallel processing over a network.
Unfortunately, no formal definition followed, and
no sample code was provided. This left an unfilled
void, and a host of informal but widely varying
discussions using the poorly defined term followed
in the literature.
Recently, the term “worm” has been widely used to
describe programs that automatically replicate and
initialize interpretation of their replicas.’ By
contrast, the definition of viruses covers all self-
replicating programs but does not address the
manner in which replicas may be actuated. Here is
a pseudo-code example of a simple worm:
W: = [F = F&DO~~-FILE-NAME;C~IY W TO F;RUN F;]
With the ability to replicate comes a host of other
issues. The most obvious issue is that a replicating
program might exhaust all of the available
resources in a system, thus causing a system failure.
In the case of this worm in a uniprocessing
environment, the system eternally runs replicas of
the worm, and no other processing can take place
while the worm runs. In a multiprocessing
environment, well-designed worms may be able to
coexist safely with other programs if they are
limited in their replication and evolution so as not
to seriously impact performance.
Another important aspect of viruses is their ability
to “carry” additional code with them. For example,
in the 1984 paper [l], pseudo-code was provided
for a compression virus, a denial of services virus,
and other examples. The early worm experiments
I
51 solved large problems by including subprob-
ems in replicas, thus allowing them to solve parts
of the problem using remote resources. More com-
monly used viruses include the ‘diskcopy” pro-
gram provided with the DOS operating system,
‘This idea was first brought to my attention in a paper
published in Computers and Security in which Thomas A. Long-
staff and E. Eugene Schultz describe several Lwormsn.
which, in certain environments, replicates and
carries along the contents of the entire disk on
which it resides; product installation programs,
which replicate as part of their installation process;
and backup programs which make copies of them-
selves and other programs on other media to
improve system reliability.
Another interesting feature of self-replicating pro-
grams is their resilience. In environments where
non-replicating programs often fail or are destroyed
through errors or omissions, viruses seem to thrive.
This is because of the natural redundancy provided
by replication. In this environment, viruses seem to
be more fit than non-viral programs.
From a protection standpoint, viruses offer unique
problems. Their resilience makes then very hard to
remove from an operating environment, while
their transitive spread bypasses most modern pro-
tection methods. General-purpose detection is
undecidable [1,2, 41,while special-purpose methods
are not cost effective [o]. There are many other
interesting properties of self-replicating programs.
We refer the interested reader to some of the
recent literature in this area [6].
In the remainder of this paper, we will formalize
the notion of worms, describe how that formal-
ism leads very quickly to a series of conclusions
about worm properties, show how these results
impact multiprocessing and multiprocessor
environments, discuss some of the potentials for
both malicious and benevolent worms, describe a
number of historical incidents, summarize results,
draw conclusions, and propose further work
2. Some Formalities
Cohen [2] presents “Viral Sets” in terms of a set of
“histories” with respect to a given machine. A viral
set is a set of symbol sequences which, when inter-
preted, causes one or more elements of the viral set
to be written elsewhere on the machine in all of
the histories followin
B
the interpretation. We
include here some o the relevant definitions
642

Computer and Security, Vol. 11, No. 7
M:(s~, I~, 0,: sMxIM-IM, NM: SMxIM+S,w 4,: WG-+d)
Jv=jo... a}
Y={l...=J}
&={s O,...JnI, nfE.9
IM={i,,...,ij}, jE#
“natural” numbers)
positive “integers”)
states)
tape symbols)
where:
d={-l,O, +1}
S,:Af/l/-S,
q,:&-xJv-+I,
PM:JVN-N
head motions)
state over time)
tape contents over time)
(current A! cell at each time)
Box 1
I [vcI*] Ufld[ME&] U#dVOE TnJHV& jEJ
[[P!=j]d [S,=&] d (‘I,j,...,‘i,,+~“~-I)= v]*
3v’E V, 3t’, t”, j'%V and t’> t
(1)
(4
(3)
[[(j'+I4)Gj]0r[(j+I4>~j’]l and
[(ql+‘P I’Jy”f(-,)= v’] and
[3t”[t<r”<t’] and [P,.Ej',...,j'+Iv'I-l]]
Box 2
required for the remainder of the paper, starting
with the definition of a set of Turing-like [3] com-
puting machines “L# * as in Box 1.
The “history” of the machine HIMis given by
g9
0, P),2 the “initial state” is described by
07 q,, PO), and the set of possible AZ tape sub-
sequences is designated by I*. We say that;
“For convenience, we drop the M subscript when we are deal-
ing with a single machine except at the first definition of each
term.
M is halted at time twV’t’> t, H,= H,f, (t,t’~N);
that
M haltso3tE.&‘, M is halted at time 1;
that p “runs” at time t-the “initial state” occurs
when PC, is such that p appears at q,.,,“; and that
p runs@%EN, p runs at time t. The formal
definition of the viral set (W) is given in Box 2.
The interested reader is referred co [2] for details.
643

17B. Cohen/A Formal Definition of Computer Worms
3. Definition of Computer Worms
We define a “Worm Set” w as a viral set in which any worm (w) that is run at some move i results in a
worm w’ being run at some subsequent time i’ (Box i). ’ ’
VMVW(M, W)EW-
[WI*] and [ME&q and VWE WVHVC,jE.N
[[pl=j ] and[sl=sCJ]and(‘l,j,‘..rOr.j+lw(-l)= w]*
3w’E W3t’, t”, l”‘,j’EJV,f’> I
0)
(2)
(3)
(4)
[[(j’+ Iw’I)q] or [(i+ M)q’]] md
[(ot,;+.,•,~,j~+iru’i_,)=W’] Und
W[t<r”<t’] und[P,~Ej’,...,j’+Iw’(--l] and
3t”‘[C’< t”‘] and [Pp =j’] and [Sp = So]
Box 3
Translated into English, this means (approximately):
(M, W) is a “worm set” if and only if:
all worms in W are AZ sequences -and- M is a A? -and-
for each worm w in W, for all histories of M,
for all times t and cells j
if the tape head is in front of cell j at time t -and-
A is in its initial state at time t -and-
the tape cells starting at j hold the worm w -then-
there is a worm w ’ in I+‘, a time t’ > t, and place j ’ such that
(1) at a place j ’ not overlapping worm w
(2) the tape cells starting at cell j ’ hold worm w ’ -and-
(3) at time t” between t and t’, worm w’ is written by M -and-
(4) at some later time t”‘, worm w’ is run by M
The definition of W is different from that of W
only in condition 4 being added, and because this
term is an “and” on the right side of an implica-
tion, WCW. We normally refer to elements of
V,(M, V)E Y for a given machine M as “viruses”
on M, and in the same parlance we will refer to
members of W,(M, W)E W for a given machine M
as “worms” on M. We typically drop the “on M”
when we are referring to a particular M, and make
statements like “all worms are viruses”.
It turns out that most of the examples used for
proofs about viruses [2] were not only viruses but
also worms by the present definition, and thus
the proofs apply directly. The remaining proofs
do not depend on the lack of condition 4 above,
and thus most of them arc also true for worms.
For the purpose of brevity, we list some of the
useful results for viruses that also hold for worms,
along with page numbers from the cited work:3
‘Some of these require a trivial modification to the sample M
so that instead of halting after replicarion, M moves the tape
head to rhe start of the replica and changes to state S,,.
644

Computer and Security, Vol. 7I, No. 7
PI2 Theorem 1
P13 Lemma 1.1
P’4 Theorem 2
P14 Theorem 3
PI9 Theorem 4
P21 Theorem 5
P23 Theorem 6
P25 Lemma 6.1
P26 Theorem 7
A union of Ws is a W.
3 “largest” W for any machine M.
3 %mallestn Ws ( Wmin)for some M.
3 Wminof every size iE9 for a universal ./%.
There are uncountable Ws for some M.
Every sequence of symbols is a worm on some M.
Worm detection is undecidable.
Detecting evolutions of a known worm is undecidable.
Worm evolution is as general as .& computation.
Another interesting result of this definition is that
once a worm runs, M can never halt! More
formally:4
Theorem A:
Vw E W,(M, W) C W, w runs =+M never halts.
This is because at all times after w runs, there
is always another WE W that must run at a sub-
sequent time. More formally, assume 3wG W,(M,
W)C W and w is run at time t. Then by condition
4 in the definition:
31”’> t:[J+ =j ‘1 and [S,. = S”]
and by condition 2 of the definition:
(o,.,,,, ,...) 0 t”‘.,‘+,lu’,-,)= w’
Thus w’ is run at time r”‘! But if any WE W is run
at any time t (specifically, w’ at time Y), we return
to the previous situation. By the induction
theorem, if a condition is true at some time 1 and if
being true at time t implies it is true at time t + 1, it
‘We use letters for theorems and lemmas herein to avoid con-
flicts with the theorem numbering from cited works.
is true for all time t’ > t. By condition 3 of the
definition:
VtEN, 2” > t: [& = So] and If” > t: P,. # P,
so by definition, VH,M is not halted at time t, or in
other words, M never halts. Thus a system running
a worm has the “liveliness” property.
Lemma A. 1:
VwE W’,(M,W)E W, M halts*jtEN, w runs at
time t.
4. Multiprocessing Environments
In a multiprocessing environment, worms are quite
different than in a uniprocessing environment. For
example, in a multiprocessing environment, a
worm need not dominate processing. With proper
controls on replication, a stable system can be put
in place to attain desirable levels of worm activity.
Here is a simple example in which a system func-
tion ok returns the number of currently active wk
worms:
COPY W,TOFRUNFJF [Oh> @XT;]]
645

E B. Cohen/A Formal Definition of Computer Worms
In this k limits the number of worms in the
system. Each worm will replicate until k total
worms are in the system. From that point on, each
worm will wait until there are k or fewer worms in
the system, replicate, and then exit. Assuming we
have a fair scheduler and an accurate ok we get a
relatively stable population of worms.
The I#, worms could implement ok by updating a
commonly accessible integer, by using unique pro-
cess names in the process table, by associating
themselves with files stored in a particular area, or
by any other interprocess communication method
available on the system.
In order to model this sort of environment and
show properties of worms, we require additional
structure, but we don’t want to abandon the
mathematics associated with Turing machines in
the process. This model extension is provided by
the “Universal Protection Machine” [2] (S), which
is implemented on a universal A? (A!), and pro-
cesses moves from each of a finite set of J%S
simulated on M by using a “scheduler” and a
“special state” which implements “system calls”.
This machine is defined as:
.9:(M,S,O,R,f:Sx O-R,%‘)
where:
ME& an “interpretation unit”
S=(So,..., si), i ES a set of ?ubjects”
O=(oO,..., ~,)JEY a set of “objects”
R=(r,,,..., rk),kE# a set of “rights” of Ss over OS
f :(S x 0 *R) a protection matrix [8]
9 = ((s,o)~,...,(A o),),1e.f a “run sequence” of sub-
jects “running” objects
When a subject interprets an object (i.e., (s,~)EL@)),
M uses the rights of s for the duration of the inter-
pretation of o. We are particularly interested in the
rights “read” (I) and “write” (w), because these
translate into the flow (f) of information between
subjects. (i.e., s,wo, and syro,* s.~&) [lo]. This is
alternatively expressed as:
Information flow is transitive (i.e., s,fs and
syjz* S.&J when M is a universal & [2f, and
using this model a vital result that viruses can
spread to the transitive closure of information flow
from the source subject was derived.’ This is
because 39 in which each subject in the transitive
closure of information flow, in turn, interprets an
object modified by the virus interpreted by a sub-
ject previously in the information flow from the
original virus source.
In any “fair” scheduler with unbounded work to be
done and assuming that all accessible programs are
run with some non-zero frequency, such an A?
will eventually be realized because there will
always be a partial subsequence of 9 in which
each of the necessary objects will be interpreted in
sequence [2].
It turns out that the same result is, in general, true
for worms, but transitivity doesn’t result simply
from running replicas. That is, if no object is modi-
fied by subjects running the worm, and if we
ignore all other causal factors (e.g., a progenitor of a
worm is run by some other user independent of the
actions of the worm under consideration), only
subjects with direct access to the worm can run it.
Mathematically:
(M,W’)EW,QaE W, Qb4 W, Q&3?,QsGS
j(s,b)e andQ(s,a)~,(s,b)Bw~dH,:b~ W
We will call worms that do not output to any
objects “pure worms” (Wp).By definition,
5Page 35 [2].
646

Computer and Security, Vol. I 1, No. 7
~runs a*(s,a)Er,
so
Theorem B:
This implicitly assumes that R is static with res
to s and a over the period of the operation oP
ect
the
worm. If this is not the case, the situation may be
far more complex because, in general, it is undecid-
able whether at some future time, ($,a)~ r will be
true [8]. This does not seem to be important in the
short term; however, over the long term, there are
often cases where momentary lapses in protection
parameters could cause the undesired extension of
rights. Once extended, of course, such rights
cannot necessarily be revoked from a pure worm
because the worm is operating with the authority
of the subject that invoked it. Even though the
right to invoke the worm may have been removed,
all of the operating instances of replicas of the
worm cannot necessarily be terminated without
massive denial of service. This situation is partially
covered by the “time transitivity” analysis used for
viruses [lo].
We anthropomorphize objects containing worms
by sayin that a worm (w) has been granted the
rights oHa subject (S)OS runs Tut W,(M, I&‘)Ew,
and we express this as w +S (read w gets s). If only
the creator of a pure worm has direct access to it, it
follows that the rights of all replicas will be limited
to the rights of the originator, since only the
originator can run it and, by definition, rights are
only extended to objects by virtue of the subjects
that interpret them. More generally, a pure worm
only gets the subjects who run it:
Lemma B. 1:
VwEW,, WCS-S runs w.
In the case of pure worms, evaluating the worst
case impact of time variations on the protection
state is trivial. Every subject that is ever granted
direct access to w is potentially impacted, and all
other subjects are completely safe from its direct
impact. This model ignores performance impacts
because the Turing machine model of computation
generally assumes that moves take no time, and is
used primarily to analyze the possibilities rather
than the practicalities of any particular situation. A
more realistic impact assessment is to assume that
all users operating on all machines where there is
an impacted user are impacted because of the per-
formance degradation effects of the worm on those
machines. This is an area for further research.
In a uniprocessing environment, because worms
always run their replica, they are a bit harder to
intentionally control than non-worm viruses
because there is no obvious way to reduce the
population. For viruses, however, this is not the
case. For example, the following virus (v~) limits
itself through the use of a name space:
0,: = [F = RANDOM-DIGIT;COPY V, TO F;]
Since the digits consist only of (0...9), the total
number of copies of v, is limited (i.e., they over-
write each other). We can trivially extend this
result to any &rite-sized name space. Even a virus
which optionally runs replicas can be controlled by
a semaphore mechanism to adapt to the require-
ments of the environment. For example, the
following viral variant (vi) on the previous worm:
V,: = [WHILE TRUE 110 (F$,F” = MN~~M-FI~~-NA~sJF [q> ~]EX.IT;
IF [U, < k/2][COPY V, TO F AND F’;WUN F AND F’;];COPY V, TO F”JKJN F”;]]
In this case, vi exists without replication while there
are more than k replicas operating, and replicates at
a higher rate if less than k/2 replicas are present.
Thus, there is a stronger drive for replication when
the population is low, while death becomes promi-
nent when population is high. This too can be
generalized to provide varying drives for survival of
the species as a function of population.
647

F. B. Cohen/A Formal Definition of Computer Worms
Most multiprocessing environments have mechan-
isms whereby one process can force another pro-
cess to stop processing. These can be used by
worms as a means of population control. For
example, a pair of worms (w, ,wJ could be used to
form a stable population ratio by spending some
portion of their time forcing the other to halt (i.e.,
“kill” another process):
W,: = [WHILE [ 0, > k2], kL.L A W,; PAUSE ; REPLICATE;]
W2: = [WHILE [(7, > k,], KILL A W,; PAUSE ; REPLICATE;]
As long as at least one of each w, and wa are active,
and finding and killing processes takes far less than
the duration of a “pause”, the system will regain a
balance at k, and k, respectively of w, and wa. If
instead of simply waiting, each worm performed
some useful functions requiring relatively little
time, we would have a useful worm computation
environment. We can call this a 2-worm system,
and it is simple to extend the principle to an n-
worm system as follows:
w,: = [Vi < n [WHILE [ai> k;], &LL A w,;];
PAUSE; REPLICATE;]
By makin an n-worm system for large n, we may
dramatica ly improve overall system reliability. InK
one experimental implementation, we used an n-
worm to perform regular maintenance tasks on a
UnixTM system. In this case, the worms deleted old
temporary files and “core” files, regenerated data-
bases, killed errant processes, and performed other
regular maintenance functions. The result was an
Yecosystemn in which almost no systems adminis-
tration was required for continued operation over a
four-year period.
Despite the potential practicality of worms in
multiprocessing environments, we have encoun-
tered more destructive worms than practical ones
in the global multiprocessing environment, and
early experiments with practical worms have
occasionally resulted in problems. In 1985, an
experimental worm in a UnixTM environment
replicated until the maximum number of processes
available to the user were consumed. At that point,
all of the replicas were forced into a wait state
because they could not create new replicas until
some other replica failed. It turned out that in this
case there was no way to stop the worm except
through a system reboot, because we couldn’t kill
all of the processes simultaneously, and as soon as
one was killed, another replica was created. The
inherent priorities of the scheduler made the prob-
lem unresolvable. This worm did no serious harm,
because all of the replicas were in wait states, and
consumed no critical resource.
Another worm which impacts multiprocessing
environments is commonly called a “paging
monster”. A paging monster simply copies itself
into each of a series of pages in memory, cycling
through memory periodically. In most paged
virtual memory systems, this worm forces the
system paging program to page out other processes
at a very high rate, and thus forces the system to
thrash. By combining the UnixTM worm described
above with the paging monster, the situation can
become far more damaging, because you cannot
eliminate the paging monsters by simply killing
processes.
We return for a moment to Lemma B. 1.In each of
the examples given above, the worms were pure
worms run by a single user, and although they had
an impact on the system, in each case, no rights
were extended to them beyond those granted to the
user who created them. By directly limiting the
impact of a single user on system behavior and
prudent use of standard access controls, we can
protect users in a multiprocessing environment
from severe damage due to pure worms. We don’t
have to worry about the transitive closure of rights
in this case.
There is a temptation to try to extend Lemma B.l
to cover non-pure worms whose modifications to
other objects don’t cause those objects to include
worms, but this doesn’t work for two reasons. The
648

first reason is that any modification could be inter-
preted by some M’ simulated by interpreting some
third object so as to make the modification intro-
duce a worm for machine M’. For any universal
.H, there always exists such an M’. The second
reason is that we would have to exclude all modi-
fications that might eventually result in the genera-
tion of a worm. For example, multiple separate and
independent modifications, none of which intro-
duces a worm for some machine M, could generate
a worm through their combined action. The only
cases where we may be able to extend Lemma B.l
are cases where M is not a universal .M , which is of
relatively little interest in most modern computing
environments; and the case where information
flow is closed under transitivity.
5. Multiprocessor Environments
Just as multiprocessing environments provide
unique opportunities for worms and viruses to per-
form useful or malicious functions, multiprocessor
environments have features that impact the effec-
tiveness of worms and viruses. There are several
important cases in the modern environment to
consider because of their large numbers. They are
(loosely):
l Tightly coupled systems where processors effec-
tively share all non-processing resources for
improved performance.
l Shared f;‘le sysfemr where multiple processors
effectively share a file system either directly or
through networking.
l Remote procedure calls where processes on remote
processors can invoke local processes.
0 Remote Zogins where remote users can run pro-
grams on local machines by logging in and invok-
ing commands.
l File transfer andforward systems where remote users
can send files to or through local machines.
We don’t yet know a great deal about protection
from worms and viruses on these systems other
than the general results previously published on
viruses. There are, however, some interesting
points to be made and some possible areas of
research to be explored.
In tightly coupled systems, processors are essen-
tially not distinguishable from a protection stand-
point, and thus they can be treated as a single
system. At the other extreme, in file transfer and
forward systems, remote processors have limited
functionality, and while they can be impacted by
large numbers of network requests, livelock, and
deadlock of the network, etc., with nominal pro-
tection in the form of setting low priorities for
remote file transfers and limited function interfaces
for incoming files, almost all impact from remote
systems can be eliminated.
Systems allowing remote logins dominate in the
timesharing arena, with almost every timesharing
system now providing remote login over modems,
and networked systems allowing remote login
through explicit “remote shell” and “remote login”
network calls. In much of the modern computing
environment, remote login is permitted to known
users without additional authentication, and in
cases where this is not typical it is common to pro-
vide login scripts for accessing remote systems
using known user identities and passwords. The
increased standardization of this process makes the
extension of rights from machine to machine very
simple.
For example, it is simple to write a worm program
that attempts remote logins to hosts which are
allowed to login to the current host (since reci-
procity is the norm in the modem computing
environment). Assuming this has some success, the
worm can replicate into the new system and
operate from there, attempting to extend privileges
to a new machine. By combining this mechanism
with known attacks, the worm may attempt to
attain increased privilege. Once increased privilege
is attained, the worm has more candidates available
649

F. B. Cohen/A Formal Definition of Computer Worms
for remote and thus mechanism to
privilege still A simple that guesses
on remote once access
attained works well because, pass-
word is relatively and a of
user and limited on the
is commonly A lack audit trails
this sort attack also keep the simple
and
The mechanism remote procedure is often
to implement operations in
where special exist in
machines. For a local server may
all of incoming mail keep desired
lists available that the
doesn’t have be duplicated the
network, it is to provide
printer access that expensive that don’t
to be can be The key
is that remote operation made very
and transparent that user is maxi-
This in provides capabilities remote
processors local processing file storage,
other system To the that the
is less ideal, this
possibilities for and viral
A shared system provides means by a
user make a available to multitude of
with great For example,
planting a in a called “1~“~
offerin users to another in the
%irectory, users may fooled into
to that and running When
they that, and their search is set
as most users’ search are set the
local will be which will the worm.
the designer a bit the “1s” will
first or rename then perform
system’s “1s” and then itself, thus
its presence to the observer.
6”ls”is the name of the Unix directory program used by most
users to see what files arc in a directory. ‘1s” is also the most
frequently run program under Unix according to statistics
taken in the first virus experiments in 1984.
650
The effect of the shared file system is to make this
sort of access far more likely and casual. In most
shared file system environments, this mechanism
can be used to effectively im act
machines in the environment. A sK
all of the
ared file system,
even if most of it is read-only to any given user,
provides a very high bandwidth and easy-to-
exploit environment for worms and viruses. It
facilitates the execution of programs by remote
processors under conditions that grant the program
access to the remote user’s privileges instantly and
with no additional authentication required. Even a
pure worm can spread throughout such a system
with relative ease, and a virus that “infects” files
should typically be able to take over the entire
network of shared file system machines in very
short order. Based on the timesharing experiments
with viruses [I], it would not be surprising to see
the vast majority of the network fall to attack in
under an hour.
The current trend in distributed computing envi-
ronments is toward the shared file system situation,
and without some substantial effort to provide pro-
tection in this environment this is a disaster waiting
to happen. The current protection techniques,
which effectively allow a systems administrator to
prevent read or write access to a file system or on a
directory or file basis restrict access to particular
areas of a file system, are completely inadequate for
protection against viruses and worms. In the
current environment, each site protects itself only
against intrusion caused by outside agents, whereas
in the case of worms and viruses the intrusion
comes from inside agents (i.e., the users on the
impacted system running external programs).
6. Some More Specific Examples
Remote process invocation makes the problem of
malicious worm control in a multiprocessor
cnvironmcnt far more difficult. As examples, the
UnixTM remote procedure call facility, the Novclle
‘The scqucncc of places the command interpreter looks to find
a program.

NetWareTM add-on packages that allow remote
command execution on workstations, and the
DecNetTM remote command interface, each pro-
vide rich environments for uncontrolled worm
spread.
Even though these systems may limit the author-
ized remote users who may invoke these facilities,
this is ineffective against worms because they
spread transitively. Thus, unless the transitive
closure of machines with users authorized for
remote process invocation is a closed subset of the
systems or none of the users ever runs a worm, all
of the members of the environment are susceptible.
Here we see that in the case of worms in a remote
process invocation environment, just as in the case
of viruses in general, transitive spread results in a
partially ordered set of infectable users from any
given source, and just as in the case of viruses,
nearly all of the networked computers in the world
today are susceptible.
Even very simple worms in the environment today
wreak widespread havoc, and just as viruses may
evolve in a very general fashion thus making eradi-
cation very difficult, worms may evolve with the
same generality. In the case of worms, the problem
is particularly unnerving because of the require-
ment for concerted action throughout a distributed
network.
For example, the Internet worm [o], which did not
evolve, required concerted action, but this action
was made easy because the attack depended on a
“bug” which was easily repaired, and because all of
the replicas were essentially identical. If this worm
had evolved during replication in a substantial
manner, and had not depended on a “bugn, but
rather on the legitimate rcmotc procedure call
capability of UnixTM, the eradication problem
would have been far more severe. The worm
experiments that went awry at Xerox [j] required a
concerted network-wide reboot and the UnixTM
worm described earlier required a system reboot.
Returning again to Lemma B. 1, even in the casts of
these relatively severe network worms no extension
of privileges was achieved. In other words, theI
systems extended the privileges exploited by these
worms to their originator, either by design or
implementation error. The worms did not gain
privileges by being run unknowingly by users with
special rights, they were granted system rights by
exploiting flaws in the systems they attacked.
7. Summary and Further Work
We have provided a mathematical definition of
“computer worms” that we feel reflects the current
usage and reconciles many of the inconsistencies in
recent literature. We have listed several important
properties of worms and systems containing worms,
and derived several new results that are specific to
specific sorts of worms. We have shown several
methods by which self-controlled worms and
viruses can coexist with other programs in multi-
processin and multiprocessor environments, and
that wea L esses exist in current multiprocessing
environments which facilitate uncontrolled worm
spread.
In future papers, we hope to present theoretically
sound defenses for specific subclasses of worms and
criteria for the safe coexistence of some viruses and
non-viral programs. A number of other subclasses
of viruses also appear to be of interest, and we
believe that theoretical results may guide us toward
improved defenses against many subclasses of
viruses currently exploited by attackers,
We encourage other researchers to examine and
challenge our definition with mathematical altcr-
natives. As we stated earlier, the lack of a mathe-
matical definition has caused numerous problems
in this area, and we hope that this presentation of
one will lead to substantial progress.
References
[i] F. Cohen, Computer viruses: theory and experiments,
DOLMV73.S 7111Conference on Compukr Srcuriry, originally
appearing in IFIP-set 84 (1984), also appearing as invited
paper in IFIP-TCl 1, Comput Secur., 6 (January 1987).
22-35, and other publications in several languages.
651

F. B. CohenlA Formal Definition of Computer Worms
[2] F. Cohen, Computer Viruses, ASP Press, Pittsburgh, 1985,
subsequently approved as a dissertation at the University
of Southern California, 1986.
[3] A. Turing, On computable numbers, with an application
to the Entscheidungsproblem, London M&z. Sot. Ser. 2,
1936.
[4] L. Adleman, An abstract theory of computer viruses,
Crypro-89.
[j] J. Shoch and J. Hupp, The “worm” programs: early expcri-
ence with a distributed computation. CACM (March
1982). 172-180.
Fred Cohen received a B.S. in Elcctri-
cal Engineering from Carnegie-Mellon
University in 1977, an MS. in Informa-
tion Science from the University of
Pittsburgh in 198 1, and a Ph.D. in Elrc-
trical Engineering from the University
of Southern California in 1986. He was a
professor of Computer Science and
Electrical Engineering at Lehigh
University from January 1983 through
April 1987, and a professor of Electrical and Computer
Engineering at The University of Cincinnati from September
of IY87 through Dccembcr of 1988. He is currently the Presi-
dent of ASP in Pittsburgh, PA, U.S.A.
Dr. Cohen has published over 20 refereed papers and over 20
other professional articles, has written several graduate level
texts, and has designed and implemcntcd numerous devices
and systems for information protection. He is most well known
for his ground-breaking work in compurcr viruses. where he
did the first in-depth mathematical analysis, performed many
startling experiments which have since been widely confirmed.
and developed the first protection mechanisms, many of which
are now in widespread use. His current rcscarch interests are
concentrated in high integrity systems.
[6] C. Langton (ed.), Arfij%al Life, Addison-Wesley, Reading,
MA, 1989.
[7] J. Kochlis and M. Eichin, With microscope and tweezers:
the worm from MIT’s perspective, C4CM. 32 (June
1989).
[8] M. Harrison, W. Kuzzo and J. Ullman, Protection in
operating sysrems, CACM, 1Y (August 1976). 46 I-47 1.
[Y] F. Cohen, A cost analysis of typical computer viruses and
defenses, IFIP-TCl 1, Camput. Sew., 10 (IYYl) 23Y.
[lo] F. Cohen, Protection and administration of information
networks under partial orderings, IFIP-TCl 1, Cmput.
Sew., 6 (1987). 118- 128.
652

A formal definition of computer worms and some related results

More Related Content

Similar to A formal definition of computer worms and some related results (20)

More from UltraUploader (20)

A formal definition of computer worms and some related results