VIRUS-L Digest   Monday, 16 Sep 1991    Volume 4 : Issue 161

Today's Topics:

Encrypted search strings
Scanners
Virus Simulator
Virus Simulator
NAV 1.5 + Desqview (PC)
IBM Anti-Virus Miscellany (PC)
INFO PLEASE: self-replicating-systems
Re: Preventing boot from floppy - problem with Int 13 from TSR (PC)
FAT Infection (PC)
Name that virus! (PC)
Virus Simulator
Stoned virus
Help needed to cure Joshi virus (PC)

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 [email protected] (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: [email protected].

  Ken van Wyk

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

Date:    Tue, 10 Sep 91 22:10:35 -0700
>From:    [email protected] (Fred Waller)
Subject: Encrypted search strings

[email protected] (Fridrik Skulason) writes:

> There are several products which only rely on published search
> strings, but they are not very secure - virus writers have
> access to the same search patterns and they often modify their
> viruses so they will not be detected by those patterns.

One sees this assertion often, and just as often I wondered how
true it really is.

If we consider the 500 or so commonly-recognized main types, the
immense majority are either "originals" or coded "variations" in
which the code derives from a previous virus in an evolutionary
manner. When a new virus appears, the search strings determined
for previous version(s) are frequently useless, and new ones
become necessary. A virus writer has no need to fool around with
the previous virus code to specifically "alter" only those portions
that are used as search strings by the scanners - simply rewriting
his code slightly, without ever knowing the precise search string
used by any scanner, is enough.  All the search-string encryption
in the world doesn't affect him one bit.

Yes, there _are_ a few viruses which have been coarsely altered so
that only that portion which some virus scanner uses as a search
string was changed.  But these are in the minority and their number
does not provide credence to the theory that encrypting search
strings for this purpose is a practical necessity.

As a proof of this, IBM has never encrypted the great many search
strings used in their VIRSCAN product.  Perhaps Dave Chess could
tell us if, in their wide experience, there have been many
_actual_ instances of viruses intentionally changed to avoid
detection by their string scanner?

My own feeling is that string encryption is a competitive tactic
and is not related to user or program security. Its purpose
is to prevent competitors from learning those precious search
strings and using them in their _own_ scanners... At least
one publisher of scanners has "copyrighted" (?!), and then
"licensed" his search strings to others.

> Yes, if it indeed uses the patterns included in the virus
> simulator - but how can you know if it does ?

Very simply: if the scanner thinks it has "found" a virus, then
obviously its search string is the same.

> I also maintain that it is advisable to use a couple of scanners,
> which use different set of patterns (or a single scanner using
> two different sets), as it increases the chances of detecting
> real-world viruses.

Hmmm... no, this doesn't help in the case of the Virus Simulator.
The Virus Simulator seems to have anticipated this: it inserts
_several_ search strings in each one of its fake viruses!  So
various scanners, using different search strings, will each "find"
a "virus" in its files.

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

Date:    Tue, 10 Sep 91 22:03:02 -0700
>From:    [email protected] (Fred Waller)
Subject: Scanners

Writes Bill Arnold of IBM:

> I rarely see complaints that virus scanning is a non-specific
> approach.

It aims at being virus-specific, but the general public doesn't
realize just how non-specific a procedure it is to look for a few
bytes of code and, on having found them, announce that "this file
is infected with the ABC virus".  There may exist reasonable
correlation between a given virus and a given chosen search string,
but as a general method, such comparison is very non-specific.  No
search string should be assumed to exist only in a virus, which
the scanners assume.  Rosenthal's Virus Simulator proves just that,
if proof was ever needed.

> Seriously, the reason that vendors use identification strings is
> that it is *easy*; id (or search) strings are easy to extract,
> easy to transmit and share, it's easy to write efficient scanners
> for search strings, etc. Search strings also happen to be compact
> (at least relative to the size of most of the viruses that they
> detect).

Those are very practical reasons. I have no trouble recognizing that.

> Precise identification doesn't require much more space per
> virus, but it does require a complete analysis of each virus
> to be reliable.

But why do we need "precise identification"?  As a user, I don't
much care whether the virus infecting my system is the "Mpghffhmx
Virus, version 1-A" or version 1-B, five bytes different. Nor
should anyone. Yet, the entire antivirus industry was based from
the beginning on the idea that it was somehow indispensable to
"name" and "identify" each "virus".  To a large extent, the
industry still carries that "mission".  The idea that defense
against computer viruses must include "precise identification"
is rather peculiar and unsatisfactory.  In this sense, hardware
protection, such as has been suggested here for write-protecting
hard disks, would probably be much simpler, less expensive,
more durable and perhaps far more effective than any software
approach.

I often wonder if we shouldn't credit the virus-naming penchant of
antivirus publishers (and the attendant publicity), as well as the
quest for "precise identification", with being at least partially
responsible for the extraordinary proliferation of new viruses, and
the concomitant increase in virus incidents worldwide.  I'm not
referring to any possible collusion, or virus-production, by anti-
virus entities, but to the obvious invitation that "orthodox" virus
authors must feel to rise to the challenge and produce new
creations that could trick a given scanner, if only ephemerally.

> The virus needs to be mapped, the constant extents in the
> virus need to be determined, a degarbler functionally identical
> to the virus degarbler may need to be written, etc.

If I were writing such software, I would seldom bother composing
dergablers.  Each encrypted virus has its own degarbler built in.
Why not just use that?  It usually works rather well... <g>.
Sliding-window encryptors do not respond well, but the rest do.

> There's certainly room for improvement; search strings are
> a rather primitive identification mechanism.

Yes, and assuming that "identification" is what is really needed.
As mentioned, I don't think it matters what the peculiar version
and subversion (!) of a virus are.  I only want to prevent it from
invading my system and from multiplying on it.  That's all *any*
user wants.  In practice, virus scanners have not accomplished
that.  In fact, some contend that scanners have accomplished just
the opposite.  Now, Rosenthal graphically demonstrates how fallible
scanners really are.  So, from both theoretical and practical
viewpoints, virus scanning is not useful.

And from what I've seen so far, the "heuristic virus analyzers" are
even worse than the scanners in the number of false alarms they
produce.

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

Date:    Tue, 10 Sep 91 22:13:05 -0700
>From:    [email protected] (Fred Waller)
Subject: Virus Simulator

William Walker ([email protected]) tried to summarize pro and
con postings made on the subject of Rosenthal Engineering's Virus
Simulator. Among other things, he quoted Tim Martin saying:

"The Virus Simulator... will simply generate false security and
 false paranoia..."

Well, it could also be said that the virus scanners are the ones
generating false security, and the Virus Simulator is exploding
that. The Virus Simulator may actually help remove some of that
false security. Regarding "false paranoia", all paranoia is, by
definition, false.

> It seems to me that the real basis for the disagreements about
> the Virus Simulator are its effects in the real world.

I would say that the cause for much of the criticism (and some
of the abuse) heaped on Rosenthal is that the Virus Simulator
publicly exposes a known but generally-tacit weakness of all the
string scanners.  Mostly, what we are seeing is a reaction by
software publishers at having a weakness of their products so
openly exposed. That may not have been Rosenthal's purpose, but
it's the effect that the software publishers are seeing and
obviously disliking, and reacting to.

> But one subject which both sides have missed is cleanup.
>
> If the "bait" files contain only the signatures, then how
> can one test the removal capabilities of an anti-virus package?
> You can't.

I think Rosenthal never said that his program could test the
_removal_ capabilities of virus scanners. It would have been nice
had it been able to, but it isn't.  Many scanners have rather poor
removal capabilities anyway.  Mostly, they are meant to act as
detectors. Rosenthal's Virus Simulator was apparently meant to test
their ability as detectors, not removers. Frankly, it doesn't really
test the scanners in quite the way Rosenthal said. What it does, and
rather well, is expose a glaring deficiency of such software, and
shows that the scanners aren't nearly as reliable as their
publishers might have prospective buyers believe. Rosenthal's Virus
Simulator does this: it shows that virus scanners can be made to
produce false alarms at the incredible rate of 100%!!! Of course the
antivirus publishers have no kind words for it. Would anyone expect
otherwise?

> Some comments have dealt with the problems of unscrupulous
> people using the simulator to leave simulated viri lying around.

Yes, but frankly, unscrupulous people don't need to leave
_simulated_ viruses "lying around"; unscrupulous people put _real_
viruses in your system.  In any case, remember that the  majority of
computer virus `infections' are not the work of unscrupulous people:
most of them are unintentional. Only the first release, or a few
after that, are probably intentional. That, after all, is the nature
of computer viruses.

> Patricia Hoffman's VSUM document is an excellent starting point.

I have to disagree.  While Hoffman's VSUMxx document makes colorful
occasional reading, it's not a serious substitute to testing
scanners to see whether they actually do or do not detect the
viruses they *claim* to detect.  Hoffman's VSUMxx is heavily biased
in favor of one vendor (McAfee Associates), and has often neglected
to even mention up-to-date competitive products, as others have
noticed here.  Hoffman's VSUMxx contains many errors of fact; even
after being publicly pointed out, they have remained uncorrected. In
any case, the VSUMxx document was never intended as a competitive
evaluation. And it couldn't test a given scanner in every particular
environment that every prospective buyer might wish to test the
scanner in.  No, I don't think there is a substitute for individual
testing.  Those prospective buyers who wish to conduct their own
tests should be able to do so. Unfortunately, they can't, because
the necessary large collections of test virus samples are not
available to them for that purpose. Nor is there a truly independent
testing organization; most of the suggested ones consist, one way or
another, of the same anti-virus industry members that produce the
software to start with.

The problem of testing antivirus software is not trivial. It is a
very real one and one that is bound to become worse as time goes on.
Even assuming that all vendors agree on a standardized testing
protocol and agent, it would still be desirable for the larger
prospective buyers to conduct their own testing and evaluation.

Finally:

> People who are tasked with finding and removing viri do not
> like wasting time tracking fake viri

It shouldn't be necessary to `track' them down at all. Fake viruses
do not self-reproduce! If one is found, it's likely to stay in one
place. But I think the problem derives not so much from the presence
of the Virus Simulator as from inadequacies of the scanners, which
are unable to tell a fake virus from a real one.  The main task of a
virus scanner is, by definition, to identify viruses. They fail at
it, rather miserably, as the Virus Simulator demonstrates.

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

Date:    Tue, 10 Sep 91 22:07:10 -0700
>From:    [email protected] (Fred Waller)
Subject: Virus Simulator

In answer to a post, [email protected]
(Vesselin Vladimirov Bontchev), writes:

> Yes, indeed, and this is a quite old and well-known problem. It
> is still unsolved, and I don't see it solved in the near future.

Perhaps the best way to solve it is to move away from string scanning
as a viral "detection" technique.  The assumption that, in order to
*stop* a virus one needs to *identify* it is, in my view, an
incorrect assumption.

> And the notorious virus simulator is certainly not a step towards
> the solution. It just shows that simple scanning may cause false
> positives (something that everybody knows... or doesn't?).

It's a "step" in the sense that it will make a lot of people aware
of the inadequacy of string scanning as a virus-detection technique.
Not just the few experts (who already know that), but the public.
String scanning _is_ useful at times, but it suffers from so many
conceptual problems that it shouldn't have been instituted as a
universal antivirus method.  Yet, it was.

Vesselin Vladimirov quoted me:

> > instead of complaining about its inadequacy, we might have
> > addressed the reason for the appearance of such software.
> > I fear we are not doing that at all, but should.

And replied:

> Once again? But wasn't addressed it wide enough? At least I've
> seen this problem addressed in most proffessional journals that
> test anti-virus products... Virus Bulletin comes to mind at once.

We shouldn't expect evryone to read the same trade publications...
:-)  But no, I don't think it was addressed.  I certainly haven't
seen anything similar to the Virus Simulator being announced before.
Did I miss something?  If I did, my apologies.

However, I was referring specifically to the rather flaming response
by Fridrik Skulason. Instead of admitting the *reason* why Rosenthal
saw an opportunity to produce his Virus Simulator, Frisk was simply
complaining about how bad the program had to be. It's bothersome
that some members of the virus/antivirus business seem so prone to
censoring or abusing others...   An occupational trait?   :-).
Rosenthal Engineering made a civil, straightforward announcement
here, not very different from the announcements that others make of
*their* software. Imagine the appearance of things if, every time
Frisk announces a new version of F-PROT, Rosenthal were to launch
into a stream of abuse criticizing how F-PROT was a useless program
because it could not remove certain viruses (which it can't), or
gave incorrect identifications (which it gives) or otherwise caused
problems to its users (which it does).

> It doesn't "test" anything. It just fools some (stupid) scanners
> and that's all.

Yes, I am in total agreement with the above. And shows how easy it
is to fool them. How easy it has *always* been to fool them.

> It's normal for SCANV .... IBM's VIRSCAN, TBSCAN, HTSCAN - all
> these are not virus scanners -

Hmmm... could've fooled me, and many other people who call them
"virus scanners", including their publishers.  I wonder why they
all include the word "scan" in their names?  :-)

