Handbook of Infosec Terms 2.0/Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso/text/virusl/vl04_115.txt

Internet Message Format | 1996-09-04 | 23.0 KB

From:       Kenneth R. van Wyk (The Moderator) <[e-mail]>
Errors-To: [e-mail]
To:       [e-mail]
Path:      cert.sei.cmu.edu!krvw
Subject:   VIRUS-L Digest V4 #115
Reply-To:  [e-mail]
--------
VIRUS-L Digest   Tuesday,  2 Jul 1991    Volume 4 : Issue 115

Today's Topics:

Rumors
Recalciterant infection with Frodo (PC)
$MUSTAFA, new virus? (PC)
Retrospect Remote vs. Gatekeeper (Mac)
Disk Boot Failure?! (PC)
Re: Can such a virus be written .... (PC)
GUARD - prevents h.d. infection via floppy boot (PC)
Re: Virus protection: what to use
New files on MIBSRV (PC)
Disinfectant 2.5? (Mac)
Re: Two versions of SCANV80.ZIP? (PC)
re: Words

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.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
anti-virus, documentation, 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

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

Date:    Sat, 29 Jun 91 02:05:00 +0000
From:    William Hugh Murray <[e-mail]>
Subject: Rumors

> I just received word of a virus that was encountered during a Mac
> System 7 installation.  Both the keyboard and mouse DIED on three
> machines that just had System 7 installed on them.  The customer
> then attached a voltage meter to the ADB port of a fourth machine
> only to find a unusually high reading.  It appears the virus
> destroys chips on the mouse and keyboard.

I am glad I do not have his job.  I  know that Ken is very careful
about what he posts.  I am reluctant to second guess him.   However,
in the case of this posting, I must.

The posting is potentially more damaging than the damage that it seeks
to avert.

First, it is hearsay.  The author does not cite his source, and claims
no first-hand knowledge of the events that he reports.

Second, it appeals to fear of permanent and irreversible damage from a
program.  Such appeals to fear can never be justified except by carefully
tested conclusions.

Third, it speculates on hardware damage from indirect evidence.  I can
think of far more likely causes for keyboards and mouses not to work
than destruction of chips, particularly, if as the reporter speculates,
the cause is somehow related to the installation of software.

Fourth, while second-hand, it reports something so unlikely as to make
any responsible reporter question his sources and hold his water.  That
is, it reports that programmable behavior of a computer caused permanent
damage to the computer hardware.  The only evidence that any damage that
may have occurred was software related was that the same code had just
been installed on all of them.  Sorry, that is not sufficient evidence
that any damage was software related.

A report of an "unusually high (output voltage) reading" is used to
support the conclusion that the damage was caused by software, when in
fact, that should lead one to the far more likely conclusion that any
damage was related to an abnormally high input voltage.

Rumors of viruses are almost as damaging to public trust as viruses
themselves.   One should not attribute damage to viruses without cause.
One may not justify premature reports on the basis that the virus is
very damaging.  The greater the power attributed to the virus, the
greater, not the lesser, the responsibility to report only what one
knows with a very high level of confidence and authority.  "I just
received word" will not cut it.

I will be very surprised if these events are at all related to software.
If the cause was software, I will be extremely surprised if the symptoms
reported were caused by destruction of chips.  I will not be surprised
to learn that they did not happen as reported, did not happen at all, or
are pure fantasy.  Even if they happened exactly as reported, the report
is still premature and irresponsible.
____________________________________________________________________
William Hugh Murray                     203-966-4769
Information System Security             203-326-1833 (CELLULAR)
Consultant to Deloitte & Touche         203-761-3088
Wilton, Connecticut                     email: [e-mail]
                                        [e-mail]
                                        MCI-Mail: 315-8580
                                        TELEX: 6503158580
                                        FAX: [phone]
                                        Compu-Serve: 75126,1722
21 Locust Avenue, Suite 2D              DASnet: [DCM1WM]WMURRAY
New Canaan, Connecticut 06840           PRODIGY: DXBM57A

