The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

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

Volume 6 Issue 75

Monday 2 May 1988


o The effectiveness of write-protection
o Brain virus remembered
Fred Cohen
o To speak of the disease is to invoke it? (Viruses)
Fred Cohen
o Fear of Fear of Viruses
John Chambers
o New BITNET LISTSERV group for discussing viruses
Kenneth R. van Wyk
o Re: KAL007
Don Wegeng
o "Human Error" and RISKS of being deceased
Jon Jacky
o Pitfalls of simulation (economic models)
Jon Jacky
o Re: bad checks
Brian Kantor
Jon Jacky
o Re: Stores and SSNs and Perrow
David Chase
o W.H.J. Feijen on Formal Specification of Programs
o Info on RISKS (comp.risks)

The effectiveness of write-protection

Mon, 2 May 88 10:38 EDT
Phil Goetz quotes (without attribution to me, probably out of deference to my
age) as follows:

  >To suggest that [write-protection] is 100% effective against a virus is to
  >overstate.  Studies in biology suggest that a virus can thrive even in a
  >population in which a large percentage of the members are immune, if a there
  >is sufficient commerce among the non-immune members...

  >Depending upon design of the virus, the target system and population, and 
  >the chosen distribution vector, the effectiveness of this mechanism against 
  >the spread of the virus might vary from high to none at all.

Those of you that read the original posting may remember that the reference in
the original posting was not to "write-protection" in general but to a specific
hard-disk write protection mechanism that could write protect up to 80% of the
hard-disk.  You may also recall that the ellipsis at the end of the first
paragraph represents:

  >This is not an argument against vaccines but only a caution
  >about the limits of their effectiveness.

Mr. Goetz asserts:

  >Conclusion: Write-protecting the hard drive can offer 100% protection.

I concede the following:

