Hacker 2/HACKER2.mdf/virus/virusl2/virusl2.238

Text File | 1995-01-03 | 33KB | 700 lines

VIRUS-L Digest   Friday, 10 Nov 1989    Volume 2 : Issue 238

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

Today's Topics:

Sophisticated Viruses
Re: Sophisticated Viruses
386 Isolation
Pam Kanes book and the CVIA
Undecidability
RE: MacWight dilemma (Mac)
Details of Ogre, Dark Avenger, etc. (PC)
Another attack?!? (PC)
Re: Sophisticated Viruses?
Re: Checksum programs; Hardware protection
Ping Pong virus (PC) at UIUC
Re: virus problem undecidability
New IBMPC anti-virals
Re: future viruses on a PC Pull plug before cleaning
In Search Of Virus Info

[Ed. In an effort to send out one digest per day, this digest is
longer than usual.  If anyone has truncation problems due to its
length (~32k), please let me know.]

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

Date:    Thu, 09 Nov 89 09:59:00 -0500
From:    [e-mail]
Subject: Sophisticated Viruses

Thanks to Jim Frost for a very thought provoking posting.  Here are some
that I had while reading it.

>Limiting Propagation Rates.  Simple viruses, and often not-so-simple
>ones, will proliferate without bounds.  Rampant proliferation will
>cause the virus to be noticed early in its lifetime and will probably
>lead to its early demise.  The internet worm did not do this.

Most PC viruses do not do it either.  When the vector is a diskette,
it need not.  Most of the network worms have not done it; they wanted
to be noticed.  Therefore, the requirement is a function of both the
chosen vector and the motive.

>Detecting and Avoiding "Virus-Protected" Hosts.  I have yet to see a
>virus which looked at the state of a system to detect virus detection
>mechanisms to nullify them and/or avoid infecting them.

Biological viruses simply ignore potential but immune hosts.  If the
potential population is sufficiently large, the presence of immune
subjects is not important.

However, again motive is important.  We have not seen any viruses that
were determined to conceal their existence, in part because writing a
virus that no one notices is not any fun.  If no one notices, then
it is not possible to know about propagation or survival.  What fun is
that?

>Count our blessings now because you
>won't believe how bad tomorrow's nightmares will be unless we start
>teaching ethics to tomorrow's programmers!

I will settle for simple self interest.  ALL computer users have a
vested interest in an orderly environment in which programs can be
relied upon to do only what they advertise.  Virus writers are soiling
their own nests.

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

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

Date:    Thu, 09 Nov 89 10:37:36 -0500
From:    Kenneth R. van Wyk <[e-mail]>
Subject: Re: Sophisticated Viruses

[e-mail] writes:

>> We have not seen any viruses that were determined to conceal their
>> existence...

In theory anyway, what proof to we have of their non-existence?  If
they're determined to conceal themselves, then why would we expect to
notice them in the first place?

In Cliff Stoll's book, "The Cuckoo's Egg", Dr. Stoll points out that
for every forty (approximately) computers that the hacker invaded,
only one or two system administrators ever noticed.  The connections
were relatively overt in that they left behind audit trails ('lastlog'
entries), yet very few people noticed.  (In my personal opinion, by
the way, "The Cuckoo's Egg" should be considered required reading by
anyone who runs, or is interested in, computers - *highly*
recommended.)

>> ...in part because writing a virus that no one notices is not any
>> fun.  If no one notices, then it is not possible to know about
>> propagation or survival.  What fun is that?

There's an important distinction to be made here - detection during
propagation vs. detection after (presumably) successful propagation.
A virus could well attempt to conceal its existence while propagating,
and then do quite the opposite (!) during a destructive phase.  No one
would notice until it would be too late.

I'm not trying to sound like the voice of gloom and doom, really.  I
don't believe that the sky is falling.  The purpose of this posting
isn't to sound sensationalistic - merely to raise some questions.

Ken van Wyk

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