> ...they are pattern matching engines that verify the presence
> of a pattern (possibly including wildcards) in the files.

Last I heard such "pattern matching engines" were widely called
"virus scanners"... but I'm not adverse to a change of name...
If they are to be called something else now, it's fine with me.

> However, F-Prot and Dr. Solomon's Anti-virus Toolkit are anti-
> virus tools, that also cerefully check whether a file that is
> found to contain a virus signature is really infected.

If they are reliable and do not produce false alarms, like the
scanners do, then they will be more useful. We'll have to wait
<sigh> and see.

> Especially F-Prot probably says that the file is "Possibly
> infected" or "seems to be infected by a new variant of..."
> and refuses to disinfect the file. Check it again, and you'll
> see that I'm right.

I imagine that by "F-PROT" what is meant here is "F-FCHK", the
signature-scanning program in the pre-2.0 F-PROT package. Or its
derivative, the scanning facility built into F-PROT 2.0.   Yes,
both will indeed give two levels of "identification", one `possible'
and one `certain', depending on whether it finds only one or both
of the *two* signature strings it uses for each virus.  No matter,
in both cases, the process is similar and the program is equally
easy to fool into thinking it has found a virus when, in reality,
there are only a few innocent, chosen bytes there.  I imagine such
a two-step process would be the next challenge for Rosenthal's Virus
Simulator.  Actually, it's easy to make a two-string fake virus file
that totally fools F-FCHK. Maybe even cause it to try to "disinfect"
the "virus"?