[Ed. The moderator's response: VIRUS-L/comp.virus receives a great
number of messages which appeal to fear and/or are purely hearsay.
Long time subscribers will no doubt recognize past examples such as
discussions of disk drives writing to write-protected disks, viruses
destroying monitors, etc.  I generally send a response to the author
requesting that he/she cite some reference and/or provide complete
technical details of any testing and so forth; I have yet to get a
response to such a request...  Occasionally, however, one of two
things can happen.  The first is that I accidentally overlook and
accept the posting.  Mistakes can happen, but I try my best to avoid
them and I try even harder to learn from my mistakes.  The second is
that I decide to pass the message on under the assumption that the
vast pool of technical expertise that we have out on the list will
quickly and decisively dispell the poster's claims.

I also would like add the comment that VIRUS-L, like all/most _public_
discussion forums, cannot guarantee the technical authenticity of its
contents.  The contents of the list are up to the individual
subscribers.  As such, I would strongly recommend treating all
(outlandish) claims with a grain of salt until they can be
independently verified.]

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

Date:    Sun, 30 Jun 91 20:31:32 +0700
From:    Aviel Roy-Shapira <[e-mail]>
Subject: Recalciterant infection with Frodo (PC)

Help please!  I have a recalciterant infection by Frodo or 4096.  I am
not sure about the source of the infection, but somehow it got into my
system.  Clean (V. 77) cleaned the disk alright, but the infection
keeps poping up.  It has become even wierder.  Both Clean, Virus Scan,
and F-Fchk (115) report that all the files on my hard disk are free
from the virus.  But, if I boot from the hard disk, and I run
F-SYSCHK, it says the virus is lurking in memory.  I don't get this
warning if I boot from a floppy.

My config.sys file contains Device=DMDrvr.bin, Device=f-driver.sys,
files=40 and buffers=20.  I don't run any programs or TSR from my
autoexec, which simply states the path and sets a couple of
environment variable.  DMDrvr.bin appears to be clean, as its length
is 8000 bytes or so and it didnot change.

I thought that Frodo was only a COM and EXE file infector, yet it
somehow entered my system and refuses to leave. Any ideas?
Aviel

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

Date:    Mon, 01 Jul 91 17:52:00 +1200
From:    "John, Registry" <[e-mail]>
Subject: $MUSTAFA, new virus? (PC)

Hi,
    Anybody heard of a possible PC virus called $MUSTAFA?
    Don't know too much about it at the moment.  The mouse has stopped
working.  If you look at device drivers, there is one at
       Memory    Size Driver    Program  Attributes
                   NUL       MSDOS    C
    0AAD-0BA7 3.9K $MUSTAFA           CS
    .
    .
    .

There is a file open:
       Name       Ext    Program
    AUX
    CON
    PRN
    $MUSTAFA     (1041)

A memory map shows:
    .
    .
    .
    1036 - 103F  0.2K   TRUMOUSE Environment
    1040 - 2193   69K   (1041)
    2194 - 23BD  8.7K   TRUMOUSE
    .
    .
    .

