The RISKS Digest
Volume 7 Issue 76

Saturday, 12th November 1988

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…


o Computer Literacy #2
Ronni Rosenberg
o A Report on the Internet Worm
Bob Page in VIRUS-L
o NSA attempts to restrict virus information
Jon Jacky
o Who is responsible for the sendmail fiasco?
Bob Frankston
o Info on RISKS (comp.risks)

Computer Literacy #2

Ronni Rosenberg <>
Wed, 9 Nov 88 16:43:58 EST
A typical computer-literacy course has the following components.  What do you
think of this operational description of computer literacy?  Should other
topics be taught instead? in addition to these?  Should everyone study this?
As before, send mail to RISKS or to me, depending on your preference.

1. TERMINOLOGY AND JARGON:  This is designed to enable students to "talk
knowledgeably" about computers.  Here are some definitions of a computer, from
computer-literacy textbooks:
 *  "A computer is an electronic machine that solves problems or answers
 *  "A computer ... is a machine that can handle large amounts of information
    and work with amazing speed."
 *  "A computer is an electronic tool that helps people do many different
    things faster, easier, or better."

Here is another definition, from a graduate computer-literacy class (for
teachers, administrators, computer coordinators, and so on):
 *  "An operating system is a program that tells the computer how to deal with
    information — tells it how to move information, how to operate, how to
    do things. ...  An operating system is done in a lower level language,
    machine language.  It really controls the flow of electricity through the

2. HARDWARE:  This is designed to give students a "working knowledge of
computer equipment."  Typical classes use Apple IIs.  The last large surveys
show a national average of 1 machine per 40 students (grades K-12).  Many
schools cannot afford two disk drives per machine.  A computer lab of 10-30
machines might have 1-3 printers (dot matrix).  Devices such as joysticks,
mice, and touch-sensitive displays are too expensive for most schools to buy
(or these devices operate on machines that are too expensive), but some
schools buy one of each, to pass around a class.  The emphasis is on
identifying components and handling equipment (e.g., floppy disks).  A 1988
survey showed that among 11th grade students:
 *  30% did not know what a cursor does,
 *  60% did not know what a modem does, and
 *  40% could not identify a spreadsheet as a software component or a video
    display as a hardware component.

3. SOFTWARE:  Exposure to "basic software concepts" is designed to enable
students to use computers as tools and to "remove the mystery of computers."
Typical classes show programs for word processing (which predominates),
spreadsheets, and databases — ones that run on Apple IIs (or, in many cases,
smaller machines).  Students do not see actual program documentation.  The
emphasis is on the syntax of program commands.  The survey cited above showed
that students scored
 *  72% correct on word-processing questions
 *  52% correct on spreadsheet questions
 *  31% correct on database questions

4. PROGRAMMING:  When included, this means BASIC or LOGO programming.  Again,
the emphasis is on learning the syntax of some language commands.  Miniscule
programs (e.g., 10 lines) predominate.

5.  JOBS IN COMPUTING:  When included, this means brief discussion of careers
in computing.  There is a widespread sense that "computer literacy" is the
passport to well paying jobs.

6.  SOCIAL IMPACTS OF COMPUTERS:  When included, this encompasses computer
uses, ethics, and legal implications.  Under uses, students might be told, for
instance, that the FBI uses computers to store data on criminals and crimes,
but not about privacy risks, data quality problems, etc.  Students might be
told that some people lose jobs because of computer automation — and that
these people can get other jobs working with computers.  Ethics means a mention
of computer crime.  Legal implications means a warning that students should not
copy software disks they use in class.  Students are explicitly encouraged to
have "positive attitudes about computers."  Topics not covered include
whistleblowing, the military influence on the computer profession, limits of
simulations, and risks of large computer systems.

(long) report on the Internet Worm

Ken van Wyk <luken@SPOT.CC.LEHIGH.EDU>
Fri, 11 Nov 88 13:57:42 EST
                     A REPORT ON THE INTERNET WORM

                               Bob Page
                          University of Lowell
                      Computer Science Department

                            November 7, 1988

     [Because of the many misquotes the media have been giving,
     this report is Copyright (c) Bob Page, all rights reserved.
     Permission is granted to republish this ONLY if you republish
     it in its entirety.]

Here's the scoop on the "Internet Worm".  Actually it's not a virus -
a virus is a piece of code that adds itself to other programs,
including operating systems.  It cannot run independently, but rather
requires that its "host" program be run to activate it.  As such, it
has a clear analog to biologic viruses — those viruses are not
considered live, but they invade host cells and take them over, making
them produce new viruses.

A worm is a program that can run by itself and can propagate a fully
working version of itself to other machines.  As such, what was loosed
on the Internet was clearly a worm.