Write-protecting 100% of the hard drive 100% of the time can offer 100%
protection against any contamination or infection of the hard drive.  100%
protection of 100% of all hard drives (an absurd case) can provide 100%
protection against any infection of those hard drives.  However, even write
protection of 100% of 100% of the hard drives will not be 100% effective
against 100% of viruses.  [I refer Mr.  Goetz to Mr.  Cohen for proof of that

The assertion in the second pargraph was also made in the narrow context of the
particular implementation of write-protection which was the subject of the
posting.  However, upon inspection, I conclude that it stands by itself.  I
leave it to Mr. Goetz' peers to instruct him as to why.

Mr. Goetz concedes:

  >Of course, if you are using your computer as a terminal, you might move a
  >virus between accounts on a mainframe, or between different computers you 
  >dial up.  But your computer is protected.

The interesting characteristic of a virus is not how it behaves in the target
machine but how it behaves in the community.  The interesting characteristic is
the ability of the virus to replicate rather than its ability to infect.  The
XMASCARD program did not infect; it only replicated.  After it replicated a
sufficient number of times, the number of copies overwhelmed the community.

The issue here is not how or whether you can protect yourself.  Rather it is
how viruses will behave in a community of systems many of which are not
protected.  It is whether or not Mr. Goetz will have to write protect his
hard disk.  It is whether or not the community will be sufficiently orderly
and well behaved that we can safely share programs and other data that we
did not create ourselves.

Forgotten, but not gone.                                      Bill Murray

William Hugh Murray, Fellow, Information System Security, Ernst & Whinney
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840

Brain virus remembered (Fred Cohen) <pyramid!uccba!ucqais!fc@unix.SRI.COM>
1 May 88 20:51:23 EDT (Sun)
Some info on the brain virus not previously mentioned by those who were
trying to quell it - it modifies several .com files, maybe all of them
eventually, without changing file sizes or dates - this was found by
using a cryptographic checksum on a golden unit, infecting it, and
looking at the results. Apparently, at Miami U of OHIO, they were
accidentally reinfecting every time they cleaned a disk because they
had NO GOLDEN UNITS! We found a 2 year old disk and are going to use
this as a beginning from now on. We also got help from a programmer who
wrote a little routine that checks for changes in the interrupt vectors
and halts the machine as soon as they change. We are in the process of
installing an improved self defending command interpreter, but are having
a hard time because we cannot get sources for the system files we are
trying to protect. Once again, protectionism causes more problems than
benefits. Oh yeah, did I forget to mention, that since you cannot write
protect lotus, etc because of copy protection, you cannot keep them from
getting infected - I thought I should bring it up. Finally, even if you
rewrite the boot sector, the brain we found remains active through the
com files it modified. So much for the cures I've heard about. As always,
suggestions are welcomed, but I think we will get it under control before
the summer break (2 days away). If we don't it could be real trouble for
the rest of you. - Fred

To speak of the disease is to invoke it? (Viruses) (Fred Cohen) <pyramid!uccba!ucqais!fc@unix.SRI.COM>
1 May 88 21:09:54 EDT (Sun)
In WHMurray's recent article to this bboard, I hear the same sounds
I have heard for years when attempting to discuss computer viruses
in an open forum. To speak of the disease is to invoke it. Did anyone
ever consider that the disease is inevitable, but the defense is not.

Society does not progress by failing to recognize threats, by hiding
its head in the sand, or by ignoring gaping holes in its integrity.
It survives by identifying corruption and eliminating it. Those who
would permit society to live in a situation so frail that a single
attacker could bring it to its knees, and then try to cover up that
knowledge by hiding it from those best prepared to put up a defense
are begging for the destruction of that society. Imagine howbad the
virus situation would be 20 years from now if we didn't find out about
it now! We would have cars that could be infected, automated airliners
waiting for an accident to happen, automated defense systems that
could strike individuals deads directly from space, all existing in an
environment without integrity.

To hide the truth is not to make the world safe. Only the truth can
set us free from the oppressive forces that lack integrity but live
in a dearth of secrecy. I think we need to start to spend our efforts in
computer security on protecting integrity, not secrecy, and I will say
it in public forums, dispite the best efforts of some of our government
agencies to keep me from doing it. Furthermore, I will continue to encourage
others to do so.

Don't get me wrong,. I don't think we should glorify attackers, I think we
should start to talk about rational defenses that protect the individual.
Don't forget that society is made up of individuals, and that by protecting
those individuals, we protect the society as well. It is the attempt to
protect the society by allowing individuals to come to harm that rationalizes
needless wars, police actions, illegal arms deals, and the whole slew of other
corrupt practices that are bringing our society down. It is the truth that
will set us free, but only if we are brave enough to face it.

    Sorry for the flaming nature of this, but I feel strongly on this
    issue, and have had enough from those who would silence important work.


Fear of Fear of Viruses (Re: RISKS-6.73)

Mon, 2 May 88 01:23:22 PDT
You've described a general problem, of people refusing to document security
problems out of fear that some unscrupulous readers (or children) will use
the information.  The result, of course, is that honest computer users are
kept ignorant while the dishonest ones slowly learn the tricks.

I've discovered one approach that is often successful at tricking people
into telling me about the problems.  I tell them that I don't believe them.
Very often they will respond by trying to demonstrate my ignorance, and of
course, the only way they can do this is to demonstrate the problem.

You can vary the form of the insult quite a bit.  For instance, if they have
named a particular commercial product and claimed that it is infected, you
can suggest that they have a financial interest in another product, and are
using scare tactics to discredit a competitor.  (This isn't hypothetical, of
course; people have done this.)

Recently, there was a debate in unix.wizards about a supposed security
problem with the Bourne-shell's IFS feature.  The same debate raged, with
nobody willing to document the problem.  I finally got fed up, and announced
that I didn't believe there was a problem; that they were just shooting off
their mouths, trying to sound like security wizards when they weren't.  I
got lots of flames that didn't document any problems, but among them was one
letter containing a piece of code that used IFS to create a shell that was
setuid to root.  It's now part of my collection of security bugs.

As for viruses, I have the feeling that most people talking on the subject
are rather ignorant, and can't tell you or me anything.  Perhaps if you
challenge them, you can find a few who will try to show that they know more
than you....

John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393)

New BITNET LISTSERV group for discussing viruses.

Mon, 02 May 88 15:54:24 EDT
For anyone who may be interested, I've started a LISTSERV discussion
forum on BITNET, entitled VIRUS-L.  It is dedicated to the discussion
of computer viruses, including present viruses and their progress, and
the prevention/detection of viruses.

To subscribe to the list, as with any LISTSERV-run list, send a message
to the appropriate LISTSERV; in the message, say:  SUB listname your name.
That is, send a mail message to LISTSERV@LEHIIBM1, stating SUB VIRUS-L your
real name.  To subsequently sign off of a LISTSERV group, send a message
to the appropriate LISTSERV stating SIGNOFF listname.  Please do not
send these requests to the list itself, as they will be distributed to
the entire list [and] do nothing other than annoy people...  :-)