The partition table and boot sectors look o.k.  Scan 77 doesn't pick
it up.  I am getting Scan 80 (hopefully) and will try that.  If you do
a whereis $mustafa.* it finds it on every directory on the disk (2.7K
long. Looking at the actual directory entries the file doesn't exist.

If anybody has any more info for me please e-mail.

    John

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

Date:    01 Jul 91 02:06:56 -0400
From:    [e-mail] (Edward J. Huff)
Subject: Retrospect Remote vs. Gatekeeper (Mac)

I ran the Retrospect 1.3 remote updater, which sends a new version of
the Retrospect Remote cdev across the network.  Gatekeeper 1.1.1 and
1.2 both log the PBSetCatInfo from '' to 'cdev' operation to whatever
application happened to be running.

The basic problem is: gatekeeper depends on trusting certain programs
to be permitted certain operations, but sometimes, operations can be
performed by an INIT such as Retrospect Remote, while that program is
the "current application," and gatekeeper fails to notice that the
operation was not initiated by the trusted program.

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

Date:    Mon, 01 Jul 91 12:28:37 +0000
From:    [e-mail] (Greg Burlile)
Subject: Disk Boot Failure?! (PC)

Could a virus cause the "Disk Boot Failure" DOS error message to
appear?  We've had this problem with two of our machines.  One of them
we had to reformat so that would could finally get the PC to boot from
the hard drive.  The other computer we were able to boot from diskette
and then reboot from the hard drive.  Prior to that we had a problem
with several computers (including the two I mentioned above) having
their root directory files erased (including the hidden system files).
Could someone please give me some input as to why this is happening.
Is it a virus?  I've run F-PROT 1.13 on these machines and nothing
came up.  I just downloaded a copy of 1.16 and will see if it finds
anything.

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

Date:    Mon, 01 Jul 91 13:40:17 +0000
From:    [e-mail] (Matthew F Ringel)
Subject: Re: Can such a virus be written .... (PC)

[e-mail] (Pete Lucas) writes:
>until the virus has had a look at whats there. Of course the write-protect
>notch/slide is 99.99% effective in my experience at preventing any
>illicit writes; you would, of course, have write-protected any diskette
>you put in the drive before doing the hypothetical DIR command, wouldnt
>you?
>          Pete Lucas

Speaking of that...
    Is it possible for a virus to circumvent an IBM's
write-protection of a disk (if the disk is protected in the stndard
way of covering the notch), or is it something physical that no piece
of software can get around?

Any idea?  I'd love to hear them.
                        -Matthew


}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}}{}{}{}{}{}{}{}{
Matthew F. Ringel                   {}  Internet:[e-mail]
     ...and God saw the light...    {}           [e-mail]
..and said that it was pretty neat.{}    Columbia University Football #1!

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

Date:    Mon, 01 Jul 91 15:20:00 +0300
From:    Y. Radai <[e-mail]>
Subject: GUARD - prevents h.d. infection via floppy boot (PC)

  About half a year ago, someone asked whether there was a way of
preventing infection of one's hard disk on cold-boot when an infected
diskette happens to be in drive A:.  As I hinted a couple of times, I
would soon be announcing a program to do this.  Well, it's called
GUARD and is now available in uuencoded ZIPped form to anyone who
requests it from me by e-mail.
  Some people on this list expressed the opinion that this wouldn't
work on a cold boot, or against partition-record viruses, or that it
could only detect infection but not prevent it, or that it would re-
quire hardware or a special BIOS.  Well, GUARD prevents hard-disk
infection on floppy boot (even cold boot) without using either hard-
ware or a special BIOS.

  The basic idea is as follows:  When you install GUARD, it zeroes out
several bytes of each entry of the partition table (storing the origi-
nal bytes elsewhere in the partition record), so that these partitions
are not recognized as DOS partitions when booting from a diskette, and
it inserts code in the partition record which resets these bytes when
booting is performed from the hard disk.  A command GUARD -G in the
AUTOEXEC.BAT file of the hard disk zeroes the bytes again, thus re-
storing the protection for the next diskette boot.
  Because of the fact that the hard-disk partitions are non-DOS par-
titions when booting from a diskette, no boot-sector or file virus can
infect the hard disk.  A partition-record virus will infect the parti-
tion record of the hard disk *temporarily*, but the viral code will be
overwritten by GUARD's uninfected code the next time booting is per-
formed from the hard disk.

  There's nothing original in the idea of modifying the partition
record for this purpose, although I haven't seen a program which deals
with p.r. viruses in this way.  Note also that it does not rely on a
device driver or any other code outside of the p.r., as most other
programs of this type do.  Another feature is that you can protect
*selected partitions* of your hard disk(s).

  GUARD also contains an option to require typing of a password in
order to use the computer after booting from the hard disk.

  Can GUARD be circumvented by a directed attack?  Of course, but what
anti-viral program can't?  (The closest thing to an exception seems to
be a carefully designed checksum program activated after booting from
a clean diskette.)  However, it's effective against all viruses which
do not mount a directed attack against this type of defense (which
includes all viruses known today).

  Note: I am not the author of GUARD.  I simply beta-tested it, sug-