This data was collected through an emergency mailing list set up by
Gene Spafford at Purdue University, for administrators of major
Internet sites - some of the text is included verbatim from that list.
Mail was heavy since the formation of the list; it continues to be on
Monday afternoon - I get at least 2-3 messages every hour.  It's
possible that some of this information is incomplete, but I thought
you'd like to know what I know so far.

The basic object of the worm is to get a shell on another machine so
it can reproduce further.  There are three ways it attacks: sendmail,
fingerd, and rsh/rexec.


In the sendmail attack, the worm opens a TCP connection to another
machine's sendmail (the SMTP port), invokes debug mode, and sends a
RCPT TO that requests its data be piped through a shell.  That data, a
shell script (first-stage bootstrap) creates a temporary second-stage
bootstrap file called x$$,l1.c (where '$$' is the current process ID).
This is a small (40-line) C program.

The first-stage bootstrap compiles this program with the local cc and
executes it with arguments giving the Internet hostid/socket/password
of where it just came from.  The second-stage bootstrap (the compiled
C program) sucks over two object files, x$$,vax.o and x$$,sun3.o from
the attacking host.  It has an array for 20 file names (presumably for
20 different machines), but only two (vax and sun) were compiled in to
this code.  It then figures out whether it's running under BSD or
SunOS and links the appropriate file against the C library to produce
an executable program called /usr/tmp/sh - so it looks like the Bourne
shell to anyone who looked there.


In the fingerd attack, it tries to infiltrate systems via a bug in
fingerd, the finger daemon.  Apparently this is where most of its
success was (not in sendmail, as was originally reported).  When
fingerd is connected to, it reads its arguments from a pipe, but
doesn't limit how much it reads.  If it reads more than the internal
512-byte buffer allowed, it writes past the end of its stack.  After
the stack is a command to be executed ("/usr/ucb/finger") that
actually does the work.  On a VAX, the worm knew how much further from
the stack it had to clobber to get to this command, which it replaced
with the command "/bin/sh" (the bourne shell).  So instead of the
finger command being executed, a shell was started with no arguments.
Since this is run in the context of the finger daemon, stdin and
stdout are connected to the network socket, and all the files were
sucked over just like the shell that sendmail provided.


The third way it tried to get into systems was via the .rhosts and
/etc/hosts.equiv files to determine 'trusted' hosts where it might be
able to migrate to.  To use the .rhosts feature, it needed to actually
get into people's accounts - since the worm was not running as root
(it was running as daemon) it had to figure out people's passwords.
To do this, it went through the /etc/passwd file, trying to guess
passwords.  It tried combinations of: the username, the last, first,
last+first, nick names (from the GECOS field), and a list of special
"popular" passwords:

