The RISKS Digest
Volume 7 Issue 69

Thursday, 3rd 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 Virus on the Arpanet - Milnet
Cliff Stoll
o More on the virus
Gene Spafford
Matt Bishop
o A320 update
Robert Dorset via Steve Philipson
o Re: Conspiracy to Defraud
Dan Franklin
o Re: Telephone answering machines
Vince Manis
o Info on RISKS (comp.risks)

Virus on the Arpanet - Milnet

Thu, 3 Nov 88 06:46 EST
Re Arpanet "Sendmail" Virus attack November 3, 1988

Hi Gang!

It's now 3:45 AM on Wednesday 3 November 1988.  I'm tired, so don't believe
everything that follows...

Apparently, there is a massive attack on Unix systems going on right now.

I have spoken to systems managers at several computers, on both the east
& west coast, and I suspect this may be a system wide problem.

Symptom:  hundreds or thousands of jobs start running on a Unix system
bringing response to zero.

Systems attacked:  Unix systems, 4.3BSD unix & variants (eg:  SUNs) any
sendmail compiled with debug has this problem.  See below.

This virus is spreading very quickly over the Milnet.  Within the past 4
hours, I have evidence that it has hit >10 sites across the country,
both Arpanet and Milnet sites.  I suspect that well over 50 sites have
been hit.  Most of these are "major" sites and gateways.


Apparently, someone has written a program that uses a hole in SMTP
Sendmail utility.  This utility can send a message into another program.

Step 1:  from a distant Milnet host, a message is sent to Sendmail
       to fire up SED, (SED is an editor)  This is possible in certain
       versions of sendmail (see below).

2:  A 99 line C program is sent to SED through Sendmail.

3:  The distant computer sends a command to compile this C program.

4:  Several object files are copied into the Unix computer.
        There are 3 files:  one targeted to Sun
                            one targeted to SUN-3
                            one targeted to vax    (ultrix probably, not vms)

5:  The C program accepts as address other Milnet sites

6:  Apparently, program scans for other Milnet/arpanet addresses and
     repeats this process.

The bug in Sendmail:

When the Unix 4.3 BSD version of Sendmail is compiled with the Debug
option, there's a hole in it.

Most Unix systems (BSD 4.3 and Suns) apparently do not have this bug.
It exists only where the system manager recompiled Sendmail and enabled

This is bad news.

  Cliff Stoll

More on the virus

Gene Spafford <>
Thu, 03 Nov 88 09:52:18 EST
All of our Vaxen and some of our Suns here were infected with the virus.  The
virus forks repeated copies of itself as it tries to spread itself, and the
load averages on the infected machines skyrocketed.  In fact, it got to the
point that some of the machines ran out of swap space and kernel table entries,
preventing login to even see what was going on!

The virus seems to consist of two parts.  I managed to grab the source code for
one part, but not the main component (the virus cleans up after itself so as
not to leave evidence).  The way that it works is as follows:

1) Virus running on an infected machine opens a TCP connection to a
victim machine's sendmail, invokes debug mode, and gets a shell.

2) The shell creates a file in /tmp named $$,l1.c (where the $$ gets replaced

by the current process id) and copies code for a "listener" or "helper"
program.  This is just a few dozen lines long and fairly generic code.  The
shell compiles this helper using the "cc" command local to the system.

3) The helper is invoked with arguments pointing back at the infecting
virus (giving hostid/socket/passwords as arguments).

4) The helper then connects to the "server" and copies a number of files
(presumably to /tmp).  After the files are copied, it exec's a shell with
standard input coming from the infecting virus program on the other end of the

From here, I speculate on what happens since I can't find the source to
this part lying around on our machines:

5) The newly exec'd shell attempts to compile itself from the files copied over
to the target machine.  I'm not sure what else the virus does, if anything --
it may also be attempting to add a bogus passwd file entry or do something to
the file system.  The helper program has an array of 20 filenames for the
"helper" to copy over, so there is room to spare.  There are two versions
copied — a version for Vax BSD and a version for SunOS; the appropriate one is