Date:    Thu, 09 Nov 89 10:50:00 -0500
From:    [e-mail]
Subject: 386 Isolation

The isolation hardware in the I386 makes it possible to construct a
contained execution environment in which all the effects of execution
are contained within the envrionment.  Such an environment would be a
useful place to test untrusted programs.

Has anyone constructed such an environment?

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

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

Date:    08 Nov 89 02:38:45 +0000
From:    [e-mail] (Kelly Goen)
Subject: Pam Kanes book and the CVIA

Hi I am passing this note on for the CVIA... no endorsement is made nor
representation implied by Amdahl Corp or Onsite consulting as to the
information that follows:

   I am the Acting Technical Director of the National BBS Society and,
though I spend a great deal of time on computer virus related
activities, I am not an active participant in any of the virus
discussion forums, such as Virus-L.  I do keep current with important
virus issues and virus-related publications and occasionally come
across something that requires comment.  Pam Kane's book "V.I.R.U.S. -
Vital Information Resources Under Siege" from Bantam Books is one such
thing.
     Aside from the many technical inaccuracies and misleading product
information contained in the book, Pam Kane's portrayal of the
National BBS Society, the Computer Virus Industry Association and John
McAfee's involvement in each is highly charged and grossly fallacious.
Her assertion, for example, that Mr. McAfee 'owns' the National
Bulletin Board Society and controls its virus-related activities is
absurd to the point of comedy.  The claim that the donation of a
five-line bulletin board, months of unpaid time, and the
responsibilities of coordination for a loose-knit and highly
independent group of 2,000 SysOps is "ownership" cannot be taken
seriously.  Her entire discussion of the National Bulletin Board
Society shows a blatant disregard for the facts and an alarming lack
of understanding of the dynamics of virus research.
     More amazing, though, is her recollection of the events
surrounding the formation of the Computer Virus Industry Association,
an event that I witnessed first hand.  Ms. Kane would have us believe
that Mr. McAfee was strongly interested in having herself and other
small antiviral product vendors as members and went out of his way to
try and force membership on these companies.  My own recollection was
that Mr. McAfee extended these invitations out of politeness.  It is
hard to imagine why an organization that includes Microsoft, Lotus,
Novell, Boeing Computer Services, Amdahl, Locus, Fujitsu, Ford
Aerospace, Martin Marietta and 35 other such companies would be so
interested in having Panda Systems as a member.
     I asked for and received permission from Mr. McAfee to include
part of a May 2, 1988 letter from Mr. McAfee to Kate Drew-Wilkerson
describing his intent to form the CVIA.  I hope this puts his intent
in proper perspective:

"May 2, 1988

"Kate,
"    It is clear, at least to me, that computer viruses will not
go away of their own accord.  On the contrary, they must, based
on all known laws of statistics, increase in prevalence.  What we
see today is merely a shadow of the problems we will face in the
future.  The number of individual strains will increase at some
linear rate, and the incidences of infection will increase
geometrically.  This much is clear.  The time frame is the only
unknown.
"    Accordingly, I feel that the most urgent need is to
organize.  A consortium of hardware and software developers
focused on the unique problems posed by an impending rash of
infections is Priority One.  For this to work, we mustobviously
have the corporate computer industry leaders involved.  How to do
so at this juncture is the problem.  The companies that shape
the computer markets and policies have not yet been directly
impacted, and by and large they dismiss the issue.  In time this
will change.  For now, however, I will content myself with the
three or four security firms who have branched out into the
computer virus marketplace and with whom I have established a
rapport.  We can jointly form the foundations for the later entry
of the industry giants.
"   From a sense of responsibility, and to embark with the
necessary open forum required for success, I will extend an
invitation to all parties that are known to me to be active in
the virus field.  It is doubtful, however, given the existing
antagonism between the various vendors, that I shall have much
success at achieving a quorum.  In truth, I am counting on the
probability that those vendors who would prove embarrassing as
members will, for obvious reasons, decline participation.
...
"    /s/John McAfee"

     I would like to thank the moderator of this virus forum for