As far as the "heuristic virus analyzer" built into F-PROT v2.0,
that's another matter: it doesn't use scanning strings at all
so Rosenthal's Virus Simulator files have no effect on it.  But
let us not rejoice too soon: Frisk's "heuristic virus analyzer"
is *extremely* prone to false alarms, much more so than his string
scanner. In fact, it produces more false alarms than any other
virus detector I've tested.  It would be even easier to make fake
viruses to cause it to trigger, in the same way that the fake
viruses cause false alarms with string scanning.  Already many of
my utilities caused it to issue false alarms.

Sorry, but at this stage of the art, I see no advantage in using
these "heuristic virus analyzers" either.

One thing that is rather unpleasant is that the author takes the
liberty of judging what somebody else's program should or should
not be coded like: if it finds something it dislikes, it puts out
a message that "it is a badly-written program".  What gall!
Rosenthal's Virus Simulator is "useless";  the utilities many
cherish are "badly written"; only "his kind" of programs are
"well-written", etc.  I really think such attitude ought to be
controlled.

As an example of *actually* successful antivirus software, I just
downloaded from the McAfee BBS a program called SECURE, by Mark
Washburn.  This is an excellent Interrupt monitor which performs
almost flawlessly and succeeds in stopping every known virus from
multiplying.  Now, I really don't know whether it satisfies
everyone's pet theoretical considerations or not, but I do know
that it *works* extremely well and that it stops every virus I've
tried on it.  SECURE never bothers to identify any given virus,
it simply stops it from replicating. It's very difficult to cause
SECURE to produce false alarms, even intentionally.  It doesn't
interfere with normal program operation. It uses but 4kB of RAM.
I call *that* successful antivirus software.  And, of course, it
remains totally unaffected by Rosenthal's Virus Simulator.