6) The new virus is dispatched.  This virus opens all the virus source
files, then unlinks the files so they can't be found (since it has them
open, however, it can still access the contents).  Next, the virus
steps through the hosts file (on the Sun, it uses YP to step through
the distributed hosts file) trying to connect to other machines'
sendmail.  If a connection succeeds, it forks a child process to infect
it, while the parent continues to attempt infection of other machines.

7) The child requests and initializes a new socket, then builds and invokes a
listener with the new socket number and hostid as arguments (#1, above).

The heavy load we see is the result of multiple viruses coming in from multiple
sites.  Since local hosts files tend to have entries for other local hosts, the
virus tends to infect local machines multiple times — in some senses this is
lucky since it helps prevent the spread of the virus as the local machines slow

The virus also "cleans" up after itself.  If you reboot an infected machine (or
it crashes), the /tmp directory is normally cleaned up on reboot.  The other
incriminating files were already deleted by the virus itself.

Clever, nasty, and definitely anti-social.  


More on the virus attack

Peter Neumann <>
Thu, 3 Nov 1988 14:27:22 PDT
Remember that the above are preliminary messages relating to an event in
progress.  There seem to be many unanswered questions.  Perhaps someone will
contribute a definitive report to the next issue of RISKS.

Examination of the code suggests a fairly sophisticated person writing
relatively high quality (although undocumented) code, exploiting several flaws
that exist(ed) on many UNIX systems, and written with considerable good
practice in self-checking, reliability, etc.  From the evidence thus far, I
would guess it that this was a deliberate attack, not an accidental experiment
run astray. 

Although it was primarily a denial of service attack, it did some remarkable
things, taking advantage of many different approaches.  The spawned
processes appear to have been doing attacks on encrypted passwords to enable
ftps (in case the .rhost attack would not work — cf. the Stanford breakins
described in CACM and SEN by Brian Reid).  Separate versions to run on Suns
and Vaxens were apparently propagated in DES encrypted form, decrypted, and
both programs tried to see which one would work.

We quoted Henry Petroski here over a year ago to the effect that we do not
learn from our successes, but that we have an opportunity to learn from our
failures.  Once again we are presented with the opportunity to learn that many
of our computer systems have serious security vulnerabilities, and that we need
to take pains to defend against the really malicious attacks.  Strangely some
people take heart in the fact that the security attacks to date (whether
penetrations, exploitations of privilege, Trojan horses, or legitimate viruses)
have been relatively modest in scale, perhaps to justify the absence of
concern.  I am afraid that it will take a Chernobyl- or Three-Mile-Island-like
disaster before the community at large wakes up.  PGN

More on the virus

Matt Bishop <bishop@bear.Dartmouth.EDU>
Thu, 3 Nov 88 16:32:25 EST
...  This program introduced itself through a bug in sendmail.  At these sites,
sendmail was compiled and installed with a debugging option turned on.  As near
as I can figure (I don't have access to the sendmail sources), by giving a
specific option to the "debug" command in sendmail (there are lots of those,
controlling what exactly you get information about) you can cause it to execute
a command.  As sendmail runs setuid to root, guess what privileges the command
is executed with.  Right.
   Apparently what the attacker did was this:  he or she connected to sendmail
(ie, telnet victim.machine 25), issued the appropriate debug command, and had
a small C program compiled.  (We have it.  Big deal.)  This program took
as an argument a host number, and copied two programs — one ending in
q.vax.o and the other ending in .sun.o — and tried to load and execute them.
In those cases where the load and execution succeeded, the worm did two things
(at least):  spawn a lot of shells that did nothing but clog the process table
and burn CPU cycles; look in two places — the password file and the internet
services file — for other sites it could connect to (this is hearsay, but I
don't doubt it for a minute.)  It used both individual .rhost files (which it
found using the password file), and any other remote hosts it could locate
which it had a chance of connecting to.  It may have done more; one of our
machines had a changed superuser password, but because of other factors we're
not sure this worm did it.
   This last part is still sketchy; I have the relevant sun.o file and will
take it apart to see just what it was supposed to do.  As of now, it appears
there was no serious damage (just wasted CPU cycles and system administrator
   Two obvious points:
1.  Whoever did this picked only on suns and vaxen.  One site with a lot
    of IRISes and two Crays (ie, NASA Ames) got bit on their Suns and Vaxen,
    but the attempt to get the other machines didn't work.
2.  This shows the sorry state of software and security in the UNIX world.
    People should NEVER put a program with debugging hooks in it, especially
    when the hook is (or can be made) to execute an arbitrary command.  But
    that is how the sendmail which was used was distributed!
   One more interesting point:  initially, I thought an application of the
"principle of least privilege" would have prevented this penetration.  But
the attacker used a world-writeable directory to squirrel the relevant programs
in, so — in effect — everything could have been done by any user on the
system!  (Except the superuser password change, of course — if this worm
did in fact do it.)
   I think the only way to prevent such an attack would have been to turn
off the deug option on sendmail; then the penetration would fail.  It goes to 
show that if the computer is not secure (and like you, I don't believe there
ever will be such a beastie), there is simply no way to prevent a virus (or,
in this case, a worm) from getting into that system.
   I know this is somewhat sketchy, flabby, and fuzzy, but it's all I know
so far.  I'll keep you posted on developments ...


A320 update

Steve Philipson <>
Mon, 31 Oct 88 11:39:11 PST
Henry Spencer's recent article on the A320's first six months in
service states that the fly-by-wire system has "behaved perfectly."
It should be noted, however, that the article he was referring
to clearly pointed out that there were failures of the primary 
flight guidance computer, which were rectified by backup systems.

More information from Flight:

 From Flight International, 9/24/88:

"Five months after entry into commercial service with Air France, British
Airways, and Air Inter, Airbus Industries' A320 fly-by-wire 150-seat
airliner still has many teething problems, but fewer than other Europ-
ean or American transport aircraft in their first year, say the man
ufacturers and operators [Note: Air France and BA have been running
rather old fleets for a LONG time]

"Air France's Airbus A320 Ville de Paris, on flight AF914 from Paris
to Amsterdam on August 26, had to turn back shortly after takeoff 
from Charles de Gaulle with 81 passengers on board.  A series
of warnings included a toilet fire indication, which subsequently
proved to be a false alarm.

"When the pilot attempted to land the aircraft, yet another warning
light erroneously indicated that the landing gear was not down.  The
A320 made a pass over the airport, and the control tower confirmed 
that the landing gear was down.  A second pass was then made, and
Air France ground engineers andmechanics confirmed that the gear
was down. The pilot made a perfect landing, although the computer
display system displayed many false warnings.

"Passengers on the A320, which had taken off 40 min. late because of
heavy traffic, had to transfer to two other aircraft, causing a 
4 hr delay.  

"The faulty A320 was grounded for two days pending thorough checks,
but is now back in regular service to Dusseldorf, Amsterdam, and

"Earlier, on August 19, an Airbus A320 belonging to French domestic
carrier Air Inter reported a double power failure on a flight from
Nice Cote d'Azur to Paris.  According to a computer system warning,
the auxilliar power unit broke down at the same time as one of the
two main generators, a little while before landing at Orly airport.
The pilot made a safe landing, as his aircraft still had three
additional power sources--the second main generors, batteries, and 
the other auxilliary power unit.

"On March 28, Air France's Ville de Paris had encountered similar pro-
blems on its inaugural flight over Paris and the Champs Elysees with
then Prime Minister Jacques Chirac and 150 other passengers.

"Since entry into commercial service, only three per cent of A320 flights
have been delayed beyond the accepted 15 min. by technical problems, says
Airbus Industrie technical vice-president Bernard Ziegler.  'This 97
per cent rate of technical regularity is very close to the best aircraft
in service, which have attained 98 per cent or 98.3 per cent,' he says.
"For a brand new aircraft with revolutionary avionics and fly-by-wire,
the A320 hasmade a remarkable achievement.'

The loss of Air France's third A320, Ville d'Amsterdam, at Mulhouse
Habsheim airport during a local aero club rally on June 26, with three
dead and 50 injured among its 153 joyriding passengers, has caused
great concern, although the aircraft has been cleared of any malfunc-
tion and the accident was  attributed to pilot error.  Air Inter's
pilots' union added to the general concern by striking in protest 
against the A320's two-man crew [but largely on the basis of pay and
seniority, with safety as a propaganda gimmick].

'Every day in Europe, five airliners on average turn back for various
technical reasons,' says Bernard Ziegler.  'That does not make news.
But when the A320 is one of the five, then the mass media cries out.
That's the rule of the game.  But we are satisfied the A320 is all
right--nothing wrong with it.  It's a very good plane.'

Any new aircraft undergoes a series of technical adjustments in its
first months of operation, he notes.  'It took Boeing two-and-
a-half years for the 757, a year for Airbus Industrie with the A300,
and hopefully it will only take us nine months for the A320,' says

I find Ziegler's rationale for the failures of the A320 somewhat 
disturbing.  With only a handful of airplanes in service, for any
significant percentage of in-flight or on-ground failures to occur,
and then say it should be compared to the massive fleets of existing
aircraft, is to obfuscate the issue.

His confidence in the A320's backup electrical systems is also rather
odd, considering the airplane's susceptibility to transient controls,
and his company's failure to provide even a mediocre cabin lighting
control system.

Re: Conspiracy to Defraud

Tue, 01 Nov 88 16:39:47 -0500
Re the Confederation of British Industry's proposal to change the law on
defrauding to include deception of computers as well as people:

To state the obvious, computer programs are so limited in their ability to
understand what someone might be trying to do, and what information is
necessary for that purpose, that it's often necessary to "deceive" them just to
get them to do the right thing.  It's much like the problem of figuring out
what to put on a complex form, like tax forms: every individual situation is
different, and the form either provides no way at all to say what your
situation is, or provides several equally plausible ways to express it.  But at
least forms have margins, and you can attach additional pieces of paper to
them.  Computer-based "forms" have neither.

Here's an example: in the process of trying to provide some service, a computer
asks for my telephone number.  I don't believe it has any right to that number
for this purpose, so I refuse to answer.  But it won't go on to the next query
until I answer that one.  I find someone in charge: "I don't want to give my
phone number out.  Is that OK?"  "Sure.  Just give it a fake number and go on."
The computer is now "deceived".  It's ridiculous to think that both I and the
computer's owner could now be charged with fraud!

Taken literally, such a law would also preclude thorough testing of computer
software.  In testing, you're almost always "deceiving" the computer in order
to see whether it will handle some case correctly, particularly if you're
checking error handling.  Are testers going to have to insert special routines
that print out "It's OK, I know this is a test" before giving any answers, to
avoid prosecution?

There are also serious theoretical problems with the notion of "deceiving" a
computer.  In theory, deception occurs when an individual is deliberately led
to believe X when not-X is true.  But what does "belief" mean when applied to a
computer system?  If I have a file on a computer system that says I'm 3 years
old, does that mean the computer "believes" I'm three years old?  Of course
not, you say.  What if it's in a database?  Is it deception then?

I think it's all the fault of some AI people who would like us to think that
all it takes to be able to say that a computer system believes a fact is that
it's in a Lisp-based inference system that includes a "believes" predicate!

    Dan Franklin

Re: Telephone answering machines

Vince Manis <>
Tue, 1 Nov 88 16:30:36 PST
I was concerned about security when I bought a new answering machine this
spring. I finally settled on a GE model which has an 8-bit security code (which
you set in octal!), believing that a search space of 256 is large enough.
(There--all you have to do is look me up in the phone book and you have enough
information to crack my code. Some people are just not security-conscious

The search space seemed large enough on the following grounds:

1) there aren't many answering machine hackers around;

2) I rarely store confidential data on my machine;

3) people aren't patient enough to call a number 256 times just to break in.

Now, what I'm surprised at is that this is *exactly* the reasoning that those
operating computers have used, and I knew that at the time, having read lots of
papers on security. I hadn't even thought about only allowing non-destructive
operations, though again this is something that anybody who has ever used
anonymous ftp knows about immediately.

Am I overreacting, or is it really better to say that those who are cognisant
of history are also doomed to repeat it?

Vincent Manis, Manager, Instructional Laboratories, 
Department of Computer Science, University of British Columbia

Please report problems with the web pages to the maintainer