providing a means of voicing my viewpoints in what I feel is an
important computer virus area.

Aryeh Goretsky, Acting Technical Director
National BBS Society
1429 Dry Creek Road
San Jose, CA  95125-4617
408 265 8499

               Kelly Goen/ Cybernetic Systems Specialists Inc.

Disclaimer: neither Amdahl Corp nor Onsite consulting offer any
representation warranty or guarentees as to the accuracy of the
information in this e-mail.

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

Date:    Thu, 09 Nov 89 12:52:00 -0500
From:    "Joseph M. Beckman" <[e-mail]>
Subject: Undecidability

The hypothesis of viral detection is that it is an undecidable task to
determine whether an arbitrary program on an arbitrary "machine"
contains a virus or not.  This does not mean the viral detection
question is undecidable.

First, one is primarily interested in a subclass of the question.  This
subclass is a Type II error, or false acceptance (saying a program is
virus free when it is not).  Crocker & Pozzo have argued that it is
feasible to create a filter which has a Type II error rate of 0.
Naturally, some programs without viruses are rejected by a filter of
this type.  See their paper in the 1989 IEEE Security & Privacy
Conference Proceedings.

Second, neither programs nor machines are arbitrary in the real world.
One can certainly think of machines (and then of programs running on
those machines) where it can be trivially and without error shown
whether a particular program is infected with a virus or not.

All of this assumes that one has a definition of "virus."

Joseph

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

Date:    Thu, 09 Nov 89 12:49:00 -0500
From:    <[e-mail]>
Subject: RE: MacWight dilemma (Mac)

    Possible (though unlikely) solution to the MacWight (MacWrit, or
whatever) Virus:

    Anyone out ther familiar with Timbukto?  That nice little DA that
allows one user on a net to actually attach his mac to another running
on the same net.  Even take over the other mac if the other person
does not know what is happening.  That way it is possible to have
something change right before your eyes if you are on a net, running
Timbukto and have someone else (who is probably in hysterics) running
Tim on another mac on the net.  Try capturing someone's mac when he's
netTrek and just have fun with the poor boy.

                        it's possible...
                                   Alex Z... . .  .

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

Date:    Sun, 05 Nov 89 15:01:02 +0000
From:    Alan Solomon <[e-mail]>
Subject: Details of Ogre, Dark Avenger, etc. (PC)

There has been a number of people recently calling for information
about some of the newer viruses, like Ogre, and Dark Avenger.  What
follows are excerpts from the manual of a commercial product;  it's OK
for me to post this, as I wrote it and have the copyright!  I shan't
mention the name of the product, but I must apologise that the pages
of the manual do refer to various components of the product.  Where it
refers to Findvirus, please take this as meaning any virus scanning
program that knows about the virus in question;  when it refers to
Peeka, please take this as meaning any disk sector editor.  The
paragraph numbers are the chapter numbers in the manual.

I've taken the liberty of calling Ross Greenberg's discovery Fumble
instead of Typo, as there is already a Typo in the literature, and we
don't want two viruses with the same name.  Sorry, Ross.

If anyone finds any errors or significant omissions in these
descriptions, please respond via email or fax to me directly.

Finally, could I please lay one myth to rest.  Datacrime (called
Columbus day in the US) does the low level format on October 13th and
every day thereafter until December 31st.  It does this in versions
1168, 1280 (infective lengths) and Datacrime II.  It does NOT do
anything on October 12th, and Datacrime II does NOT go off on Jan 1 to
Oct 12th.  Datacrime II refrains from the format on Mondays.  The
whole October 12th thing was caused by a misunderstanding about dates,
picked up by the media and turned into a factoid.
The other important thing about Datacrime, is that it is extremely
uncommon indeed. We have had no (zero, nil) cases in the UK, and I
know of only two cases in Holland.  Does anyone know of any
*confirmed*, definite, sightings? Apart from Fridrik's self inflicted
accident, of course :-)

