Subject: RISKS DIGEST 16.91
REPLY-TO: risks@csl.sri.com

RISKS-LIST: RISKS-FORUM Digest  Tuesday 14 March 1995  Volume 16 : Issue 91

   FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
   ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

***** See previous issue for further information, disclaimers, etc. *****

  Contents:
Re: PGP Moose -- Not just the headers! (William Oswald)
Re: Automatic return fire (Joseph Chew)
Scientology Blackmail Risk (John V. Vilkaitis)
Viral morality (Rob Slade) [LONG]

----------------------------------------------------------------------

Date: Tue, 14 Mar 95 18:06:18 EST
From: William Oswald <siwgo01@sip.unisys.com>
Subject: Re: PGP Moose -- Not just the headers! (Leichter, RISKS-16.90)

>... beware!  Any "From:" lines you include are likely Moosebait!

I recently sent to the mailing list folk_music@nysernet.org this followup to
a thread in which readers were contributing names to a list of recommended
female blues guitarists:

>Please add Cindy Cashdollar -- a fantastic blues Dobro player.
>I saw her backing up Leon Redbone a few years ago in Phila. at one
>of the Penn's Landing concerts, and I would sure like to hear more.

I was surprised to receive the following bounce:

>Subject: Error Condition Re: Re: Female blues guitarists summary
>X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
>X-Comment: Folk Music Mailing List

>We are sorry, but this system sensed the following request which may have 
>been inadvertently sent to this list:

>PLEASE ADD 

>If your posting was intentional, please accept our apologies and resend your
>mail message, making sure you do not include anything that may look like a
>request in the first line of the body of the actual message. If this was 
>indeed a request please resend it to listserver@nysernet.org

  William Oswald  --  siwgo01@sip.unisys.com

------------------------------

Date: Tue, 14 Mar 1995 14:41:15 -0800
From: JTCHEW@lbl.gov (Ad absurdum per aspera)
Subject: Re: Automatic return fire (RISKS-16.90)

Well... I trust that this is simply a case of a missing thought that seemed
obvious to the speaker, namely, that the shooter would be subject to return
fire by the human, if there were a clean shot and the situation otherwise
justified returning fire.

The description is interesting, though.  Makes it sound as though some kind
of active millimeter-wave radar or sonar-like device were in use, as opposed
to passive triangulation of the sound of gunfire.  This presents intriguing
technical problems.  The bullets of common small arms are roughly... oh, for
these back of the envelope purposes let's say they're the size of a pencil
eraser.  They move anywhere from about 800 feet per second (the .45
automatic pistol) to as much as 3000+ fps (the AR-15).  They are almost
always, but not neces- sarily, made of metal.

Now, consider that they are fired at ranges from 7 yards (which the
conventional wisdom says is the maximum range of most civilian shootings) to
contact.  An exception might be a drive-by shooting at several tens of
yards, or an urban sniper situation at perhaps a couple of hundred yards.
We can probably disregard these because of transmitted power and, in the
case of a sonar, timing considerations.  So this James Bond gizmo might have
as little as .007 seconds in which to do the job.  In an urban environment
it also has to gate out echoes.  And unless it's a slick Doppler job, it has
to get two readings.  Finally, unless it also catches the sound of the
gunshot, it *still* doesn't give you the range, just an idea of where to
look, based on what you hope is the trajectory.

Meanwhile, in case solving realtime problems in three dimensions isn't fun
enough, the shooter might well have moved and/or hidden his weapon.

This could well be quite a tactical asset to a police team.  Maybe even an
individual officer, in giving him a clue as to where to look.  It certainly
isn't a cure-all, and, especially in the case of a lone officer, it's easy
to imagine RISKS associated with getting into a "heads-down mode" to run a
technological crutch and forgetting the tactical situation.

Joe

------------------------------

Date: Tue, 14 Mar 1995 14:32:39 -0800 (PST)
From: javilk@netcom.com (Javilk)
Subject: Scientology Blackmail Risk

   If, as was mentioned in the prior edition, the Finish police handed all
the anonymous ID database to the Scientologists, many of the people who
have used the anonymizing service may RISK exposure to some form of
blackmail attempts.  One has only to look at some of the articles posted
in the Scientology forum on the Usenet to see what they are often accused
of.
   A few thoughts from a course I once attended at IBM on industrial 