Once subscribed, send list submissions to VIRUS-L@LEHIIBM1.

VIRUS-L is currently open to the public.


Ken van Wyk

Kenneth R. van Wyk, 
User Services Senior Consultant, Lehigh University Computing Center, 

Re: KAL007

Don Wegeng <Wegeng.Henr@Xerox.COM>
2 May 88 09:01:09 EDT (Monday)
In regards to the continuing debate in RISKS about the KAL007 incident, it
appears that one side of the argument is putting all of its faith in the
version of the story reported in the book "Shootdown". It seems to me that you
are always at RISK when you chose to put all of your faith in a single source,
be it a pressure sensor in an engine, the phone company's billing system, an
elected official, or a book about an aircraft that was shot down.

   [... and the OTHER side of the story is putting its faith on information
   that is all derived from one set of interrelated sources???  If you wish to
   speak in analogs with fault-tolerant computing, beware of the common-mode
   failures that can undermine supposedly redundant systems.  By the way,
   one difficulty with trying to prove a conspiracy theory is that everyone on
   the inside will deny it (which may thus seem credible), whether or not the
   theory is true.  So, you are ALWAYS AT RISK, period.  PGN]

"Human Error" and RISKS of being deceased

Jon Jacky <>
Mon, 02 May 88 09:12:28 PDT
In the Letters column of the 1 May 1988 NEW YORK TIMES MAGAZINE (p. 14),
a Steven Goldberg writes concerning an earlier article (27 March) on civil
aviation accidents.  He observes, "In the 'all accidents' category, the 
pilot is found responsible for the accident in only 38.6 percent of the 
cases.  However, in the 'fatal accidents' the pilot is found responsible
61.5 percent of the time.  It may be that there is a benign explanation for
the fact that a pilot who is dead is far more often blamed than one who can
defend himself.  But the prima facie conclusion, in the absence of such an
explanation, is that considerations other than safety lead the authorities to
blame the pilot, who can not speak for himself."

- Jon Jacky, University of Washington

Pitfalls of simulation (economic models)

Jon Jacky <>
Mon, 02 May 88 09:26:51 PDT
The 1 April 1988 issue [!!] of DATAMATION includes an article, "Economic
Modeling Gains Despite Accuracy Concerns," by Gary McWilliams (pps. 43-54).
I am not familiar with this field, and the article never really explains
what the inputs and outputs of the models are, where they come from or 
how they are validated.  Nevertheless, people apparently use them to 
forecast economic trends and seem to regard them as useful.  One model,
called Project Link, includes more than 20,000 equations.  

Much of the article appears to be based on an interview with Sam Cole,
economist and model builder at SUNY Buffalo, and author of GLOBAL MODELS AND
THE INTERNATIONAL ECONOMIC ORDER (Oxford Pergamon, 1977).  The article reports,

"The World Bank uses a global model in its lending, says Cole, sometimes to 
the detriment of its debtors.  'When the World Bank lends [a country] money,
it expects that country to have a [repayment] plan, and usually pursuades the
country to accept World Bank forecasts.  Since its forecasts are usually 
wrong, these countries end up with debts and no way to repay them,' says
Cole.  The World Bank's use of optimistic growth forecasts often are built
into the models for political reasons, according to Cole."

- Jon Jacky, University of Washington

Re: bad checks

Brian Kantor <>
Mon, 2 May 88 13:24:37 PDT
In the middle 70s I was responsible for designing a simple on-line
inquiry system for automating bad-check lookup for one of those
firms that guarantee checks for retail merchants.

The way this works is that for a monthly fee (based on average
purchase amount and volume), the guaranteee firm would automatically
guarantee any check up to some limit, and provide a guarantee for
any higher amount check that was verified with them.