Dr Alan Solomon                Day voice:     [phone]
S&S Anti Virus Group           Eve voice:     [phone]
Water Meadow                   Fax:           [phone]
Germain Street,                BBS:           [phone]
Chesham,                       Fido node:     254/29
Bucks, HP5 1LP                 Usenet:        [e-mail]
England                        Gold:          83:JNL246
                               CIX, CONNECT   drsolly

[Ed. Because of the length of the excerpts, I've sent them to the
comp.virus documentation archive sites.  Access information will be
posted shortly.]

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

Date:    Thu, 09 Nov 89 13:51:40 -0600
From:    [e-mail] (Vince Laurent - work id)
Subject: Another attack?!? (PC)

We have encountered something that appears to be a virus of some sort.
The symptoms are :
     1. When an EXE file is run that is 'infected' the screen gets lines
        and garbage that looks like 'snow' (TV term there...)
     2. After a few runs it changes the file length to 0.
     3. When the disk is checked using some utilites there are numerous
        'bad sectors' scattered on the disk.
Side Note: The color of the 'snow' is the same as the last application that
           ran (ie when Norton Editor is run with a green screen - there is
           green snow, white screen editing makes white snow, etc...)

I have not been able to 'capture' this virus to get a look at the code. I
know of 3 cases so far, some of my coworkers have run across it too.

Any ideas on what it might be?

                        ---------------------------------------------
                        | Vincent J. Laurent                        |
                        | Help Desk                                 |
                        | Computing Affairs                         |
                        | Southern Illinois University - Carbondale |
                        | CA6692@SIUCVMB                            |
                        ---------------------------------------------
p.s. please! no comments about yellow snow...

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

Date:    Thu, 09 Nov 89 15:17:25 -0400
From:    "Joel B. Levin" <[e-mail]>
Subject: Re: Sophisticated Viruses?

>I don't agree with you on any of these points, Terry. Say, on the
>Macintosh all calls to ROM are done through trap vectors in RAM. These
>trap vectors are patched by the system file (to fix bugs), by some
>programs and by all anti-virus tools. However, it doesn't take a
>genius to figure out that one could restore the trap vector to it's
>original value and thereby bypassing the "safe" system.  . . .
> . . . A patch like this wouldn't occupy much space and is quite
>simple to write.

Except that when system patches or INIT patches or program patches to
the traps were removed by the virus (and how would the virus decide what
value to restore them to?--this is different for each ROM and system
release version) the user would certainly be likely to notice the
resultant changed program behavior -- or system crashes.

    /JBL

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

Date:    Thu, 09 Nov 89 14:51:40 +0200
From:    Y. Radai <[e-mail]>
Subject: Re: Checksum programs; Hardware protection

  Concerning checksum programs, Paul Kerchen writes:
>           where does one store these checksums and their keys?  If
>they are stored on disk, they are vulnerable to attack just like
>programs.  That is, a virus could infect the program and then update
>its checksum, since the key must be somewhere on disk as well (unless
>the user enters it every time they compute a checksum--yecch!) and one
>must assume that the checksum algorithm is known.  Or,
>more simply, a virus could simply wipe out all the checksums,
>leaving the user to decide which files were infected.  Storing the
>'sums off line would insure security, but at what cost?  Checking
>and updating the 'sums with any frequency would become tedious at best.

  First, let's rule out the possibility of wiping out the checksums.
To be successful, a viral attack (as opposed to a Trojan Horse attack)
must not be obvious.  Such an action would immediately be noticed.
That leaves us with the more subtle action of altering checksums.
  Now there are two types of CSPs (checksum programs), sometimes
called "dynamic" and "static", and most of Paul's remarks seem to be
based on the assumption that we are using the dynamic type.  Dynamic
CSPs are resident programs which checksum each program which is execu-
ted just before its execution.  A well-known example is the checksum
feature of FluShot+.  Static CSPs are non-resident programs which
checksum a list of many files on demand, usually at boot time by vir-
tue of being placed in the AUTOEXEC.BAT file.  An example is Sentry.
  Now the dangers described above by Paul are no problem for static-
