The RISKS Digest
Volume 13 Issue 01

Monday, 6th January 1992

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…


Customer Clogs Honda 800 number
Sanford Sherizen
Life-and-Death Computer
Warren M. McLaughlin
AIDS Computer Virus
Caesar Chavez
Snow at San Jose ???
John Pettitt
ZIP+4 and privacy
Douglas W. Jones
Infra-red bar-coded security cards forgeable by laser printer
George Michaelson
Hot sun on car dash obliterates thermal printer output
George Michaelson
Screensaver doing "nothing" might be a resource hog
Karl Swartz
Recommended: Hamming's "The Art of Probability"
Doug Jensen
Review: A Pathology of Computer Viruses
Gene Spafford
Re: Airbus Fuel Monitoring
David C. Martin
Info on RISKS (comp.risks)

Customer Clogs Honda 800 number

Sanford Sherizen <>
Thu, 2 Jan 92 21:57 GMT
The Boston Globe (December 30, 1991) reported that a disgruntled Honda owner
called its "Better Business Bureau Information Line" toll-free customer
relations number so many times that he clogged the line.  He did the same to
other 800 numbers used primarily by Honda employees and dealers.  In both cases,
he presumably used an automatic redialing mechanism (daemon dialer).  He then
began tying up a Honda facsimile number by transmitting muti-page letters during
a four-day period.

American Honda Motor Co. says that it was forced to ask AT&T to step in and
block the calls which allegedly came from a Holliston, Mass home.  However, AT&T
security said that it also had to block any calls to the Honda numbers for the
entire 508 area code, which covers west and north of Boston.  Attempts to reach
the Holliston complainer was not possible since his phone is unlisted!

I seem to remember that a televangelist's number was tied up in a similar
fashion a few years ago and there has been rumours of political candidates'
phones being plugged by their competition.  How common is this form of
destructive behavior?

It will be interesting to see whether AT&T does some form of call or line
blocking on this individual.  How can phones be made open except for certain
parties who overstep bounds?  When are there too many calls and when is the line
crossed into harassment?  Is this a case where caller ID would have "proven"
harassment?  Under what conditions is someone no longer allowed "phone rights?"
Was the Los Angeles judge's denial of telephone use by Ian Mitnick to prevent
him from connecting to a computer in any way related in a legal sense to this
present incident?

Good story to end 1991.  The year of ousted regimes, stalled economies, and
phone disorders.  Sort of an updated version of Sex, Lies, and Videotapes,
to be called Lex, Slides, and Telegaps.

Sanford Sherizen, Data Security Systems, Inc., Natick, MA 01760

Life-and-Death Computer

"Warren M. McLaughlin" <McLaughlin@DOCKMASTER.NCSC.MIL>
Sun, 5 Jan 92 13:21 EST
The Washington Post, 5 Jan 1992, page C6 (the editorial page):

  As technologies become more powerful, the distinction between a helping tool
and a decision-making tool keeps gaining importance.  Nowhere is this clearer
than in the case of the new diagnosis-aiding computers, which offer doctors the
benefit of a gigantic data base — far larger than their own experience could
be — compiled from the results of many thousands of cases nationwide.  By
conglomerating and analyzing the results of these cases, the computer can read
out a series of alternative treatments, a probability rating on the success of
a given procedure or — most controversially — the statistical risk of a
patient's dying upon arrival in an intensive care unit in a given condition.
Physicians with access to such a machine now bear a responsibility at least as
weighty as that of diagnosis itself: that of balancing the computer's seemingly
precise numbers and instant certainties with the knowledge that its results are
dependent upon human judgement.

  According to the staff in a Michigan hospital using a program of this type
