To:	   VIRUS-L@LEHIGH.EDU
Subject:   VIRUS-L Digest V6 #92
--------
VIRUS-L Digest   Tuesday,  8 Jun 1993    Volume 6 : Issue 92

Today's Topics:

Re: Digital Enterprises $5,000 challenge! $$$ $$$
Re: Digital Enterprises $5,000 challenge! $$$ $$$
Re: Digital Enterprises $5,000 challenge!
FDISK/MBR with OS/2 boot manager. (OS/2)
re: What to do about Quox virus? (PC)
re: Misidentification by F-Prot 2.08a (PC)
re: Anyone have something like this? (PC)
How a floppy is accessed. (was "DIR" infection). (PC)
Re: New scanner -- Looking for code (PC)
CANSU (PC)
New virus in Chile, not detected by newest scanners (PC)
3,5" can"t read HD - is that a virus ?? (PC)
Re: Redirection Difficulty (PC)
Evaluating Activity Monitors (CVP)
Review of "Computer Virus Handbook" by Highland
avp.zip (PC)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a gatewayed and non-digested USENET
counterpart.  Discussions are not limited to any one hardware/software
platform - diversity is welcomed.  Contributions should be relevant,
concise, polite, etc.  (The complete set of posting guidelines is
available by FTP on cert.org or upon request.)  Please sign submissions
with your real name; anonymous postings will not be accepted.
Information on accessing anti-virus, documentation, and back-issue
archives is distributed periodically on the list.  A FAQ (Frequently
Asked Questions) document and all of the back-issues are available by
anonymous FTP on CERT.org (192.88.209.5).

Administrative mail (e.g., comments, suggestions, beer recipes)
should be sent to me at: krvw@AGARNE.IMS.DISA.MIL.

All submissions should be sent to: VIRUS-L@Lehigh.edu.

   Ken van Wyk


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

Date:    Sun, 06 Jun 93 16:23:36 +0000
From:    mitchell@mdd.comm.mot.com (Bill Mitchell)
Subject: Re: Digital Enterprises $5,000 challenge! $$$ $$$

in comp.virus, chilly@panix.com (Will Schenk) said:

>miser@stein2.u.washington.edu (Robert Fulwell) writes:
>>Here's an interesting offer a few people out there probably wouldn't mind
>>cashing in:
>>
>><Taken straight from Prodigy (DON'T ask me what I was doing there :-)>
>>
>>PRODIGY(R) interactive personal service         06/03/93         1:29 AM
>>
>>    DIGITAL ENTERPRISES IS CHALLENGING COMPUTER HACKERS to
>>    defeat its anti-virus technology.
>>       The Gaithersburg, Md-based company says virus experts
>>    have tried unsuccessfully for more than 2 years to defeat
>>    its V-Card Anti-Virus System. It's inviting hackers to come
>>    to its headquarters through mid-July to try their hand at
>>    loading a true virus (Trojan horses and bombs don't count)
>>    onto the system. The computer must be rendered non-bootable
>>    and files must be non-recoverable while V-Card is operating.
>>       The company will reward the triumphant hacker with $5000.
>>
>
>It's people like this who give hacking a bad name...

People like who?
    Robert Fulwell, who posted the article you quote?
    Prodigy, who apparently distributed the announcement?
    Digital Enterprises, who apparently produce an anti-virus product?
    "virus experts", who apparrently tried for two years to defeat the product?
    "hackers" who might try to outdo the "virus experts" to collect $5,000?
and, pray tell, why?

- -- 
mitchell@mdd.comm.mot.com (Bill Mitchell)

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

Date:    Sun, 06 Jun 93 14:43:00 -0400
From:    mju@mudos.ann-arbor.mi.us (Marc Unangst)
Subject: Re: Digital Enterprises $5,000 challenge! $$$ $$$

chilly@panix.com (Will Schenk) writes:
>	...and I'm sure that the FBI WON'T we waiting for you as you exit
>the building with code in hand and money in pocket.  Seems like you would
>probably find a large source of virus writers there..

Yes, but how would they go about proving that you wrote a virus that
actually caused harm?  Most virus authors don't sign their work (not
with their real name, at any rate), and last time I checked it wasn't
illegal to write a virus -- just to deliberately infect other machines
such that it causes damage.

- -- 
Marc Unangst, N8VRH         | "People who love sausage and respect the law
mju@mudos.ann-arbor.mi.us   |  should never watch either one being made."
                            |     -The Sausage Principle


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

Date:    Mon, 07 Jun 93 04:17:39 +0000
From:    winner@cua.edu
Subject: Re: Digital Enterprises $5,000 challenge!

 chilly@panix.com (Will Schenk) writes:
> 	...and I'm sure that the FBI WON'T we waiting for you as you exit
> the building with code in hand and money in pocket.  Seems like you would
> probably find a large source of virus writers there..

I can't for the life of me imagine what the FBI would do there but
congradulate you on your winnings.  It would make more sense to have
the IRS there to make sure you pay the taxes on your winnings.

I do not believe that writing self-replicating code could break any
law, if so players of CoreWars, or researchers using Tierra would be
in danger of breaking the same law.  While (as I understand it) there
are laws pertaining to illegal entry into a computer system, which a
virus infestation might be covered under, I doubt it would apply if
you went there and introduced the code with the companies knowledge
and permission.

I don't mean to imply that I like the idea of the contest (I don't
mean to imply that I am against it either.)  I just would be very
surprised to find that winning the contest would break any laws.  I
also don't think that winning the contest would imply that you are
some notorious virus-writer.  I would expect that many to most of the
people concentrating on anti-viral software (especially viral shields)
would have the skills needed to investigate the security of the
system.  It is their ethics/morals/dispossition/nature that has them
direct their skills to anti-viral work rather than viral work.