aaa          cornelius        guntis      noxious    simon
academia      couscous        hacker      nutrition    simple
aerobics      creation        hamlet      nyquist    singer
airplane      creosote        handily      oceanography    single
albany          cretin        happening      ocelot    smile
albatross     daemon        harmony      olivetti    smiles
albert          dancer        harold      olivia    smooch
alex          daniel        harvey      oracle    smother
alexander     danny        hebrides      orca        snatch
algebra          dave        heinlein      orwell    snoopy
aliases          december        hello      osiris    soap
alphabet      defoe        help      outlaw    socrates
ama          deluge        herbert      oxford    sossina
amorphous     desperate        hiawatha      pacific    sparrows
analog          develop        hibernia      painless    spit
anchor          dieter        honey      pakistan    spring
andromache    digital        horse      pam        springer
animals          discovery        horus      papers    squires
answer          disney        hutchins      password    strangle
anthropogenic dog        imbroglio      patricia    stratford
anvils          drought        imperial      penguin    stuttgart
anything      duncan        include      peoria    subway
aria          eager        ingres      percolate    success
ariadne          easier        inna      persimmon    summer
arrow          edges        innocuous      persona    super
arthur          edinburgh        irishman      pete        superstage
athena          edwin        isis      peter        support
atmosphere    edwina        japan      philip    supported
aztecs          egghead        jessica      phoenix    surfer
azure          eiderdown        jester      pierre    suzanne
bacchus          eileen        jixian      pizza        swearer
bailey          einstein        johnny      plover    symmetry
banana          elephant        joseph      plymouth    tangerine
bananas          elizabeth        joshua      polynomial    tape
bandit          ellen        judith      pondering    target
banks          emerald        juggle      pork        tarragon
barber          engine        julia      poster    taylor
baritone      engineer        kathleen      praise    telephone
bass          enterprise    kermit      precious    temptation
bassoon          enzyme        kernel      prelude    thailand
batman          ersatz        kirkland      prince    tiger
beater          establish        knight      princeton    toggle
beauty          estate        ladle      protect    tomato
beethoven     euclid        lambda      protozoa    topography
beloved          evelyn        lamination      pumpkin    tortoise
benz          extension        larkin      puneet    toyota
beowulf          fairway        larry      puppet    trails
berkeley      felicia        lazarus      rabbit    trivial
berliner      fender        lebesgue      rachmaninoff    trombone
beryl          fermat        lee          rainbow    tubas
beverly          fidelity        leland      raindrop    tuttle
bicameral     finite        leroy      raleigh    umesh
bob          fishers        lewis      random    unhappy
brenda          flakes        light      rascal    unicorn
brian          float        lisa      really    unknown
bridget          flower        louis      rebecca    urchin
broadway      flowers        lynne      remote    utility
bumbling      foolproof        macintosh      rick        vasant
burgess          football        mack      ripple    vertigo
campanile     foresight        maggot      robotics    vicky
cantor          format        magic      rochester    village
cardinal      forsythe        malcolm      rolex        virginia
carmen          fourier        mark      romano    warren
carolina      fred        markus      ronald    water
caroline      friend        marty      rosebud    weenie
cascades      frighten        marvin      rosemary    whatnot
castle          fun        master      roses        whiting
cat          fungible        maurice      ruben        whitney
cayuga          gabriel        mellon      rules        will
celtics          gardner        merlin      ruth        william
cerulean      garfield        mets      sal        williamsburg
change          gauss        michael      saxon        willie
charles          george        michelle      scamper    winston
charming      gertrude        mike      scheme    wisconsin
charon          ginger        minimum      scott        wizard
chester          glacier        minsky      scotty    wombat
cigar          gnu        moguls      secret    woodwind
classic          golfer        moose      sensor    wormwood
clusters      gorgeous        morley      serenity    yaco
coffee          gorges        mozart      sharks    yang
coke          gosling        nancy      sharon    yellowstone
collins          gouge        napoleon      sheffield    yosemite
commrades     graham        nepenthe      sheldon    zap
computer      gryphon        ness      shiva        zimmerman
condo          guest        network      shivers
cookie          guitar        newton      shuttle
cooper          gumption        next      signature