type CSPs.  In this case one can keep the CSP, along with the CSB
(checksum base) and key (generating polynomial in the case of a CRC),
on a write-protected, non-infected bootable diskette, and execute the
CSP from that diskette after cold-booting from it.  Since the CSP is
static, this need be done only once per boot, and the additional in-
convenience relative to doing this from the hard disk will be very
slight.  (In fact, there are even utilities which allow you to specify
that the program is to be executed only once a day, once a week, etc.
even though the command is in AUTOEXEC.BAT.)
  But suppose one wants to execute the program from the hard disk any-
way.  We can still foil the checksum forger by simply requiring the
user to supply the key interactively.  "Yecch!", says Paul, but he is
probably thinking of dynamic checksumming.  Again, if one uses static
checksumming, the key need be supplied only once per boot at the most.
  Now let's suppose we're using a dynamic-type CSP and prefer the con-
venience of doing everything from the hard disk.  Would this really
make the checksum and keys vulnerable, as Paul claims?  Even if it's
true that *theoretically* a virus could find the CSB and key and then
alter the former, in practice that seems to me rather unlikely for a
variety of reasons:  First, if the CSB is stored under a name that is
not fixed, how would the virus find it?  If it does it by searching
all files on the hard disk looking for a certain type of content, then
infecting some file and computing its new checksum from the key which
it has discovered and updating the CSB, that would take a lot of time.
One must remember that any modification in a program which causes it
to take much more time than usual is likely to be noticed by the user,
causing him to suspect a virus.
  Secondly, forging checksums would make a lot more sense if there
were a single CSP which was used by a majority of the users of a
given type of computer.  But what good does it do to write a program
to forge checksums used by a particular type of CSP when it is use-
less on the overwhelming majority of computers?  Unless the virus
creator is satisfied with attacking a very limited environment, such
as a student lab, in which all computers use the same CSP, checksum
forging hardly seems worthwhile.
  This is not to say that there are no dangers to CSPs.  But checksum
forging is not the main one.  On most systems there are CSP-fooling
techniques which are not only much faster and independent of the par-
ticular CSP, but also easier to write.
  To give a PC example, suppose the hard disk and RAM are infected by
a boot-sector virus which hooks Int 13h in such a way that any attempt
to read the boot sector results in reading the sector in which the
virus has stored the original boot sector (i.e. it works like the
Brain virus except that it infects the hard disk also).  If the com-
puter is booted from the hard disk, the CSP will be activated only
after the virus has installed itself in RAM, hence checksumming the
boot sector will not reveal that the boot sector has been modified.
  This particular trick can be overcome by booting from a clean disk-
ette before activating the CSP.  But on the PC, at least, there are
several other ways of fooling a naively designed CSP which cannot be
overcome in this way.

  Chuck Kichler says things similar to what Paul says above, except
that he suggests looking in the program (the CSP) instead of in the
CSB.  The answers are similar.  However, he also suggests using a
hardware device.  This is not a new idea, and there is at least one
commercial implementation of this for PCs, called Disk Defender, con-
sisting of a card placed between the disk drive and the controller.
It comes with software for dividing the hard disk into two logical
drives, one of which is left unprotected for necessary writing, while
the other is completely write protected, except when it is necessary
to transfer files to it.  I agree that this is one of the best types
of anti-viral protection.  But even if we ignore the tedious installa-
tion required (if the disk is not initially empty) and the relatively
high price ($240, last I heard), one should not assume that it neces-
sarily provides absolute protection; it may still be possible for a
virus to infect the normally protected drive during those periods when
the protection is removed in order to transfer new files to it.

                                     Y. Radai
                                     Hebrew Univ. of Jerusalem, Israel
                                     [e-mail]

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

Date:    Thu, 09 Nov 89 14:56:05 -0500
From:    "Mark S. Zinzow" <[e-mail]>
Subject: Ping Pong virus (PC) at UIUC