gested numerous improvements, and wrote the documentation for it.  You
are invited to try it out ("gamma-test" it) and to send me your com-
ments, which I will reply to and/or forward to the author.  (Eventual-
ly GUARD will be uploaded to Simtel20 and other servers as shareware.)

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

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

Date:    Mon, 01 Jul 91 15:38:00 +0300
From:    Y. Radai <[e-mail]>
Subject: Re: Virus protection: what to use

  Aryeh Goretsky gave a good description of the three main types of
anti-viral software.  I think he missed a few important points, how-
ever, so I'd like to contribute a few additions to what he wrote.

 Concerning "filters" (or as I call them, generic monitoring pro-
grams), he writes:
>Filters have the
>advantage of being able to detect new viruses because they are not
>looking for specific viruses, but rather virus-methods.

Correct, but there is another advantage (in comparison to the other
methods he mentions, which can only detect infections *after* they
have occurred): filters can *prevent* infection from occurring at all.

  He then mentions three disadvantages of filters.  However, there are
two others: (1) They can't prevent anything which happens before they
go resident (in particular, boot sector infections).  (2) Being resi-
dent programs, they are more vulnerable to neutralization or circum-
vention by a hostile program than is a non-resident program.

  Concerning "change checkers" (modification detectors), he writes:
>The advantages to change checkers
>are that they will detect known and unknown viruses, like the filter,

True, but a filter can also be effective against immediate-acting
*Trojans*, something that is not true of a change checker.

>it's been theorized that if
>the method of change checking is known, a virus could be written to
>add itself to files in such a way that a checksum identical to the
>known (good) checksum is generated;

This is not possible with a CRC or cryptographic algorithm if each
user's checksums are based on a different key unknown to others and
his table of checksums is inaccessible to a hostile program.  (These
two conditions cannot be achieved in inter-machine transfer of files
to arbitrary users, but they can be achieved when modification takes
place on a given computer, which is what is normally assumed when
discussing viruses.)

  Turning to [known-virus] scanners, he writes:
>And of course, as more
>viruses are added, the scanner gets s l o w e r.

This is true of *most* scanners, but not all of them.  By using a
hashing technique, the scanning time can be kept constant, at the
price of somewhat increased program size.

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


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

Date:    Mon, 01 Jul 91 11:10:06 -0500
From:    James Ford <[e-mail]>
Subject: New files on MIBSRV (PC)

The following files have been uploaded to risc.ua.edu in the directory
pub/ibm-antivirus for anonymous ftping:

scanv80.zip
netscn80.zip
vshld80.zip
clean80.zip
virx15.zip

One last note:  MIBSRV.MIB.ENG.UA.EDU has been removed.  It is probably
going to make someone a nice boat
- ----------
Behind every successful man is a woman who made it necessary.
- ----------
James Ford -  [e-mail], [e-mail]
              The University of Alabama (in Tuscaloosa, Alabama)

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

Date:    Mon, 01 Jul 91 12:39:33 -0700
From:    [e-mail] (Rob Slade)
Subject: Disinfectant 2.5? (Mac)

Recently, the Fidonet "Warnings" echo carried a note about Mac users
having to upgrade to Disinfectant 2.5.  I replied with the information
from John Norstad's posting here a while back:

==========

From: [e-mail] (John Norstad)
Subject: Disinfectant and System 7 (Mac)
Date: 20 May 91 01:50:16 GMT

Thanks to an error in Apple's Compatibility Checker, I've been deluged
with requests for information on Disinfectant 2.5.