[I wouldn't have picked some of these as "popular" passwords, but
then again, I'm not a worm writer.  What do I know?]

When everything else fails, it opens /usr/dict/words and tries every
word in the dictionary.  It is pretty successful in finding passwords,
as most people don't choose them very well.  Once it gets into
someone's account, it looks for a .rhosts file and does an 'rsh'
and/or 'rexec' to another host, it sucks over the necessary files into
/usr/tmp and runs /usr/tmp/sh to start all over again.

Between these three methods of attack (sendmail, fingerd, .rhosts)
it was able to spread very quickly.


The 'sh' program is the actual worm.  When it starts up it clobbers
its argv array so a 'ps' will not show its name.  It opens all its
necessary files, then unlinks (deletes) them so they can't be found
(since it has them open, however, it can still access the contents).
It then tries to infect as many other hosts as possible - when it
sucessfully connects to one host, it forks a child to continue the
infection while the parent keeps on trying new hosts.

One of the things it does before it attacks a host is connect to the
telnet port and immediately close it.  Thus, "telnetd: ttloop: peer
died" in /usr/adm/messages means the worm attempted an attack.

The worm's role in life is to reproduce - nothing more.  To do that it
needs to find other hosts.  It does a 'netstat -r -n' to find local
routes to other hosts & networks, looks in /etc/hosts, and uses the
yellow pages distributed hosts file if it's available.  Any time it
finds a host, it tries to infect it through one of the three methods,
see above.  Once it finds a local network (like 129.63.nn.nn for
ulowell) it sequentially tries every address in that range.

If the system crashes or is rebooted, most system boot procedures
clear /tmp and /usr/tmp as a matter of course, erasing any evidence.
However, sendmail log files show mail coming in from user /dev/null
for user /bin/sed, which is a tipoff that the worm entered.

Each time the worm is started, there is a 1/15 chance (it calls
random()) that it sends a single byte to on some
magic port, apparently to act as some kind of monitoring mechanism.


Three main 'swat' teams from Berkeley, MIT and Purdue found copies of
the VAX code (the .o files had all the symbols intact with somewhat
meaningful names) and disassembled it into about 3000 lines of C.  The
BSD development team poked fun at the code, even going so far to point
out bugs in the code and supplying source patches for it!  They have
not released the actual source code, however, and refuse to do so.
That could change - there are a number of people who want to see the

Portions of the code appear incomplete, as if the program development
was not yet finished.  For example, it knows the offset needed to
break the BSD fingerd, but doesn't know the correct offset for Sun's
fingerd (which causes it to dump core); it also doesn't erase its
tracks as cleverly as it might; and so on.

The worm uses a variable called 'pleasequit' but doesn't correctly
initialize it, so some folks added a module called _worm.o to the C
library, which is produced from:
        int pleasequit = -1;
the fact that this value is set to -1 will cause it to exit after one

The close scrutiny of the code also turned up comments on the
programmer's style.  Verbatim from someone at MIT:
    From disassembling the code, it looks like the programmer
    is really anally retentive about checking return codes,
    and, in addition, prefers to use array indexing instead of
    pointers to walk through arrays.

Anyone who looks at the binary will not see any embedded strings -
they are XOR'ed with 81 (hex).  That's how the shell commands are
imbedded.  The "obvious" passwords are stored with their high bit set.

Although it spreads very fast, it is somewhat slowed down by the fact
that it drives the load average up on the machine - this is due to all
the encryptions going on, and the large number of incoming worms from
other machines.

[Initially, the fastest defense against the worm is is to create a
directory called /usr/tmp/sh.  The script that creates /usr/tmp/sh
from one of the .o files checks to see if /usr/tmp/sh exists, but not
to see if it's a directory.  This fix is known as 'the condom'.]


None of the ULowell machines were hit by the worm.  When BBN staffers
found their systems infected, they cut themselves off from all other
hosts.  Since our connection to the Internet is through BBN, we were
cut off as well.  Before we were cut off, I received mail about the
sendmail problem and installed a patch to disable the feature the worm
uses to get in through sendmail.  I had made local modifications to
fingerd which changed the offsets, so any attempt to scribble over the
stack would probably have ended up in a core dump.

Most Internet systems running 4.3BSD or SunOS have installed the
necessary patches to close the holes and have rejoined the Internet.
As you would expect, there is a renewed interest in system/network
security, finding and plugging holes, and speculation over what
will happen to the worm's creator.

If you haven't read or watched the news, various log files have named
the responsible person as Robert Morris Jr., a 23-year old doctoral
student at Cornell.  His father is head of the National Computer
Security Center, the NSA's public effort in computer security, and has
lectured widely on security aspects of UNIX.

Associates of the student claim the worm was a 'mistake' - that he
intended to unleash it but it was not supposed to move so quickly or
spread so much.  His goal (from what I understand) was to have a
program 'live' within the Internet.  If the reports that he intended
it to spread slowly are true, then it's possible that the bytes sent
to were intended to monitor the spread of the
worm.  Some news reports mentioned that he panicked when, via some
"monitoring mechanism" he saw how fast it had propagated.

A source inside DEC reports that although the worm didn't make much
progress there, it was sighted on several machines that wouldn't be
on its normal propagation path, i.e. not gateways and not on the same
subnet.  These machines are not reachable from the outside.  Morris
was a summer intern at DEC in '87.  He might have included names or
addresses he remembered as targets for infesting hidden internal
networks.  Most of the DEC machines in question belong to the group he
worked in.

The final word has not been written - I don't think the FBI have even
met with this guy yet.  It will be interesting to see what happens.

NSA attempts to restrict virus information

Fri, 11 Nov 88 18:56:45 PST
The following excerpts are from THE NEW YORK TIMES, Nov 11 1988 p. 12:


Government officials are moving to bar wider dissemination of information 
on techniques used in a rogue software program that jammed more than 6,000
computers in a nationwide computer network last week.

Their action comes amid bitter debate among computer scientists ... One group
of experts believes wide publication of such information would permit
computer network experts to identify problems more quickly and to correct 
flaws in their systems.  But others argue that such information is too 
potentially explosive to be widely circulated.

Yesterday, officials at the National Computer Security Center, a division of 
the National Security Agency, contacted researchers at Purdue University in
West Lafayette, Ind., and asked them to remove information from campus
computers describing internal workings of the software program that jammed
computers around the nation on Nov. 3. ...  (A spokesperson) said the agency
was concerned because it was not certain that all computer sites had corrected
the software problems that permitted the program to invade systems in the 
first place. ...

Some computer security experts said they were concerned that techniques
developed in the program would be widely exploited by those trying to break
into computer systems. ...

- Jonathan Jacky, University of Washington

Who is responsible for the sendmail fiasco?

Wed Nov 9 01:42:09 1988
The lesson from the PC world is that we can assign official responsibility to
the system administrators but in practice they should not be expected to have
the expertise.  The expertise lies with those distributing turnkey workstation
systems.  Sun?  Berkeley??
                                             Bob Frankston

Please report problems with the web pages to the maintainer