- -Jim

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

Date:    Wed, 02 Jun 93 10:18:00 +0200
From:    Amir_Netiv@f120.n9721.z9.virnet.bad.se (Amir Netiv)
Subject: FDISK/MBR with OS/2 boot manager. (OS/2)

 (Vesselin Bontchev) writes in reply to Johan Wevers
JW:
 >> My first harddrive (physical drive C:) contains 2 bootable partitions,
 >> DOS 5.0 and OS/2 2.0, and the OS/2 boot manager. I don't know on which
 >> level
VB:
 > Actually, it has 3 partitons (DOS, OS/2, BootManager),
 > only one of which (the Boot Manager) is bootable.

Actually it is usually simpler, In most Double Boot systems I know it
goes like this:
The partition table itself is a program that prompts for type of
desired boot, the selection made by the user replaces the "Active
Partition" byte in the MBR and reboots, so that this time the next
step in the chain (reading the boot-sector) is calling the desired
boot-loader, and it continues the load chain normally.

JW:
 >> the boot manager takes control, nor do I know or the MBR is different when
VB:
 > The Boot Manager gets control after the MBR is executed. It checks
 > what you want to boot (DOS or OS/2) and transfers control to it. The MBR
 > should be a "normal" one.

Either way, if the MBR itself is the boot manager or the MBR points to
the boot manager (the active partition is the boot manager`s) the
partition *may* look different.

JW:
 >> using different operating systems. My direct question is: is it safe to
 >> give the command FDISK/MBR on this drive, or would it destroy something?
VB:
 > Should be safe.

I wouldnt bet my life on it.  I would highly recommend that any user
that has such a disk will have a backup of the partition-table and
Boot-Sectors on a floppy. This can be achieved with DISKPART (of the
V-CARE Anti-Virus) or Norton`s DISKEDIT, CHIEF`s BACKINFO ( and
probably other tools as well).

Any other attempt to mess with the MBR of such a disk may cause severe
damage.

Regards

* Amir Netiv. V-CARE Anti-Virus, head team *

- ---
 * Origin: <<< NSE Software >>> Israel (9:9721/120)

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

Date:    Fri, 04 Jun 93 11:34:44 -0400
From:    "David M. Chess" <chess@watson.ibm.com>
Subject: re: What to do about Quox virus? (PC)

> From:    Eriq Oliver Neale <neale@unt.edu>

> I just now ran across a diskette infected with the "Quox" virus

The Quox is a reasonably simple diskette and Master Boot Record
infector.  It's "stealthed" in the sense that if you use INT13
to read an infected boot record, it will show you the original
clean one instead.  It has no particular payload and no text
strings.  We got a sample from Thailand in July of 1992, and
I named it "Quox" because there was no obvious good name, and
we didn't have very many viruses starting in "Q".

It infects only the master boot record of a hard disk; to
clean up, cold-boot from a clean floppy, make sure all your
hard disk partitions are there, and then use FDISK /MBR.
To clean up a floppy, copy the files off and FORMAT /U.
Or use IBM AntiVirus or some other anti-virus that can deal
with it.

- - -- -
David M. Chess                /  "In the long run, life depends less on
High Integrity Computing Lab  /    an abundant supply of energy than on
IBM Watson Research           /    a good signal-to-noise ratio." - Dyson


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

Date:    Fri, 04 Jun 93 11:46:37 -0400
From:    "David M. Chess" <chess@watson.ibm.com>
Subject: re: Misidentification by F-Prot 2.08a (PC)

> From:    "System Manager, and VAX Gopher" <farnold@wotan.duch.udel.edu>

>                                               F-Prot 2.08a identified the
> virus as a _Screaming Fist_ variant, while McAfee's Scan program said that
> it was a combination of a boot sector virus, [Genp], with the _Stickey_
> [ML2] virus infecting the .com and .exe files.

> how often does
> this happen (misidentification, or identifying two viruses as a
> third)?

I see no evidence that F-PROT was wrong.  Most likely, you had
some variant of the Sticky virus.   The Sticky virus is indeed
a _Screaming First_ variant (in the sense that Sticky shares lots
of code with the various Scream or Screaming Fist viruses).  The
main difference is that Sticky infects both boot records and files.

"Genp" is just SCAN's way of saying "something virus-like in the
boot record, but I don't know which virus it is".  In that sense,
SCAN was misidentifying the virus at least as badly as F-PROT was!

The virus does indeed assume that all files with extension "COM"
or "EXE" must be infectable programs.  On the other hand, DOS does,
too!   *8)   If you type the name of that VAX .COM file, your
machine will probably hang (don't try this at home, kids!).

If the virus was the usual strain of the Sticky (can't tell for
sure, since F-PROT saw it as a variant, and SCAN doesn't do
any sort of verification), it has no payload, so if all the
infected objects have been cleaned up, and all contacts alerted
and scanned, you're done...

- - -- -
David M. Chess                           For Best Results,
High Integrity Computing Lab                Consume Before Above Date
IBM Watson Research


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

Date:    Fri, 04 Jun 93 11:49:42 -0400
From:    "David M. Chess" <chess@watson.ibm.com>
Subject: re: Anyone have something like this? (PC)

> From:    Waldemar.Cichon@f6031.n491.z9.virnet.bad.se (Waldemar Cichon)

> I think, a virus can also physically destroy tracs: he has only
> reformat some tracs with its own sector numbering.

But that doesn't *physically* destroy the track!   If the disk is
low-level formatted, it'll get the normal sector numbers written
again.  The tracks are physically fine, they just (temporarily)
have odd stuff written in the little magnetic fields...           DC


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

Date:    Wed, 02 Jun 93 10:29:00 +0200
From:    Amir_Netiv@f120.n9721.z9.virnet.bad.se (Amir Netiv)
Subject: How a floppy is accessed. (was "DIR" infection). (PC)

Roger Riordan in a comment to Amir Netiv

 > Whenever you attempt to access a disk drive DOS first
 > checks the status of the door open line. If the door has been
 > opened since the last disk access DOS then reads the FAT.

This doesn't make sens. If the door has been opened since last disk
access, it is reasonable to assume that the floppy was replaced,
therefore it is necessary to first check the type of disk and to
calculate the location of the FATS, or else you might read garbage.

 > If this does not match the last disk read (or if the read fails) DOS
 > then reads the disk boot sector. If this fails DOS will reset
 > the drive and try again several times.

Too much work for some pretty obviouse conclusion: The floppy was
replased.

 > Thus, in the normal state of affairs, the boot sector of each
 > floppy is read just once. This READ is usually preceded by an
 > attempt to read the FAT and this is preceded by a call to
 > Int 13 to check the door opened status.

If what you sujjest is right, whay is it necessary to acess the boot
sector every time?

 > I think this sequence is followed for DOS 3 on (but won't swear
 > to the door status call for DOS 3).

I've written a small ISR that beeps on INT 13h ant tried it with some
of the services you've mentioned. Unless all the calles to these
services adone by CALL and not INT (which is quite a resonable
posibility), there was not even one beep, however it beeps chirfully
on int 13h "Read" head-0 cyl-0 sec-1.  several time upon replacement,
then single time on each access.

Regards

* Amir Netiv. V-CARE Anti-Virus, head team *
- ---
 * Origin: <<< NSE Software >>> Israel (9:9721/120)

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

Date:    Mon, 07 Jun 93 04:26:42 -0400
From:    stefang@isy.liu.se (Stefan Gustavson)
Subject: Re: New scanner -- Looking for code (PC)

This is an outrageous request. Please think before you speak.
And how on Earth would a virus scanner be easier to test if
you have the virus source code?
If someone has virus source code, he/she ought to have participated
in writing it. I doubt that such a person would give it to you to
make your anti-viral scanner work better.
From your article, I get a strong feeling that you are just a malicious
or misguided hacker trying to obtain virus source code to modify.
I sincerely hope I am wrong.

      Stefan Gustavson (stefang@isy.liu.se)

[Moderator's note: As most long-time readers of this group know, one
of the policies of the group is that requests for viruses aren't
accepted.  I _should_ have rejected this one, but goofed - my fault.]

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

Date:    Mon, 07 Jun 93 12:03:43 -0400
From:    RJ.Neville@rock.concert.net
Subject: CANSU (PC)

In trying to fix a "damaged" disk, I ran across the virus CANSU. I
proceeded to scan the remainder of the machines and diskettes in the
area and have found 2 infected hard drives. Clean says that it will
clean this. What cost to my hard drive?

Any information would be helpful... Please mail directly to me so as
not to waste bandwidth. Thanks!


RJ			MCS Manager, Queens College	rj@queens.edu
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It's not what you've got, it's what you give.
It's not the life you choose, it's the life you live -- TESLA
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

Date:    Mon, 07 Jun 93 12:59:35 -0400
From:    <JVIGNOLO@ucvvm1.bitnet>
Subject: New virus in Chile, not detected by newest scanners (PC)

A  variant  of the CPW virus, not detected by SCAN 104  or  FPROT
2.08a,  has  been found on a LAN server, in  central  CHILE.  The
virus has a good spread potential, because the net connects a few
hundred  PC's,  and users have working  relationships  with  many
other commercial an educational institutions in the Country.

The  "original" CPW is reported (at least) in VSUM9304. I do  not
have  a  copy  of  that virus. Virus  features  listed  here  for
comparison are extracted from VSUM9304.

The  original virus was written in CHILE, presumably  by  someone
whose initials are CPW. The virus is detected by SCAN 99+,  FPROT
2.07+ and others.

I have performed a few experiments with the variant. Results are:

- - The  new virus infects (at least) EXE and COM files,  including
  COMMAND.COM,  increasing file size by 1527 (decimal)  bytes  on
  both  file types. Same behavior as the original, although  file
  growth was 1459 bytes.

- - When  an  infected program is run, the  virus  installs  itself
  memory  resident  reducing available memory by  2000  (decimal)
  bytes,  as reported by MEM, exactly like the original. It  does
  not  show up as a memory resident program in MEM's list.  I  do
  not know which interrupts are hooked.

- - The  virus  infects  files  (at least)  on  execution  or  copy
  operations.  It  does  not infect every time  an  operation  is
  performed. I do not know the pattern.

- - When resident, the virus does not forge file size as  indicated
  by DIR. This is an easy way to identify infected files.

- - When  resident, the virus erases a program named SCAN.EXE  when
  execution  is  attempted. Same as the  original.  Renaming  the
  program avoids erasure.

- - No  messages  are  visible  in the  infected  files.  They  are
  encripted.  Messages  are  visible in memory,  with  the  virus
  active. They say:

  "CPW fue hecho en Chile en 1992,  VIVA CHILE MIERDA!"

  meaning:

  "CPW was made in Chile in 1992". Last part is a popular  saying
  here. Translation would not be polite...

  Original  virus  messages  are similar, but  not  encripted  on
  infected  files. Virus author is probably the same one. He  has
  "perfected" his work.

- - SCAN  102,  SCAN 104, FPROT 2.07, FPROT 2.08a and MSAV  do  not
  detect  the  virus on infected files. I have not  tested  other
  programs.

- - SCAN 102 and SCAN 104 do find the virus when active in  memory,
  identifing it as *1530*.

- - FPROT 2.07 sniffs the virus on heuristic scanning.
  Message  for COM files is: "This is a  self-modifying  program,
  which  may  indicate a self-encrypting virus  or  just  unusual
  code."
  Message  for  EXE  files is:  "This  program  contains  several
  features  which are normally only found in virus programs.   It
  is almost certainly virus-infected."
  FPROT 2.08a, however, does not detect the virus on heuristics!

FPROT 2.07 is (to my knolewdge) the best tool available for  fast
identification of infected files.

I have no idea about virus payload, if any.

Infected samples will be sent to known researchers.

- -----------------------------------------------------------------
 JVIGNOLO AT UCVVM1                     Juan A. Vignolo
      BITNET                          Associate Professor
                                    Electrical Engineering
PO Box 4059, Valpso.          Universidad Catolica de Valparaiso
      CHILE                                 CHILE
- -----------------------------------------------------------------



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

Date:    Tue, 08 Jun 93 02:35:34 -0400
From:    Ralph Rinschen <rinschen.pad@sni-usa.com>
Subject: 3,5" can"t read HD - is that a virus ?? (PC)

Hello,

my 3,5" drive can"t read HD drives. 

1.st there were no problems - but suddenly from one day to
another, DOS says : General failure !!

Sometimes it works and sometimes not. After cleaning the drive
it still doesn"t read. 

So, whats wrong with this drive. If it  reads 3,5" HD disc there are not 
too many noises so i think the head are still in good positions. 
By the way, is there anywhere a testprogramm for this ??

I ran different virus scanner - all with a negativ result.

Does anybody know what to do ??

Thanks

Ralph
- -- 
==============================================================
Sender4s Name and Adress  |
- ------------------------- | There is no grazy lazy boring text
Name : Rinschen, Ralph    | in here ..
Street : Cromptonstr. 10e | ----------------------------------
Location : 4790 Pb-Elsen  |
Telephon : not visible    | email : rinschen.pad@sni.de
==============================================================
- --
==============================================================
Sender4s Name and Adress  |
- ------------------------- | There is no grazy lazy boring text
Name : Rinschen, Ralph    | in here ..


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

Date:    Fri, 04 Jun 93 09:49:07 -0400
From:    Donald G Peters <Peters@DOCKMASTER.NCSC.MIL>
Subject: Re: Redirection Difficulty (PC)

Since Padgett and Vesselin questioned the value of this thread I will
attempt to close it with a brief reply. Based on Padgett's message
(Vesselin's came later, although it was much more explicit) I was able
to figure out that function 45h-46h was the key to my problem. Anyone
who wants the source I wrote can send me an email message.

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

Date:    Fri, 04 Jun 93 14:02:54 -0400
From:    "Rob Slade" <roberts@decus.arc.ab.ca>
Subject: Evaluating Activity Monitors (CVP)


PRTAVSB.CVP   930522
 
                  Evaluation of Activity Monitors
 
It is very difficult to specify, in advance, what you should check
for in activity monitoring software, since the developers are loath
to state, in specific detail, exactly what the program will be
checking for.  (This reluctance is understandable: if a developer
"advertises" exactly what the product checks for, virus or "trojan"
writers will simply use another route.)  In addition, the work or
computing environment must be considered, as well, in certain cases,
as the "corporate climate".  Activity monitors, more than scanners
or change detectors, are subject to review on the basis of
"political" rather than technical grounds.
 
Activity monitoring software should be thoroughly tested in a "real"
working environment (one that uses all the programs you normally do,
in the ways you normally use them) for some time in order to ensure
that the vaccine does not conflict with "normal" operation.  The
"real" environment includes the "real" people who will be using the
software: chose your "sample" population carefully and avoid simply
giving it to the tech support office to test.  Two important factors
to check for are the number of "false positives" (or false alarms)
that the software generates, and the level of information given to
the user when an anomalous condition is detected.  This last is
difficult to judge: user populations who tend to remain at the
"novice" level will have no more confidence in the system regardless
of how much information it gives them.
 
While activity monitors have a good chance to detect viral activity
of "new" and unknown viral strains, it would be very difficult to
agree with those that claim to be able to detect "all current and
future" viral programs.  While it might generally be held to be a
"good thing" to prevent changes to the file allocation table, it is
unlikely that FAT or "system" viri could have been foreseen prior to
the existence of the "DIR" family.  Activity monitors are also
unlikely to work well against "companion" type viral programs
without specific safeguards in place.
 
Monitoring programs should be tested against a battery of viral
programs, but the "test suite" should be collected on the basis of
function rather than simply diversity.  If the activity monitor is
effective against Stoned, then Empire, Michelangelo and Monkey
variants are unlikely to trouble it.
 
Unfortunately, activity monitors tend to encourage a "set and
forget" mentality towards viral protection.  This should be avoided
at all costs.  If activity monitoring software is your protection
method of choice, continue to keep up to date with viral methods and
test your software regularly.
 
copyright Robert M. Slade, 1993   PRTAVSB.CVP   930522

==============                      _________________________
Vancouver      ROBERTS@decus.ca    |    |     |\^/|     |    | swiped
Institute for  Robert_Slade@sfu.ca |    |  _|\|   |/|_  |    | from
Research into  rslade@cue.bc.ca    |    |  >         <  |    | Alan
User           p1@CyberStore.ca    |    |   >_./|\._<   |    | Tai
Security       Canada V7K 2G6      |____|_______^_______|____|


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

Date:    Fri, 04 Jun 93 14:08:07 -0400
From:    "Rob Slade" <roberts@decus.arc.ab.ca>
Subject: Review of "Computer Virus Handbook" by Highland

BKHGHLND.RVW   930404
 
Elsevier
Mayfield House
256 Banbury Road
Oxford OX2 7DH
England
655 Avenue of the Americas
New York, NY   10010
USA
212-989-5800
fax: 212-633-3990
Computer Virus Handbook, Harold Joseph Highland, 1990, 0-946395-46-2
 
When Dr. Highland first offered to send me a copy of this work, late in 1992,
he indicated that it was outdated.  In some respects this is true.  Some of the
precautions suggested in a few of the essays which Dr. Highland did not write
tend to sound quaint.  As one example, with the advantage of hindsight, Jon
David's ten page antiviral review checklist contains items of little use, and
has a number of important gaps.  However, for the "general", rather than
"specialist" audience, this work has much to recommend it.  The coverage is
both broad and practical, and the information, although not quite up to date,
is complete and accurate as far as it goes.
 
The book starts with, as the title has it, "Basic Definitions and Other
Fundamentals".  Dr. Highland has collected definitions from a number of sources
here, which makes a refreshing change from some of the dogmatic assertions in
other works.  The fact that the reader is left to make his own final decision
as to a working definition might be frustrating to some, but is likely
reasonable given that the argument over the definition of a virus is still
raging to this day.  With the changes that are still taking place in terms of
new "forms" of viral programs, it is unlikely that this debate will be settled
any time soon.
 
Chapter one also contains important background information on the operation of
the PC and the structure of MS-DOS format disks.  The one shortcoming might be
that so much of the book deals with MS-DOS machines that readers dealing with
other systems may fail to note the generic concepts contained therein.
 
Chapter two is a concise but encompassing overview of the viral situation by
William Hugh Murray.  Using epidemiology as a model, he covers the broad
outline of viral functions within a computing "environment", and examines some
theoretical guidelines to direct the building of policy and procedures for
prevention of viral infection.  The article is broadly helpful without ever
pushing the relation between computer viral and human epidemiology too far.
 
Chapter three deals with history and examples of specific viral programs.  This
section is an extremely valuable resource.  While other works reviewed have
contained similar sections, the quality of this segment in Highland's tome is
impressive.  Mention must be made of the reports by Bill Kenny of Digital
Dispatch who provides detailed and accurate descriptions of the operations of a
number of viral programs which are, unfortunately, all still too common. 
(Chapter four is similar, containing three reports of viral programs from other
sources.)
 
Large sections of the handbook deal with the evaluation and review of antiviral
software.  (I must say that I had great sympathy with that part of the preface
which dealt with some experiences encountered when trying to test various
packages.)  Chapter five gives an evaluation protocol and test methodology. 
The detail here may lead some to skip over it, but it is helpful to those who
wish to determine how thoroughly the testing was conducted.  Chapter six, an
article by Jon David as mentioned earlier, is a suggested procedure and
checklist for testing antiviral software.  This chapter is unfortunately weak,
and although there is some valuable direction, one comes away with the
impression that the important thing to test is whether the program runs on a
VGA monitor and has a bound manual.  One must, of course, realize that
antiviral testing was then in its infancy, and Mr. David's article reflects the
general tone fo those times.  Chapter seven is concerned with specific product
evaluations, and, as most lists of its type do, shows its age.  Of the twenty
products listed, I recognize only seven as still being in existence,; of those
that still do exist four have changed substantially in the intervening three
years.
 
Chapter eight is an essay by Harry de Maio entitled "Viruses - A Management
Issue", and it must be considered one of the "forgotten gems" of virus
literature.  It debunks a number of myths, and raises a number of issues seldom
discussed in corporate security and virus management.  Chapter nine is similar,
being Dr. Highland's suggested procedures for reducing the risk of computer
virus infection.
 
Chapter ten is a collection of essays on theoretical aspects of computer virus
research and defence.  Fred Cohen is heavily represented here, of course, but
not as singularly as in, for example, Hoffman's "Rogue Programs".
 
Dated as the book may be in some respects, it is still a valuable overview for
those wishing to study viral programs or the defence against them, particularly
in a corporate environment.  While some may find the book to be "academic" in
tone, it never launches into "blue sky" speculations: all of the material here
is realistic.  The "aging" of the product reviews makes it difficult to
consider it still a reference "handbook" or a "how to" resource, but Dr.
Highland's work is by no means to be discarded yet.
 
copyright Robert M. Slade, 1993   BKHGHLND.RVW   930404

==============                      
Vancouver      ROBERTS@decus.ca    | "Do you get guns with your 
Institute for  Robert_Slade@sfu.ca |  gun magazines?  No.
Research into  rslade@cue.bc.ca    |  Do you get viruses with your 
User           p1@CyberStore.ca    |  virus magazines?  Yes."
Security       Canada V7K 2G6      |               - Kevin Marcus


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

Date:    Sun, 06 Jun 93 06:00:32 -0400
From:    HAYES@urvax.urich.edu
Subject: avp.zip (PC)

Hello.
AVP.ZIP, the antivirus/integrity program from Russia mentionned by V. Bontchev
is now available via FTP from our site.

Best, Claude.

- ----------
Site:       urvax.urich.edu,  [141.166.36.6]    (VAX/VMS using Multinet)
Directory:  [anonymous.msdos.antivirus]

FTP to urvax.urich.edu with username anonymous and your email address
as password.  You are in the [anonymous] directory when you connect.
cd msdos.antivirus, and remember to use binary mode for the zip files.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Claude Bersano-Hayes     HAYES @ URVAX                 (Vanilla BITNET)
University of Richmond   hayes@urvax.urich.edu     (Bitnet or Internet)
Richmond, VA  23173


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

End of VIRUS-L Digest [Volume 6 Issue 92]
*****************************************