espionage:
   The typical means of gaining control used by some intelligence services,
(including private ones,) and often cults, is to make a series of minor but
unethical or illegal requests which, once filled, would place the victim
greater and greater conflict with their employers, the law, and/or society
if their deeds were to be made public.  The goal is to deny the victim
access to legal and societal services.  (And in the case of cults, outside
moral support.) Eventually, the victim has no choice but to comply with even
the most hienious of operations, or risk long term incarceration, or worse.
   One way to avoid this scenario, is to call the would-be blackmailer's
bluff and say "No" at the outset.  A better way, would be to seek out and
cooperate with an appropriate company security or law enforcement agency,
such as the FBI, so as to help them turn the blackmail operation into a
sting. The would-be victim is usually given immunity from prosecution.  In
most cases, the typical minor transgressions spoken of via an anonymizing
service user would be laughed at by the police; but the concept of
blackmail on an organized scale should be taken quite seriously by an
organization such as the FBI. 
   One should also note, that if the FBI, CIA, etc. are not watching the
anonymizing services, they are sadly in remiss of their duties. It does not
take much to crack such a service!  Thus one may suspect that voluntary
cooperation at the outset might be to one's benefit in most cases; and in
some cases, being blackmailed by a more nefarious organization may actually
turn out to be a relatively opportune event.

   If the Scientologists begin to fear that many of their potential victims
would turn to the FBI, they may become more reluctant to pursue potential
victims.  Perhaps we should push this concept a bit on the net and
elsewhere.

John V. Vilkaitis, Senior Consultant, Software General Corp. javilk@netcom.com

------------------------------

Date: Tue, 14 Mar 1995 18:25:21 EST
From: "Rob Slade, Social Convener to the Net" <roberts@mukluk.decus.ca>
Subject: Viral morality

VIRETHIC
 
Viral Morality: A Call for Discussion
 
"Computer ethics" has been an ongoing study in the technical world.  On the one
hand is the study of the ethical, moral, or proper use of computers.  On the
other, is the study of computer crime and vandalism.  Lately, I have noted a
rather desperate interest in courses or training in computer ethics, as well as
an increase in the frequency and depth of discussions regarding the ethics of
virus writing.  I would like to address this latter topic, specifically.
 
One problem with current discussions and literature regarding the ethics of
virus writing and distribution is the lack of dialogue between two opposing
camps.  This paper is not intended to present any final answer, nor to add to
the literature in the field, but to open the field for comment.  My purpose in
writing this is to provide an initial overview and to elicit feedback from any
and all concerned with the topic.
 
For those of traditional moral stance, the current situation is discouraging. 
Peter Denning's "Computers Under Attack" (cf. BKDENING.RVW) has a very thorough
survey of the field, but it provides little in the way of answers or hope. 
Deborah Johnson's work "Computer Ethics" (cf. BKCMPETH.RVW) is pre-eminent in
the field, but serves only to clarify the problem.  Sarah Gordon's interviews
with computer students show responses typical of almost all such studies.  The
base attitude appears to be, "If I find it interesting, and I can do it, why do
you say I shouldn't?"
 
The proponents of security-breaking activities often question the traditional
ethical position by asking, "Where's the harm?"  This query is directly
relevant to discussions of the morality of virus writing.
 
I should begin by defining two generally opposed groups in this area.  First is
the "antivirus", or "AV", research community.  Many, though not all, of the
members of this group would be involved in producing antiviral software.  All
would study viral programs with a view to eliminating viral programs in the
normal computing environment.  They take a rather paranoid, and almost
obsessive, position with regard to the sharing and distribution of viral code. 
(They would rejoin this last by pointing out that it isn't paranoia if someone
is *really* out to get you.)
 
The AV community is not really opposed to the writing of viral programs.  It is
seen as a trivial, and therefore pointless, exercise; but not necessarily evil,
in itself.  The communication of viral program code is also a normal
professional and academic activity, as long as it is limited, done for a stated
purpose, and the recipients are known.  It is the unregulated exchange of virus
code and source, providing open access to anyone with a computer and a modem,
that is upsetting.  The opposing group is therefore described as the virus
exchange community, or "vx" for short.  (This designation was first used by
Sarah Gordon.)  For the purposes of this paper, therefore, references to "virus
writing", "virus exchange" or "vx" will mean the uncontrolled or unregulated
exchange or provision of access to virus source and object code.
 