This is a slightly edited copy of our local warning.

Today (Thursday, November 9, 1989) the Ping Pong B virus was found
on an XT in Newmark hall here at the University of Illinois at
Urbana-Champaign.  This is the third virus to infect IBM PC's here.
The previous PC viruses were Brain and Jerusalem.

This virus is a boot sector infector and also goes by the names
Bouncing Ball, Italian, VERA CRUZ, and VERA CRUZ B.

Please use scanv48.arc (anonymous ftp'able from uxe.cso.uiuc.edu
in the directory pc/virus) to search systems for infection, and
unvir6.arc (from the same place) to remove the virus from infected
systems.  VIRUSCAN, the name for the package of programs in
scanv48.arc, is a shareware product.  Just this week CSO has
purchased a site license for the U. of I. so you may ignore the
request for a $25 registration if you are using this software here.

SCAN.EXE (in scanv48.arc) will report two versions of Ping Pong when
it is found.  This is a bug, the B version also triggers the message
for the non-B version.  So far, we think we only have one version
of this virus floating around.

The program IMMUNE by Yuval Ratavy in unvir6.arc will make your
system immune to the Ping Pong, Jerusalem, and several other
viruses.

Please call me (244-1289 or email [e-mail]) if you
find a copy of PING PONG as I'm trying to figure out the extent and
locations where this virus has spread.

In the local versions of this announcement, excerpts from the following
VIRUS-L Digests were included:

VIRUS-L Digest            Wednesday, 18 Jan 1989        Volume 2 : Issue 18
 Subject:     Re: The Ping-Pong virus (PC)

VIRUS-L Digest             Thursday, 9 Mar 1989         Volume 2 : Issue 61
Subject:     Re: Bouncing ball virus (PC)

VIRUS-L Digest              Friday, 10 Mar 1989         Volume 2 : Issue 62
Subject:  bouncing ball virus (PC)

VIRUS-L Digest            Wednesday, 10 May 1989       Volume 2 : Issue 112
Subject: Yet more on SYS (PC)

VIRUS-L Digest              Friday, 12 May 1989        Volume 2 : Issue 114
Subject : 1 byte can save us from the Ping Pong virus (PC)

- -------Electronic Mail---------------U.S. Mail---
ARPA: [e-mail]         Mark S. Zinzow, Research Programmer
BITNET: [e-mail]         University of Illinois at Urbana-Champaign
CSNET: [e-mail]      Computing Services Office
 "Oh drat these computers, they are  150 Digital Computer Laboratory
   so naughty and complex I could    1304 West Springfield Ave.
  just pinch them!"  Marvin Martian  Urbana, IL 61801-2987
USENET/uucp: {uunet,convex,att}!uiucuxc!uiucuxe!zinzow
Phone: [phone]  Office: CSOB 110 \markz%uiucvmd

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

Date:    09 Nov 89 23:09:50 +0000
From:    [e-mail] (Paul Kerchen)
Subject: Re: virus problem undecidability

[e-mail] (Peter W. Day) writes:
>A note to the virus-l digest of 6-Nov-89 said that "the virus problem (at
>least detection anyway) is undecidable."  Does anyone know if there are
>any papers where this result is proved? Or where the problem is
>shown to not be NP complete? Or even where the problem is stated
>precisely?

(Sorry about the mail loop, Peter)

I base my arguments upon Fred Cohen's paper "Computer Viruses: Theory
and Experiments," which can be found in _Computer Security: A Global
Challenge_ ( a collection of security-related papers).  In this paper,
Cohen talks about the undecidability of detecting viruses in a program
and proves why this is the case (although, purists wouldn't call it a
proof).

Paul Kerchen                            | [e-mail]