called APACHE, the computer's predictions of a patient's statistical
probability of dying — calculated to two decimal points — are used strictly
as tools, rather as any doctor might estimate, say, a 10 percent chance of
survival from a given operation.  A better description of risk, in that
scenario, need not govern the doctor's (or the family's) decision as to whether
the risk should be taken, only inform it better than individual experience ever
can.  But the incomplete results of a different study performed in France
suggested that doctors with access to that kind of risk data were more likely
than others to terminate care.  The fear among practitioners is that hospital
administrators or health bureaucrats, all increasingly beleaguered and pushed
by public pressure toward cost-cutting, might see computer-confirmed statistics
on death risk as a road to easier triage.

  Given the capability for vastly enhanced diagnosis by means of computers, the
medical profession will be stuck with the same responsibility — also vastly
enhanced — as before: first, to recognize that a computer can serve the cause
of accurate diagnosis only on the basis of properly entered information by the
physician using his or her senses; second, to keep in mind a fact much of the
general public has trouble with, which is that a statistic about the
probability of an event bears no causal relationship to that event.  A person
with a 95 percent chance of dying under a procedure is not the same thing as a
person whom that procedure cannot help, or a person from whom care can be
withheld with no compunctions.  Obscure that distinction, and you take a step
toward making the computer the master — a bad one.
                                                               - Mike
PO Box 54, Bridgewater, VA 22812-0054

AIDS Computer Virus

Fri, 3 Jan 1992 04:32:47 PST
Remember that "AIDS Computer Virus" that was distributed about two years ago?
The following article appeared in Information Week on December 16, 1991 on page
         Caesar Chavez

                                - - - - - -

"A bizarre British court case involving computer viruses has pointed up the
vulnerability of users with careless policies on PC software.

"Hearing the case of a U.S. scientist accused of computer blackmail late last
month, the court granted a stay after lawyers successfully argued that the
defendant, Joseph Popp, 41, was mentally ill.  Popp was facing 11 charges of
damaging computer systems and attempting to obtain a total of 6 million pounds
($10.7 million) through blackmailing numerous medical institutes worldwide
around Christmas 1989.

"Popp is alleged to have mailed more than 20,000 floppy disks to the research
institutes.  He promoted the disks as containing valuable information about
AIDS.  But the disks themselves contained a software virus, which has since
also been dubbed AIDS.  When users tried to access the disk, they got messages
demanding 200 pounds  (about $350)  to eradicate the virus that had just
infected their systems.

"Popp was extradited to the United Kingdom, where a chorus of scientists from
universities and research institutes claimed that their software had been
damaged when the disks were loaded onto their systems.

"One organization that fell foul of the virus was the Imperial Cancer Research
Fund in London.  Dr. Ron Catterall, director of the fund's computer research
unit, was called as a witness for the prosecution.  Catterall was smart: He
loaded the disk onto his standalone PC rather than the network, and warned
other users as he discovered the virus.  `It took a long time to find out what
was going on, and to clean up my machine,' he said.  `It eventually started
overwriting the hard disk.'
                                           Philip Hunter."

Snow at San Jose ???

John Pettitt <>
Tue, 31 Dec 91 09:54:53 PST
The FAA has an on line pilot briefing sysem called DUAT (Direct User Access
Terminal).  The version of the service I use is provided by Contel Federal
Systems.  For those who are not familiar with aviation weather the raw data is
supplied in a very cryptic form.  To make simplify things for users DUAT has a
decoder that expands this into `english'.

However last night the FT (Terminal Forecast - a 24 hour forward forecast) for
both San Jose (SJC) and San Francisco (SFO) was showing 3 VBSY which was being
decoded as:
                Visibility 3 in snow and blowing spray

There seem to be two possible causes:

1) a decode error (I don't know what the correct decode of VBSY is)
2) VBSY does mean snow and spray and the NWS screwed up the forecast.

Either way computer weather briefing has a way to go yet.

John Pettitt, Specialix International     (

    [In response to my comment that Mt Hamilton is east of San Jose and
    Mt Diablo east of Oakland, and they do get snow now and then, John noted
    that the terminal forecast is for conditions on the airport and within
    the Airport Traffic Area (ATA), which is 5 miles radius.  <"Anyway, I
    called the DUAT help desk and they thought the idea of snow was rather
    a good joke - `another bug for the list'."  (John)>  PGN]