(This does not necessarily mean deliberate distribution of infected programs by
such means as infecting a legitimate program and then posting it, without
warning, to a bulletin board system.  "Trojanizing" of normal software or
malicious invasion of systems is certainly happening in some areas, but it is
not needed in the current computing situation.  While there is debate over the
relative contribution of "natural spread" and virus exchange to the current
virus problem, it is known that code made available only as openly published
material does eventually infect machines in the normal computing environment. 
The term vx does not, therefore, require any imputation of sinister motives or
hidden activity for the purposes of this discussion.)
 
There are some grey areas between these two poles.  Some people have both
written antiviral software *and* contributed to viral spread.  Given, however,
that one could expect a continuum of opinion, those in the middle are
remarkably few.  Either you are for virus exchange, or against it.
 
One other, separate, group should be noted.  Viral programs are often cited as
an example of "artificial life", and the research community in that field, both
professional and amateur, have a legitimate interest in viral programming. 
Work in the a-life field, however, does not justify unregulated code and source
exchange.  For one thing, current viral programs "in the wild" (those which are
to be found in normal home and business computers, as opposed to those which
exist only in a research or laboratory environment) have only the most tenuous
claim to artificial life.  Common viral programs are simplistic snippets of
code without anything like the complexity of the simplest known natural life
forms.  In addition, those who really do work in the artificial life area will
be well aware that it does carry possible dangers, and that research should be
subject to controls similar to those imposed on biological and genetic study.
 
The most common argument for virus-writing tends to boil down to, "You can't
stop me."  Many promote virus writing on the grounds of freedom of speech, a
rather curious position in light of the incoherence of the arguments.  (The
most vocal of these tend to be Americans, who frequently cite "First Amendment
Rights".  This refers to the first amendment to the U.S. Constitution, which
Americans tend to see as some universal law, rather than an arbitrary political
document, however desirable.)
 
Rights, though, carry with them a weight of responsibility.  As is often
quoted, your "right" to swing your fist ceases at the end of my nose.  You have
a "right" to free speech--so long as you are responsible and do not perpetrate
fraud.  You have a "right" to study whatever you like--so long  as you are
responsible enough not to carry out experiments in poison with human subjects. 
No PC is an island--at least, not where viral programs are concerned. 
Therefore, your "right" to study, write and distribute viral programs carries
the responsibility to ensure that your creations do not--ever--run on machines
where they are not authorized.
 
One of the most confusing aspects of the "exchange/no exchange" debate is the
concept of the "good" virus.  There is nothing inherently evil in the concept
of reproduction.  (Dangerous, yes.)  In fact, the very earliest experiment with
self-reproducing programs was the Xerox Worm of Shoch and Hupp.  This was
designed to spawn "segments" of the central program on other machines in the
network, thus bringing the power of many processors to bear on a single
problem.  Thus, in theory, viral programming could represent the same level of
advanced technology in software that parallel processing represents in
hardware.
 
That's the theory.  And it is promoted by no less eminent a researcher than Dr.
Fred Cohen, who did seminal work on the security-breaking class of viral
programs in a thesis, in 1984, and dissertation, in 1986.  Unfortunately, the
theory founders on some rather hard facts.
 
There are three questions to ask of a new, inherently dangerous, technology.
Has it a useful application?  Can it fulfill that application better than
current technologies?  And, can the danger, either inherently, or
effectively, be controlled?
 
To date, no one has answered those three questions.  While a variety of uses
have been proposed for viral programs, there are none which are not effectively
being done by other means.  No viral programs have, indeed, been seen to be as
effective as normal systems.  Operating system upgrades could not guarantee
universal coverage.  Network management tasks could not promise reliable
feedback.  Automated utilities would confuse novice level users, who never run
utilities anyway.  The most useful function is still that proposed by Shoch and
Hupp--and their programs were not, strictly speaking, viral.
 
(Vesselin Bontchev's examination of this question is the most detailed to date,
and is required reading for all who want to join the debate.  His proposals,
while demonstrating good ideas for safety and control, are still primarily an
advanced automated distribution system.  The necessity for viral functions in
this regard is still unproven.)
 