[Ed. The cited Cohen paper was also published in the _Computers and
Security_ journal (though I don't have an issue number), as well as
directly from Dr. Cohen.]

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

Date:    Thu, 09 Nov 89 20:46:04 -0600
From:    [e-mail] (Jim Wright)
Subject: New IBMPC anti-virals

More anti-virals.  It's getting hard to keep up these days...  :-)

In brief:

alert14g.zip    Checks files for changes, use in AUTOEXEC
ckot094.zip     *** Serious bugs, do not use ***
datacure.arc    Removes DataCrime virus and prevents damage
m-dav.zip       Removes Dark Avenger virus
netscan.zip     Network compatible program to scan for viruses
scanrs48.arc    Resident program to scan for viruses
scanv48.arc     Scans files, directories, drives for viruses
validat3.zip    Use this to check downloads for integrity


alert14g.zip
        Update to the alert13u program in the archives.  Add to your
        AUTOEXEC and it will check the files you specify to make sure
        they have not changed.  Free to government, shareware otherwise.
ckot094.zip
        CHECKOUT, a shell program to simplify use of scanv when scanning
        multiple archives.  Shareware.  WARNING!!!!  This program has a
        tendency to delete any file it can find.  This is a rather nasty
        bug.  I would recommend you not use any version of this program
        until an update is released and independently tested.  It should
        already be removed from the anti-viral archives.
datacure.arc
        A working version of the DataCure program to replace the
        apparently mangled version I got earlier.  Includes a program
        to cure infected files and a program to prevent the DataCrime
        virus from zapping your disk.  Shareware.
m-dav.zip
        A program to remove the Dark Avenger virus.  Shareware.
netscan.zip
        Network compatible program to scan disks for viruses.  An
        update to the previous archive of the same name.  This program
        is not quite shareware, in that a site license is required
        for continued use rather than a simple registration.
scanrs48.arc
        Resident program to scan programs for viruses before execution.
        Update replaces previous version.  Shareware.  Includes the
        VALIDATE program.
scanv48.arc
        Program to scan files, directories and drives for viruses.
        Update replaces previous version.  Shareware.  Includes the
        VALIDATE program.
validat3.zip
        Checksum program to use for validating downloads.  Run this on
        a file, note the numbers it gives, and compare this with
        the numbers provided by a trusted source.  What is a trusted
        source?  That is being worked out. :-)

Jim

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

Date:    10 Nov 89 07:38:05 +0000
From:    [e-mail] (Kelly Goen)
Subject: Re: future viruses on a PC Pull plug before cleaning

Sorry again turning off power will stop the current execution of the
virus...  but... unless you are perfect in your safe computing habits
and your tools are up to snuff and you give your harddisk an
engineering prep as you power up and ALL your software is clean.. you
can still be hit upon power up...  following post you invok int19 to
read the boot tracks in loc 7c00 it is at this point you are first
vunerable...and not under control of ANY antiviral tool I have heard
about...(VIRUS_PROOF pc designs not withstanding... even cd-rom has
been infected during the production of shareware libaraies...)  but
you wont incurr damage to your data while power is off but neither can
you get to it either...I am not saying the problem is unsolvable nor
hard to deal with just realize the power off switch is no REAL
protection some time or another you will eventually power up...
    cheers
    kelly

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

Date:    10 Nov 89 07:53:56 +0000
From:    wugate!smu.edu![e-mail] (Bob Mazanec)
Subject: In Search Of Virus Info

I am trying to find any and all information available on computer (UNIX
& others) viruses for a report in an ethics class (gee, i bet this
stuff might even be useful to me in running my little VAX, huh?).

Please E-MAIL me any information you might have (or even just references to
magazines/books that might have same) on
    known viruses
        what/where/when/how/etc.
    psychology of virus writers
    immunology
        what can/has been done
    bug exploitation/fixing
    etc.

MANY Thanks in advance!!
Robert L. Mazanec @ Southern Methodist University
{attctc, convex, texsun}!smu!mazanec == [e-mail]

DISCLAIMER: You think they TAUGHT me this stuff??

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

End of VIRUS-L Digest
*********************
Downloaded From P-80 International Information Systems 304-744-2253