ZIP+4 and privacy

Douglas W. Jones,201H MLH,3193350740 <>
2 Jan 92 22:58:44 GMT
I recently asked at my post office how many houses shared the same ZIP+4 code
with my house.  The answer was that if I lived in a single-family dwelling, I
almost certainly have a unique ZIP+4 code.

I note that the USPS now provides a complete database of ZIP+4 addresses in the
country — it is on CDROM, and it is included in the postal exhibit in
Chicago's Museum of Science and Industry, where you can type in your address
(as you would on a letter), and it gives you your ZIP+4 in response.  I tried
it on my address here in Iowa, and it worked correctly.

The risk I see in this is that statistical data that has traditionally been
available sorted by ZIPcode (for example, census data) may be released broken
down by ZIP+4 codes.  If this is done, it destroys any promise of
confidentiality for such data.

Of course, there is a benefit — you should be able to send mail to me with
only a ZIP+4; no need to mention city, state, street, or house number.

                    Doug Jones

infra-red bar-coded security cards forgeable by laser printer

George Michaelson <>
Sat, 4 Jan 1992 12:54:31 +1100
They handed the cards out in alphabetical order to staff, and the barcodes/card
numbers were congruent and the batch was sorted. Skilled person (not self)
examined 3 in sequence, calculated trivial encryption and checksum algorithm
used, inferred card for senior member of staff, used Public Domain code to
generate barcode strip on apple laserwriter, glued to card and swiped through
lock. bingo! instant access to secured areas, leaving calling card of selfsame
high-up all over the online logs.

Infra-Red readers also handle normal light codes. Good eyes can read thick/thin
sequences in strong light so even if numeric code on card doesn't match bars,
its forgeable. Infra-Red also pretty trivial to obtain as it UV reader.

I really think the local admin/security people have been blinded by science.
Apart from anything else the electromagnets which operate the doorlocks look
very subvertable. Another instance of hindering the novice and legitimate,
whilst barely impeding anybody intent on skullduggery.

Hot sun on car dash obliterates thermal printer output.

George Michaelson <>
Sat, 4 Jan 1992 12:47:55 +1100
Buy parking ticket @ 40c per hour. Vending machine has current TOD, allocates
ticket to nearest 20 minutes to be displayed clearly on dashboard of parked
car. Shows purchase time, and expiry time in large letters.

Come back to car 7 hours later. It has been a hot muggy day, around 35C at the
peak. Car was parked in full sunlight, and is dark (rusty!) brown.  Interior
could well have been 40C or over. (certainly felt sauna-ish inside)

Entire parking voucher is black. Either the spot heat, the continual lower
background heat, some emitted vapour from the car interior, or all three has
made it do a disappearing fax trick in reverse. Illegible unless scrutinized
at close range, certainly not readable through window.

I hope nobody's using one of these to do "permanent" chart recording or
whatever in hot locations...

Screensaver doing "nothing" might be a resource hog

Karl Swartz <>
Fri, 3 Jan 92 0:07:51 PST
This afternoon, a colleague at SLAC (the Stanford Linear Accelerator Center)
was showing me the latest screen lock and saver program he had obtained for his
workstation, a port of the one often found on Suns.  This reminded me of an
incident several years ago when I was visiting my friend George Berg.

George is a professor of computer science at SUNY Albany, known in the
department for his AI programs that run for days or even weeks at a time on
several SPARCstations, grabbing every available CPU cycle.  Over the weekend,
George dialed in from home to check on the progress of his latest project and
was a bit surprised to find that it seemed to be running much more slowly than
it had during the week.  When a later checkup again showed minimal progress he
began to invistigate, and found that the machine was indeed busy — running
Life on the unused screen in his office!  After disabling the screen saver the
real work continued on without further competition.