Initially this consisted of having the guarantee firm's telephone
operators page through a thick paper listing of bad checks and
returning a code 1, 2, 3, or 4 (1=accept:guaranteed, 2=accept:follow
ID procedures and we'll guarantee it, 3=do not accept:no guarantee,
4=do not accept:detain customer, police notified). For example,
checks listed as "stolen" would return a code 4 (yes, they stored
the range of check numbers so that they wouldn't flag unstolen checks
on the same account).  The default (we don't know that check) was
code 2 [i.e., what the store should have done without the guarantee
service].  Merchants would be paid by the guarantee service for a
guaranteed check that didn't clear, and the guarantee service would
then assume the responsibility of collecting on the bad check.
Each inquiry was recorded for amount, the assigned approval number
and code, check customer number (a reference to the name used to
verify/guarantee the check), and the merchant number.  This
was printed in a ledger and cleared from the system each night.

A new entry for someone was given code 2 until they'd been inquired
about several times over some period of time (I seem to recall more
than twice in 30 days), at which time they'd be advanced to code
1 on the assumption that they hadn't bounced any checks yet.  Since
the merchant's best interest was served by reporting bad checks
ASAP, this seemed to work.  Downgrade to code 2, 3 and 4 was manual
and done by accounting types at the guarantee firm from bad check
collections referred by the customer merchant.  Perhaps they also
used other data; I don't know.

The whole premise was that each guarantee office usually served
repeat check customers: it could build a payment history database.
I think the assumption was that people who wrote several checks
without bouncing them would probably continue to do so.

We built the database for online inquiry by storing the last name
Soundex-indexed (as a sort of hashing technique, if you will), and
listing other information such as SSN, driver's license number,
account number on the check, etc in a cross-reference.  If more
than one "hit" occured when an operator keyed in a last name, he
was prompted for more information to resolve the hits, or he could
page through a summary of the records on line to see if one fit
the profile of the check being submitted.

Clearly the RISK here is misidentification: the more information
they stored and the more the merchant's clerk collected for check
verification, the better they could do at eliminating false denials.
The system was clearly biased towards generating accepts to avoid
pissing off honest customers, but to contain the losses of the
guarantees.  Last I heard they were still using revisions of that
software and making a chunk of money.

Note that most of the actual data used to determine check acceptance RISK was
not stored online.  Probably it is now, but at that time (about 15 years ago)
the disk storage was too dear and the retrieval time simply wasn't important:
paper files in file drawers was quite good enough.  Since the review was manual
anyway, it seemed reasonable to have the relevant documents in human-readable
form.  One of them - the returned check - was always on paper anyway.  This all
ran on a Microdata REALITY system with 64K of main memory (the max) and one 10
Meg hard drive.  Nowadays you'd do it on an ATKlone.
                                                     Brian Kantor, UC San Diego


Jon Jacky <>
Mon, 02 May 88 09:06:43 PDT
The May 1, 1988 issue of the NEW YORK TIMES MAGAZINE has a feature article
about Tom Clancy, author of the best-selling thrillers HUNT FOR RED OCTOBER
and RED STORM RISING.  In the background of the obligatory picture of the
author in his study by his bookshelves, you can clearly see NORMAL ACCIDENTS
by Perrow (p. 55, right edge of page, halfway down).

- Jon Jacky, University of Washington

Re: Stores and SSNs and Perrow <David Chase>
Sat, 30 Apr 88 00:15:17 -0700
In reply to two articles by Stanley F. Quayle:
> This store uses price scanners.  It would be possible to establish a
> profile of each check-paying customer with this system....If they
> haven't thought of this already, I don't want to give them any ideas.

Don't worry; they've already thought of it and do it.  My wife reports
that Stew Leonard's in Norwalk, Connecticut is one store that does; by
name, and what you buy, and if it was on sale.  Paying cash is the
only sure way to avoid this.

(on Normal Accidents)
I think Perrow was studying nuclear power as it existed from 1979 to
1984, not as it might exist.  I don't think his conclusions on nuclear
power are weakened at all if someone tells me that we could build
safer plants, but don't.  You can rightly say that safe plants haven't
happened for economic, political, legal, and bureaucratic reasons, and
you still haven't weakened his conclusions.

David Chase, Olivetti Research Center, Menlo Park

W.H.J. Feijen

Sun, 1 May 88 14:47:20 EDT
Harvard Distinguished Lecturer Series, GB/SIGPLAN, and GB/SIGSOFT Present:

     W.H.J. Feijen, Visting Professor at University of Texas, Austin
     Professor at Technologie Universitat, Eindhoven, Netherlands

Speaking on MAY 3rd, 7:00 pm, Lecture Hall B, Harvard Science Center,
Cambridge, MA, Prof. Feijen promises to update Software Engineers on the
latest developments in the Formal Specification of Programs.  He is co-author
with Edsger W. Djikstra of the recently released "Methods of Programming".  (A
large crowd is expected.)  Host is Professor Mark Schneider, Harvard Univ.

Please report problems with the web pages to the maintainer