> Oh, well, but this is rather well known... Do we need a special
program that demonstrates it?

At the general-public level, yes!  Some of us might not be overly
impressed with the Virus Simulator, but the majority of lay users
have been `trained' to believe that virus scanners are trustworthy.
Rosenthal's Virus Simulator provides a rude awakening from such
dangerous dreams.

> This only means that you are unable to understand the appropriate
> theory and need such childish example. Well, maybe you're right
> after all - there certainly exist other people that will need it
> too...
>
> What is remarkable is the fact that you consider it as some kind
> of wonder... :-)

Yes, there are many people who will be interested in the Virus
Simulator. But I protest again at the seeming ease with which we
seem to be willing to slight and demean each other here... why
stoop to such expressions at all?  _Ad hominem_ attacks are odious
and achieve nothing except exacerbate the ill will of people. They
don't prove anything; they don't disprove anything. They only make
people mad at each other.  What for?

> Yes. All this means that Rosenthal has fished these signatures
> from the different scanners.

Does it need to mean anything else? So he fished them out. Good
place to get them. Many scanners use strings that were also
determined by someone else. Apparently, so does Rosenthal.

> Therefore, they have been provided by the scanners' authors

This depends on how one defines the word "provided". And if they
were provided, then Frisk was mistaken in suggesting that they
weren't. In either case, it's not relevant whether they were or not.

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

Date:    Wed, 11 Sep 91 09:17:22 +0000
>From:    [email protected] (n. michelis)
Subject: NAV 1.5 + Desqview (PC)

When I am running Norton Antivirus and using desqview, I have
encountered a problem.  NAV only gives a warning beep when an
innoculated file has been altered. It doesn't display the usual
warning box.  This is really annoying as I don't know inside DV if it
was activated because of a virus or because of an innoculated file
being edited.

I am running DV 2.34 and Qemm 5.13 and DOS 5. .
I am wondering if anyone else has encountered this problem.

P.S. I have contacted SYMANTEC AUSTRALIA and they also find the same
problem.
                                    Thanks !!!

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

Date:    11 Sep 91 11:15:01 -0400
>From:    "David.M.Chess" <[email protected]>
Subject: IBM Anti-Virus Miscellany (PC)

A couple random points about the IBM Anti-Virus Product:

 - The announcements I've posted here apply most to the U.S..
   Other countries' IBMs make their own decisions about when
   and how to release any given product.   If you're outside the
   U.S., contact your local IBM representative for information.
   In particular, the fact the IBM U.K. is not currently selling
   the IBM Anti-Virus Product does *not* mean that it no longer
   exists; you just can't get it from IBM U.K. at the moment.
   That was a local country decision, and doesn't affect any
   other countries.  It's still available in the U.S., for
   instance.

 - The $35 price (in the U.S.) is for an "enterprise" license.
   That means that if you're a business, you pay $35 total for
   as many copies as your business (or university, or whatever)
   needs to make for the use of employees.

DC

P.S. I'll be on vacation starting on Friday, and back on the 25th
    or so.  Just in case anyone's trying to get hold of me.  Have
    a non-annoying Friday the 13th!   *8)

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

Date:    12 Sep 91 01:48:41 +0000
>From:    [email protected] (Anthony Dunstan)
Subject: INFO PLEASE: self-replicating-systems

Hello,

I have a friend who is interested in self replicating systems.  Is
there anybody out there who could give us some information?  I know
there is an ftp site with such information, but I don't know the
address.

Any help would be appreciated.

Thanks,
 Anthony.

Please e-mail me directly (address shown below).

- -----------------------------------------------------------------------------
|   Anthony Dunstan    |  Apple Consortium & Sun Shop - Adelaide University |
| A Macintosh CyberMan |           [email protected]               |
- -----------------------------------------------------------------------------

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

Date:    Thu, 12 Sep 91 01:37:56 +0000
>From:    [email protected] (Al Dunbar)
Subject: Re: Preventing boot from floppy - problem with Int 13 from TSR (PC)

[email protected] (Alan J Rosenthal) writes:
>padgett%[email protected] (A. Padgett Peterson) writes:
>>     1: Trap cntrl-alt-del sequence
>>     2: Check for floppy in drive A:
>>     3: Disallow boot if floppy in drive
>
>Won't this leave a window during which the user can insert a floppy
>disk?  Insert floppy but leave the drive door open, press
>control-alt-delete, close the door.

I may have missed the context of this thread, but if the system
protected this way allows any kind of programming, execution of .COM
or .EXE files from A:, or access to DEBUG, they can circumvent this
trap with: JMP FFFF:0000.

- -------------------+-------------------------------------------
Al Dunbar          |
Edmonton, Alberta  |  Disclaimer: "not much better than
CANADA             |                  datclaimer"
- -------------------+-------------------------------------------

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

Date:    Thu, 12 Sep 91 11:17:58 +0000
>From:    [email protected]
Subject: FAT Infection (PC)

I'd like to know if there is a possibility of a virus infection into
the file alocation table. I understand that boot sector viruses are
known but I have not heard about a FAT virus. If this is true, will it
infect the two FATs what a re thepossibilities of losing the index.
What is the repair procedure to fix the FAT if an infection occurs?
Please reply ASAP.

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

Date:    12 Sep 91 15:43:22 +0000
>From:    [email protected] (John Lindwall)
Subject: Name that virus! (PC)

An associate of mine suspects that he is infected with a PC virus.  He
has a program which is 19K in size (a .EXE file).  When this program
is executed, DOS complains that there is not enough memory and it
exits.  Upon re-examining the file size, it can be seen seen to have
magically grown to 23K!

Are there any virus that fit these symptoms?
- --
John Lindwall                   [email protected]
"Oh look at me! I'm all flooby! I'll be a son of a gun!" -- Flaming Carrot

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

Date:    12 Sep 91 04:00:37 +0000
>From:    [email protected] (Ray Mann)
Subject: Virus Simulator

[email protected] (Vesselin Bontchev) writes
in response to a post by Doren Rosenthal on his Virus Simulator:

>I can't believe that F-Fchk has reported your simulation file to
>be INFECTED by any virus. Please, check again. Doesn't it report
>"possibly infected", "new variant of..", etc.? Does it try to
>disinfect you file? And does it succeed? No, I definitvely can't
>believe that.

 I run that test using FPROT 1.16 and the program reported many of
the fake viruses to be "possible infections". It also reported some
of them to be "Infected" for sure, with things like the MG virus,
the 600 virus, the Telecom virus, etc. Not all the fake viruses
triggered FPROT but about 50% did. Only about 10% were determined
to be certain infections.

>First of all, they do not need any virus simulator (or live
>viruses), in order to test the speed and easy of use of any
>anti-virus product. Second, the speed cannot be tested on ONE file
>only; you need huge amount of files to obtain a reliable average
>number. Third, any user (not only the administrators) is able to
>test the speed and easy of use of ANY product (including the
>anti-virus ones), WITHOUT having any kind of viruses - live or
>simulated.

 Let's remember that speed and ease of use are not what we buy
scanners for - we buy them to detect viruses. Ease of use and
scanning speed are important, but they aren't the primary function
of a scanner. Incidence of false alarms is also an important
consideration.  Any test that limits itself to speed and ease is
grossly inadequate. By the way, Rosenthal's virus simulator seems to
have disclosed a real weakness in the area of false alarms...

>>Especially when a collection of hundreds of real
>>viruses is not available
>
>This is a serious and yet unsolved problem, indeed.  My oppinion
>is that such collection should be a vailable at some central
>organization (VTC?, CERT?, NIST?, NCSC?), and this organization
>should perform an objective test of different anti-virus products.

 It might be difficult to find any organization with a large
collection of viruses that is not somehow part of the AV community
and, therefore, potentially biased. If a government agency were to
do the testing, it'd be viewed as impartial, but I think it's not
a realizable hope. An AV consortium such as the NCSA has been
trying to setup will probably run into difficulties. If they test
severely and impartially, there'll only be one winner and many
losers. The losers will see ample reason to abandon the consortiom,
since it's hurting them. If they test less severely, there'll
be many "winners" and a loser or two but candidate buyers will
no doubt see through it and refuse to take the test results
seriously.

Regardless of any centralized tests, large organizations will
probably insist on running their own testing, as they've
usually done in the past with many other products.

> The feedback that you received in this forum (which I
>consider as highly professional) seems overwhelmingly negative...

 I'm not so sure that the Virus Simulator is such a bad idea. It's
no panacea, and it doesn't REALLY test anything, but it offers some
interesting possibilities. For example, it could be useful in
training sessions, where the fake viruses could be used by
instructors to teach scanning procedures, etc. without fear of
contamination with real viruses. Sure, we'll see a number of
pranks, etc., but I'd rather have pranksters using fake viruses
than real ones!

- --- Opus-CBCS 1.14
* Origin: Universal Electronics, Inc. [714 939-1041] (1:103/208.0)
- --
Ray Mann
Internet: [email protected]
Compuserve: >internet:[email protected]

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

Date:    13 Sep 91 07:00:17 +0000
>From:    [email protected] (Brian Cooper)
Subject: Stoned virus

I just started checking my system for viruses.  I've been using
McAfee's SCAN.  My system checked out fine.  I used the /a and
/m options so all the files were checked as well as the boot
sector and memory.  I then started scanning some old floppies
that I had.  I found about a dozen floppies containing the
Stoned Virus in the boot sector.  Since my system was clean,
I just pitched the floppies; none of the programs on the floppies
were important nor were they on my hard disk.

What does it mean when a virus is in the boot sector of a floppy
disk?  How could such a virus become active when there are no files
executable files containing the virus?

Thanks in advance.
Brian Cooper
- --
Brian Cooper
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp:     ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!psgrbbc
Internet: [email protected]

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

Date:    15 Sep 91 19:50:31 +0000
>From:    [email protected] (Dan Ellard)
Subject: Help needed to cure Joshi virus (PC)

A IBM PC clone at my father's office has becomre infected with a virus
that McAfee's virus scanner identifies as 'Joshi'.  The scanner seems
to take care of the virus, but it always seems to pop up again within
a short time.

The principal symptom of the virus (so far, at least) is that it has
become impossible to format disks-- the format operation just never
finishes.  It doesn't appear that any of the data on the hard drive
has been corrupted (or at least not enough to easily notice) but the
disk operations seem slower than usual.

My questions are:
       1. What does he have to do to shake this virus?  He's using
       the most up to date McAfee product, which was highly
       recommended, but doesn't seem to be up to the task.
       2. Does this virus corrupt data, or do anything else
       malicious?
       3. Is this virus very contagious, and how long is the
       dormant period?  As soon as the virus was detected, the
       machine was isolated, but since they exchange data diskettes
       often among dozens of machines, he's wondering if he is
       going to lose ALL his PCs sometime in the future.

Please forgive my lack of details-- I can try to get more specifics
if necessary.

- -Dan

Computer science:  it's only fun until someone loses an eye.

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

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

Downloaded From P-80 International Information Systems 304-744-2253