Getting back to SLAC today, this is quite relevent as some of our computing
tasks involve many essentially unrelated events, work that can easily be farmed
out to machines on the network with cycles to spare.  Obviously productive use
of our resources depends on users understanding that "their" machine isn't
necessarily free to simulate life, compute pi to a million decimal places, or
enumerate the nine billion names of God just because they aren't in the office.
It's also easy to forget just how many resources some "cute" program can use.

Karl Swartz  uunet!decwrl!ditka!kls  1-415/854-3409
2144 Sand Hill Rd., Menlo Park CA 94025

Recommended: Hamming's "The Art of Probability"

"DOUG JENSEN, DTN 223-1201, M.S. PKO3-1/22D" <>
Wed, 1 Jan 92 17:45:56 PST
I have recently been reading Richard Hamming's book "The Art of Probability,"
(Addison Wesley, 1991) and wish to strongly commend it to those of you who
haven't yet seen it. Please allow me to whet your appetite with the following
brief excerpts.

"This one man's opinion using a rather more scientific (as opposed
to mathematical) approach  to  probability than is usual."

"Most  authors of probability books present one version of probability as if
it  were the true and only one. On the contrary, we have carefully developed
a sequence of models on what seems to be a reasonably scientific approach."

"The  model  of  probability you adopt is often relevant to what actions you
later  take,  though  most statistics books do not make plain and clear just
what  is  being assumed. Unfortunately, many times the statistical decisions
affect  our  lives, from health, medicine, pollution, etc. to reliability of
power plants, safety belts vs. air bags, space flights, etc."

"The  weak  law of large numbers encourages one to think that the average of
many repetitions will give an estimate of the underlying probability. But we
have seen...that the number of trials necessary to give an accurate estimate
of  the probability may be much more than we can ever hope to carry out. And
there  are  further  difficulties.  We  assumed  the  existence of the mean;
suppose  it  does  not exist! (see the next Section 8.7). It is not that the
author  is  opposed  to  statistics--there is often nothing else to try in a
given  situation--but  the  stated reliabilities that statisticians announce
are  often  not  realized  in  practice.  Unfortunately,  the foundations of
statistics,  and  its applicability in many of the situations in which it is
used, leaves much to be desired, especially as statistics will probably play
an increasingly important role in our society."

Review: A Pathology of Computer Viruses

Gene Spafford <>
31 Dec 91 23:09:21 GMT
I recently received a copy of "A Pathology of Computer Viruses" by
David Ferbrache of the UK Defense Research Agency.  The book is
copyrighted 1992, and is published by Springer-Verlag (ISBN
3-540-19610-2 and 0-387-19610-2).  US price was $39.50. 300 pages.

This book is an extraordinarily comprehensive book on the history, theory, and
operation of computer viruses, and on virus countermeasures.  It is the most
complete book I have seen on the topic to date, and contains a very detailed
description of how PC viruses work and spread, including viruses in networked
environments, viruses in Amiga systems, and viruses in Unix.  In fact, I expect
David to get some criticism for the detail he presents, but it serves to make
the subject matter much clearer.

Chapter 1 is a general introduction to the topic of viruses, worms, and
malware.  Chapter 2 is devoted to the history of viruses and "malware" starting
from the 1960s and thru the end of 1990.  It has a very complete description of
the earliest viruses, including some events and activities that have not been
generally reported elsewhere.  It also includes interesting information on
related activities, such as the founding of the Virus-L mailing list.

Chapter 3 is a nice introduction to the theory of computer viruses, including
discussion of how computer viruses relate to biological viruses, and other
related topics such as artificial life.

Chapter 4 is a detailed discussion of how viruses operate in an IBM PC
environment.  This includes details on camouflage techniques and signatures as
well as spread and activation.  Chapter 5 provides extensive discussion of
techniques to protect against computer viruses.  Chapter 6 is a description of
how viruses work in the Apple Macintosh.  Chapter 7 discusses viruses in
mainframes and Unix systems.