Those in the vx camp will point to two current viral programs which, they say,
do have useful functions.  One of these programs produces compressed executable
files, thus saving disk space, while the other performs encryption on files. 
However, both of these functions are provided by other programs--from which,
indeed, code was stolen for those two "good" virals.  Neither of the viral
programs are as easy to use or control as the original programs, and both have
bugs which must place them firmly in the malware grouping, for nuisance value,
if nothing else.
 
Currently, therefore, the utility of viral programs is very much unproven. 
This would, though, mean only that they are neutral, were it not for the lack
of any demonstrable control.  Methods of control have been discussed primarily
by Fred Cohen, but even he remains unconvincing.  The mechanisms generally are
limited to environmental checks which can either fail, or be easily cut out of
the program.  Some have proposed "hunter" virals, to go after programs which
"turn rogue", but a program which is corrupted will behave in unpredictable
ways and a hunter program would likely consume a lot of resources, fail, or
(most likely) both.
 
(Cohen frequently cites viral "programs which have been running since 1986 with
no ill effects" and speaks of a VCE (viral computing environment).  There are
two points to be noted here.  One is that Cohen has not yet described his viral
programs in anything like the detail he put into his earlier work, so there can
be no independent assessment of his claims.  The second point is that the very
term, VCE, implies that a viral computing environment is substantially
different, and should be kept separate, from the "normal" computing environment
as it is currently known.  A VCE may very well be a powerful entity, but it is
still an unknown and unproven concept.)
 
Computer viral programs have an inherent danger:  that of reproduction and
spread.  If you study explosives, and pass along that knowledge, you also have
to pass along the materials before there is any risk of a blast.  Even then,
the materials do not multiply themselves:  when exhausted, another supply must
be found.  The same is *not* true of viral programs.  These entities are
*designed* to reproduce.  And, unlike the study of dangerous animals, or even
germ warfare, viral programs are built to reproduce, multiply and spread
without the aid of a skilled, or even aware, operator.  If you are careless
with a deadly animal or weapon, it is still only a single danger in a localized
area.  If you are careless with a computer virus, it can spread world-wide.
 
We do not use computers because they are smart.  Computers *aren't* smart. 
Sometimes we use them because they can do calculations very quickly, but even
this is only a special case of the real value of computers.  Computers always
do the same thing in the same way.  They are repeatable.  They are, in this
manner, reliable.  Even a computer error can be useful to us--so long as it
always happens the same way.
 
Consider, then, the computer virus.  In order to reproduce without the informed
assistance of the user, the virus must be, in the computer sense, transparent. 
It must operate without alerting the operator, or interfering with the
operator's interaction with the computer.  If the virus even posts a notice
("Hi! I am infecting object X!"), it has a nuisance value and is, therefore,
not good.  (Vesselin Bontchev notes that even such a notice, by possibly
delaying a process, may have grave consequences far beyond annoyance.)
 
If, however, the virus does *not* notify the operator, then the operator is not
aware of some additional code in the machine.  This extra code will have an
unknown, and inherently unknowable, effect on the computer.  The operations of
the computer are, therefore, no longer repeatable.  This is a Bad Thing (TM).
 
Some will protest that I have overblown the danger of both the notification
messages and the possibility of conflicts.  The point that I am trying to make
is that you cannot predict the harm which may arise from interference either
with the operator or the programs.  Software is digital, and is subject to
catastrophic collapse without prior warning.  For those without a background in
computer risk assessment, an excellent overview for the non-professional is
found in Lauren Wiener's "Digital Woes" (cf. BKDGTLWO.RVW).  An intriguing
compilation of the types of things that can go wrong is to be found in Peter
Neumann's "Computer Related Risks" (cf. BKCMRLRS.RVW).  At the very least, as
Sarah Gordon points out, the virus is an autonomous agent, making decisions and
carrying out activities according to it's own internal constructs and the
intention of its programmer.  This is very likely not in correspondence with
your own intention, and is therefore an invasion of privacy.
 