If you have installed the Disinfectant INIT on your system, Apple's
Compatibility Checker incorrectly reports that it is incompatible with
System 7, and it recommends that you get version 2.5.

There is no Disinfectant 2.5, and there won't be one! Disinfectant 2.4
works fine with System 7, provided you leave the Disinfectant INIT in

==========

I have now received the following reply:

==========

06/30/91 19:10:49
From: JOHN LENKO
Subj: REPLY TO MSG# 12992 (DISINFECTANT 2.5)
Unbelievers get viruses...at least in this case they do!

This is John's friend Chris, the source for the info..

I already have 2.5, and it is already posted on DDCBBS, in case you do
not believe that there is a version 2.5.  I would suggest looking into
it, for it is not only System 7.0 compatible, but is also able to
recognize the new strain of ZUC, strain C, that is....
- --- TBBS v2.1/NM
 * Origin: Doppler/Deep Cove TBBS - Richmond, B.C. (153/915)

=========

What gives?

=============
Vancouver          [e-mail]   | "If you do buy a
Institute for      [e-mail] |  computer, don't
Research into      (SUZY) INtegrity         |  turn it on."
User               Canada V7K 2G6           | Richards' 2nd Law
Security                                    | of Data Security

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

Date:    Tue, 02 Jul 91 00:37:39 +0000
From:    [e-mail] (McAfee Associates)
Subject: Re: Two versions of SCANV80.ZIP? (PC)

[e-mail] (Rob Slade) writes:
>I retrieved SCANV80.ZIP from the wuarchive.wustl.edu mirror of
>SIMTEL20, but when I went to repost it on a local board found a
>different version.  Both versions appear to be authentic, with some
>minor differences in text files:
[listing of ZIP file contents deleted here...]
>It seems the only differences are found in:
>              README.1ST
>              REGISTER.DOC
>              SCANV80.DOC
>              VIRLIST.TXT
>with the addition of two files:
>              NETSCN80.DOC
>              VSHLD80.DOC

Oops.  The SCAN zip file was released with two extra doc files in it
accidentally.  It was replaced after it this was discovered a few
hours later, but apparently a few copies are circulating...  It's no
cause for alarm, the only difference being that the ZIP file with the
extra two files may take a bit longer to download.

Regards,

Aryeh Goretsky
McAfee Associates Technical Support
- --
McAfee Associates     | Voice [phone]    | [e-mail]
4423 Cheeney Street     | FAX   [phone]    | (Aryeh Goretsky)
Santa Clara, California     | BBS   [phone]    |
95054-0253  USA         | v.32  [phone]    | [e-mail]
ViruScan/CleanUp/VShield | HST   [phone] | (Morgan Schweers)

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

Date:    Mon, 01 Jul 91 20:39:06 -0700
From:    [e-mail] (Rob Slade)
Subject: re: Words

[e-mail] (Johnathan Vail) writes:

> virus - a piece of code that is executed as part of another program
>     and can replicate itself in other programs.  The analogy to real
>     viruses is pertinent ("a core of nucleic acid, having the ability to
>     reproduce only inside a living cell").  Most viruses on PCs really are
>     viruses.
>
> worm - a program that can replicate itself, usually over a network.  A
>     worm is a complete program by itself unlike a virus which is part of
>     another program.  Robert Morris's program, the Internet Worm, is an
>     example of a worm although it has been mistakenly identified in the
>     popular media as a virus.
>     bomb.

Question:

Given that under these definitions boot sector infectors, "spawning"
viri and items such as Mac's WDEF are excluded from "virus", does that
make them all "worms"?

If so, you will have to define "most viruses on PCs", since many of
the more successful PC viri are BSI's.

=============
Vancouver          [e-mail]   | "If you do buy a
Institute for      [e-mail] |  computer, don't
Research into      (SUZY) INtegrity         |  turn it on."
User               Canada V7K 2G6           | Richards' 2nd Law
Security                                    | of Data Security

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

End of VIRUS-L Digest [Volume 4 Issue 115]
******************************************