Chapter 8 is devoted to "network viruses" — worms.  This includes analysis of
early work, the Morris Worm, WANK, Christma Exec, and even a discussion of
e-mail chain letters!  The chapter also has a nice discussion of Internet
protocols that lend themselves to abuse by malicious code.

Chapter 9 is a chapter discussing reactions of the computing community,
including some legislative history and information on the formation of response
teams.  Chapter 10 is a brief statement about the future of the problem.

The book concludes with 18 appendices, listing everything from the DOS
filestore structure to a PC virus family tree to all the CERT advisories to
date.  One of the appendices provides an extensive reading list.

Overall, the book is one of the best books on computer viruses I've seen.
David's illustrations are clear and his prose is quite readable.  I found
information and details in this book that I have not seen in any other virus
book.  The section on the history of computer viruses, in particular, is quite
well done.

There are some small problems with the book, however.  First of all, I was very
disappointed that there were almost no footnotes or citations in the body of
the book.  As I read through the material I noted material that I wished to
pursue further — unfortunately, there were no citations to allow me to seek
original sources.  I do not doubt the accuracy of the information presented,
but I feel that the lack of specific citations is a flaw in such a scholarly

The book suffered from spotty copy-editing.  I found many places where there
were quite obvious typos.  In a few places, these typos obscured the text's
meaning or distorted some information.  I am not sure whether to fault the
author or the publisher, but is is sad to see in an otherwise excellent book by
an established publisher.

Another minor complaint is that there is no presentation of formal theory about
viruses or worms.  Although this is not an area that has seen much good work,
it would have been useful to have some coverage of that material here to
complement the higher-level descriptions.

The appendix listing other references was good, and contained some references I
have not seen before, but it did not give any indication which of the many
references were particularly noteworthy or why the references were cited.  For
instance, a number of limited-availability BBS postings and Usenet articles
were cited without an indication of why they were included.  At the same time,
the references did not list either of the fine collections of readings by
Professor Peter Denning ("Computers Under Attack" ACM Press/Addison Wesley) and
Professor Lance Hoffman ("Rogue Programs" Van Nostrand Reinhold), nor did it
reference any of the publications by the NCSA.

The book is written primarily for a British audience.  This means that the
coverage of US-specific items, such as anti-virus legislation, is briefer than
a US reader might prefer.  It also means that some small translation of terms
is necessary in spots; of course, this same criticism can be made of many
US-centric books being published in a non-US market.

Despite these criticisms, I strongly recommend this book to anyone who is
interested in computer viruses and security.  It presents material clearly and
comprehensively, and provides unbiased coverage of the area (David is not
involved with the marketing of anti-virus software or seminars as are many
other virus book authors).
                                                              (317) 494-7825
Gene Spafford, NSF/Purdue/U of Florida  Software Engineering Research Center,
Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-1398

Re: Airbus Fuel Monitoring (Van Voorhis, RISKS-12.72)

David C. Martin <>
Tue, 31 Dec 91 07:32:25 PST
Fueling is performed by an external source, not by the plane (at least for all
the American made planes that I have worked with, e.g. MD-80's, 727's, etc..)
The plane has a control panel which works on conjunction with the fueling system
from the tanker to indicate how much fuel the plane should take (i.e. how much
do you want to put in) and then automatically cuts off the flow when either the
limit of storage or the limit of input has been reached.  There are internal
pumps to move the fuel around from tank to tank.

It sounds like the fueling panel on the plane was not working correctly and they
needed to manually determine the amount to input.  This is typically done my
either disabling the fueling panel (or overriding the auto-cutoff) and
determining the fueling progress from inside the cockpit.  One problem with this
technique is that it requires multiple people (one in the cockpit, one at the
pumping station, and maybe others from the airline to supervise the
override/disable of the fueling panel).

This practice is quite common w/ older American jets and only occasionally
causes problems, e.g. when fuel spills due to other malfunctions.

Please report problems with the web pages to the maintainer