A number of virus writers will object that their creations simply are not
harmful.  Not only is it impossible to guarantee that your virus will not
conflict with existing systems, you also cannot guarantee that a given system
will not conflict with your virus.  Almost all file infecting viral programs
will interfere with applications which have an internal integrity checksum or a
non-standard loader, and will cause those applications to fail.  (An example of
this is that Windows programs infected with DOS viral programs always fail to
load.)  The "Ohio" virus (a prior version of Den Zuk) was not intended to carry
any destructive payload, but an unusual interaction with a certain network
operating system caused fatal disk corruption.  Since both Ohio and Den Zuk are
examples of the often proposed "virus hunter virus", it should be clear that
the concept of using a viral program to hunt down and disinfect other viral
programs is not a good one.
 
Historically, and statistically, virus exchange people have been careless and
incompetent programmers.  Remember that we are talking vx, here, and those
viral programs which have been released into the wild.  There may be, carefully
hidden in the desk of a virus writer, the "perfect" and harmless virus.  If so,
we haven't seen it yet.  The majority have obvious bugs, sloppy coding and
derivative programming.  Less than one percent are interesting for *any*
reason; only a handful have unique styles of algorithms.  And even these last
have programming pathologies.
 
There are two other reasons often given to justify virus exchange.  The first
is generally described as experimentation and education.  The second is
described as antiviral research, or, more commonly, assessment of antiviral
programs.  These arguments *do* have some validity, and should be examined. 
Ultimately, though, the reality fails to support the claim.
 
The call for experimentation is somewhat tied to the argument for a "good"
virus.  Current viral technology may be crude and ridiculous, but how can it be
improved if there isn't any work or sharing of results?  Quite true.  The vx
community, however, have obviously not read or noted any programming journals
or texts.  Discussions of programming and algorithms are supported by well-
annotated code fragments.  You don't present a whole program to discuss a
specific function any more than you send an entire car with a manual on auto
repair.  You certainly don't use encoded or "DEBUG script" object code:  that
has no explanatory value at all.
 
And I have yet to see, in the vx materials, any discussion of legitimate and
positive uses for viral technology, any discussion of control technology, or
any discussion directed at ensuring that viral programs do not create
conflicts.
 
In regard to education, it is true that a study of viral programs is related to
a knowledge of operating system internals, as well as assembly language
programming.  However, viral study *requires* such knowledge, rather than
providing it.  Giving someone a virus and expecting them to learn from it is
akin to "teaching" a surgeon by handing him a scalpel and pointing at a
patient.  Even the vx "old guard" are beginning to realize this.  Viral
programs use normal computer functions.  If you understand computers, a virus
is trivial.  If you don't, well ...
 
As far as virus exchange tutorials go, well, let me put it this way.  I am a
teacher.  Many of you will also know that I review technical books on a daily
basis.  Some are great, enough are good, many are bad and some are just plain
awful.  Only a few are worse, in terms of tutorial effectiveness, than vx
"zines" (electronic periodicals).
 
Recently, someone who makes his living pushing virus source code promoted a
collection of viral programs by suggesting you could test antiviral programs
with it.  This, superficially, sounds like a good idea--if you don't know what
*real* software testing is like.  What do we know about the quality of this
"zoo" (set of virus samples)?  What do we know about the structure,
organization, documentation and so forth?  How many duplicates are there?  Of
course, we *do* want duplicates in some cases; we want every possible variation
on polymorphs.  (For Tremor, that works out to almost six billion files.)  But
then, this collection was on a CD-ROM.  What a pity.  The most successful viral
programs are boot sector infectors, and you need to have real, infected disks
to truly test for them.  At a minimum, you'd want all seven "common" disk
formats, in both system and non-system versions.  That's fourteen disks--for
*each* BSI.
 
For all the length of this piece, it is still only an overview.  And, for all
it's length, it probably hasn't convinced anyone.  Ethics education (it used to
be called "values education"), in whatever form and however presented, has very
little to show that it works.  There are various theories and models of moral
training, the most sophisticated probably being Lawrence Kohlberg's "Moral
Development" schema.  All, though, basically boil down to sitting around
talking about ethical dilemmas.  They may develop debating skills and
rhetorical sophistry, but there is no evidence to suggest that any of these
programs leads to any significant change in behaviour.
 
While Kohlberg's model of moral development has the most detailed construction,
its utility is questionable.  His system is not so much one of values education
as of values measurement.  It is, therefore, a guideline for evaluating other
ethical training methods rather than a means of instruction and change.  Moral
development is a six stage structure, assessing the type of reasoning which
goes into ethical choices.  The stages range from "fear of punishment" to
"internal ethical principles".  There is great difficulty, however, in
determining the "stage" of a given individual.  Most ethical discussions will
be judged as having reasoning at all of stages three, four and five.  This
entire document, for example, could be dismissed as being level one reasoning
since it mentions the possibility of the danger of virus distribution and could
therefore be seen as a "fear of punishment" (negative consequences) on my part. 
On the other hand, most of Kohlberg's proponents dismiss level six, since even
a psychopath could be said to be acting from internal principles.  Kohlberg,
himself, has stated that he does not know if anyone consistently acts from
stage six reasoning.
 
Probably the major reason for this is that modern society has no fundamental
moral foundation.  The most widely cited (and Johnson gives an excellent
critique of it) is utilitarianism--"the greatest good for the greatest number". 
Leaving aside the difficulties of assessing such a measure, utilitarianism,
along with all the other modern "humanistic" philosophies, has nothing to
support itself.  Why is "the greatest good for the greatest number" to be
chosen over "what *I* want"?  An alternative is deontology; ethical principles
derived from the concept of duty.  (Ironically, this philosophy, while arguably
superior to utilitarianism, is limited to Kohlberg's stage four almost by
definition.)  Again, however, there is no underpinning to the concept of duty,
itself.
 
Ironically, the much maligned "Judeo-Christian Ethic" did have such a
foundation for moral standards--God.  The theistic universe may yet have the
last laugh over the mechanical universe of B. F. Skinner's "Beyond Freedom and
Dignity".  Maybe Jesus *is* the answer--or there may be no answer.
 
Bibliography
 
Bontchev, "Are `Good' Viruses Still a Bad Idea?", Proceedings of the EICAR '94
Conference, pp.25-47, also
ftp://ftp.informatik.uni-hamburg.de/pub/virus/texts/viruses/goodvir.zip
 
Clarkson, "Windows Hothouse", 1994, 0-201-62669-1, U$34.95/C$44.95 - lots of
artificial life fun with Visual C++
 
Cohen, "It's Alive!", 1994, 0-471-00860-5, U$39.95 - an intriguing, provoking
and practical exploration of computer programs as "artificial life", but
somewhat narrow
 
Denning, ed., "Computers Under Attack", 1990, 0-201-53067-8 - collection of
essays roughly related to security, also "the net"
 
Ermann/Williams/Gutierrez, "Computers, ethics and society" - textbook for
computer ethics course: not great
 
Gordon, "Technologically Enabled Crime", 1994
 
Forester/Morrison, "Computer Ethics", 1994, 0-262-56073-9 - lots of great
stories, but short on analytical depth
 
Johnson, "Computer Ethics", 1994, 0-13-290339-3 - the basic work in the field,
thorough coverage and good discussion starter
 
Levy, "Artificial Life", 1992, 0-679-73489-8, U$13.00/C$17.00 - an interesting
wander through fields studying artificial life but no strong points
 
Neumann, "Computer-Related Risks", 1994, 0-201-55805-X, U$24.75 - exhaustive
examples from the RISKS-FORUM Digest of potential technological perils
 
Slade, "Robert Slade's Guide to Computer Viruses", 1994,
0-387-94311-0/3-540-94311-0, U$29.95 - chapter seven looks at the computer
virus and society
 
Thro, "Artificial Life Explorer's Kit", 1993, 0-672-30301-9, U$24.95/C$31.95 -
good fun, but little analysis
 
Wiener, "Digital Woes", 1993, 0-201-62609-8, U$22.95/C$29.95 - excellent
introduction to the risks of software
 
(A fuller bibliography on values education readings is available for those
demonstrating a willingness to put some effort into it, since, frankly, it's a
really disappointing field.  Sarah Gordon's "Generic Virus Writer" paper has
significant resources here.)

copyright Robert M. Slade, 1995
Permission is granted to post this file, in full, on any system.

======================
DECUS Canada Communications, Desktop, Education and Security group newsletters
Editor and/or reviewer ROBERTS@decus.ca, RSlade@sfu.ca, Rob Slade at 1:153/733
Author "Robert Slade's Guide to Computer Viruses" (US contact 1-800-SPRINGER)

------------------------------

End of RISKS-FORUM Digest 16.91 
************************