Shareware Supreme Volume 6 #1/swsii.zip/swsii/201/VL6-10.ZIP/VL6-10.TXT

Internet Message Format | 1993-01-27 | 40KB

From lehigh.edu!virus-l Sat Jan 23 07:21:19 1993
Date: Fri, 22 Jan 1993 12:22:11 -0500
Message-Id: <[e-mail]>
Comment: Virus Discussion List
Originator: [e-mail]
Errors-To: [e-mail]
Reply-To: <[e-mail]>
Sender: [e-mail]
Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas
From: "Kenneth R. van Wyk" <[e-mail]>
To:   Multiple recipients of list <[e-mail]>
Subject: VIRUS-L Digest V6 #10
Status: RO

VIRUS-L Digest   Friday, 22 Jan 1993    Volume 6 : Issue 10

Today's Topics:

Re: Sale of Viri
Re: Measuring polymorphism
Re: How to measure polymorphi
Re: Math Models of Polymorphic Viruses
Re: Infection question (was: Viral Based Distribution System)
Re: How to measure polymorphism
Export restrictions on anti-virus software
Re: on the definition of virus
Virus Calendar
Re: A-V virus
Re: OS2SCAN99 checked (OS/2)
Re: DOS Viruses under HPFS (OS/2)
Re: how to get rid of the Naughty Hacker-1? (PC)
Re: Monkey [Mon] and Multi-2 [M12] viruses (PC)
Re: How do MtE utilizing viruses detect themselves? (PC)
CLEAN removing Jerusalem (Was: Re: Jerusalem (Israeli) Virus (PC))
Re: Clash between FDISK/MBR and scanners (PC)
Mr. BIOS (PC)
Re: Problems with PCs (PC)
Re: New way of opeing files??? (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.  (The complete set of posting guidelines is available by
FTP on cert.sei.cmu.edu or upon request.) Please sign submissions with
your real name.  Send contributions to [e-mail].
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
(comments, suggestions, and so forth) should be sent to me at:
<[e-mail]>.

   Ken van Wyk

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

Date:    14 Jan 93 17:16:05 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Re: Sale of Viri

[e-mail] (Albatross) writes:

>      Is there any law in the USA the prohibits the Sale of Virus
>software to the Public? Or any type of distrubution of such software
>with the sole intent to create business revenew?

I'm no lawyer...just a techie :-)...but my answer would be
"Unfortunately no".  In fact, this has been done, well sort-of...just
consider the "little black book".

Maybe some day some enterprising soul will gather all the viruses
available on the various Vx BBSes - put them on a CD-ROM and offer
them for sale.

As things are now, I don't see any way to stop that - It is difficult
to write a law that would prohibit writing/selling viruses...and any
such law might be challenged as violating the first amendment (isn't
that the "free speech" thing ?)...It is much easier to make laws
prohibiting introducing viruses into somebody's comeputer system...but
still...

As I have said before - the lack of any action against virus writers
is the primary reason why viruses are a problem today.

- -frisk

Fridrik Skulason      Frisk Software International     phone: [phone]
Author of F-PROT      E-mail: [e-mail]         fax:   [phone]

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

Date:    14 Jan 93 11:36:38 +0000
From:    [e-mail] (Vesselin Bontchev)
Subject: Re: Measuring polymorphism

[e-mail] writes:

> - - Difficulty of analysis.  By this metric, the TPE is simpler than the
> Whale, and the Whale is simpler than the MtE.

I disagree with those of your arguments. It is a metric for armouring,
not for polymorphism. The other arguments were very interesting; I'll
think on them...

Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:[phone], Fax: [phone]      Fachbereich Informatik - AGN
< PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [e-mail]    D-2000 Hamburg 54, Germany

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

Date:    14 Jan 93 10:46:30 +0000
From:    [e-mail] (Vesselin Bontchev)
Subject: Re: How to measure polymorphi

[e-mail] (Bill Lambdin) writes:

> How about releasing a polymorphic virus on a test machine with several
> thousand bait files that are identical. 2-5 thousand bait files should be
> enough.

> infect these bait files, then use a program that would generate CRC's of
> all of the infected files then delete the duplicates.
>
> If the MtE generates fewer dupes than the others, call it the most
> polymorphic

Not good enough... A virus that puts a single word (two bytes) of
random garbage in the decryptor will be flagged as more polymorphic
than MtE by your scheme...

Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:[phone], Fax: [phone]      Fachbereich Informatik - AGN
< PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [e-mail]    D-2000 Hamburg 54, Germany

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

Date:    14 Jan 93 11:25:41 +0000
From:    [e-mail] (Vesselin Bontchev)
Subject: Re: Math Models of Polymorphic Viruses

[e-mail] (The Jester) writes:

> The picture of this process is a tree graph where each node is a
> mutation of the root with a theoretically unlimited number of
> children (You can just increase K to some arbitrary size when you
> wish to increase the number of mutations) each of which is itself a
> node with children and so on and so forth. Further more the graph
> does NOT have to be directed. It is possible for a child to produce
> its parent given the appropriate key.

The graph obviously IS directed, with the different keys marking the
directed edges. You probably mean that the graph does not have to be a
TREE, i.e., there might be loops.

> The question is:Given functions VX() and VY(), can I determine if
> they are both members of the same tree? Further, if this problem

More exactly, the question is: given nodes VX and VY, it there a way
to determine whether a node VZ exists, from which there are paths to
both VX and VY?

> The application of this problem is obviously to polymorphic viruses.
> V() is the polymorphic virus function and K is whatever the virus is
> using to determine its next mutation. So if I have some known virus
> VX() and I scan the system, I can compare code against VX() and
> determine membership.

Also, it might be possible to apply the solution to the problem of
measuring polymorphism... For instance, polymorphism could be measured
as average length of the loops in the graph, or as average
"valentness" of the nodes, etc.

Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:[phone], Fax: [phone]      Fachbereich Informatik - AGN
< PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [e-mail]    D-2000 Hamburg 54, Germany

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

Date:    14 Jan 93 11:04:37 +0000
From:    [e-mail] (Vesselin Bontchev)
Subject: Re: Infection question (was: Viral Based Distribution System)

[e-mail] (Celustkova-k336-doktorand(Richta)) writes:

> Cite from your paper "Possible Virus Attacks Against Integrity
> Programs and How To Prevent Them", EICAR Conference,Munich,December
> 1992 (stresses are mine):

[citation deleted]

> Cite from Virus-L FAQ :

[citation deleted]

Well, having in mind that I have participated the writing of both my
paper and the Virus-L FAQ, I obviously know what's written in them...
:-)

> Companion viruses don't modify files but information about them and
> create new files which is executed instead of the intended, i.e. they
> modify the previous state of the system. In that way they could cause

Yes, I know that, of course... I was just pointing out that the
"common" understanding of the term "virus" (by the end user) as
"something that messes with my files" is not always correct, even for
the currently existing types of viruses on the IBM PC. These viruses
(boot sector infectors, file system infectors, companion viruses) do
not match even Dr. Cohen's natural-language definition of the term
"virus", unless you define "program" and "attach" too broadly. And
IF you define them broadly enough, a "worm" will fit in the definition
of the term "virus" too. They are essentially one and the same thing,
from the mathematical point of view... Nevertheless, for reasons of
convenience, we prefer to differentiate between them in practice.

Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:[phone], Fax: [phone]      Fachbereich Informatik - AGN
< PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [e-mail]    D-2000 Hamburg 54, Germany

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

Date:    14 Jan 93 10:54:40 +0000
From:    [e-mail] (Vesselin Bontchev)
Subject: Re: How to measure polymorphism

[e-mail] (Declan Malone) writes:

> Let me explain.  What polymorphism is, essentially, is a term
> describing randomness, true?  Now how do you measure randomness in an
> objective way?  You can't really, and the irony of it is that the more
> you try, and the more objective/detailed your description becomes, the
> more you are taking away from the central essence of the word `random'
> or sending your definition in the wrong direction. It seems to be the

Well, yes, but if you show two polymorphic mechanisms to a human virus
expert, he is usually able to tell which one is more polymorphic... I
was thinking about some objective way to provide such evaluations...

> You say that there is a real need for an objective way of measuring
> the level of polymorphism, but why is that so? If a user has a new
> virus running loose on his system, it is of little interest to him
> whether it is more or less random than another virus. Even to scanner
> manufacturers, I think, the point is largely irrellevant - so long as
> they can produce a scanner to detect the virus, its level of
> polymorphism is purely academic.

Of course, it is academic issue... Actually, such an evaluation
criteria would be more useful to the anti-virus researchers than to
the end user... But it wouldn't be completely useless even to the end
user. The ability to detect extremely polymorphic viruses reflects the
quality of the R&D department of the company that produces a scanner.
The users might want to know "how good" that company is in detecting
"difficult" viruses. For that purpose, there needs to be a way to
measure the "difficultness" (i.e., the polymorphism) of the virus
objectively. Why do you think users keep asking whether some scanner
detects MtE, instead of asking whether it detects Cascade...
Regardless that Cascade is rather common and none of the MtE-based
viruses has been found in the wild yet...

> Even so, taking it that there can be no a-priori measure of
> polymorphism, for specific purposes, measures can be defined that,
> while not measuring randomness, give something that is useful in the
> context.

Yes, it would be useful if we can achieve at least that...

> 1 Is every byte of every sample constant? (a simple CRC will identify it)
> 2 Is there a fixed (no wildcards) signature that will identify it?
> 3 Is there a simple wildcard signature (constant length) to identify it?
> 4 Is there a complex wildcard signature to identify it? ( signature matches
> variable length strings)
> 5 etc

Right, this is something like the "classes" scheme described in my
original message... However, the real problem is how to differentiate
the polymorphism of the viruses that are in category "5 etc"... :-)

> in terms of scanning. Still, it's really only of use at low levels of
> polymorphism - after that things would start to get really hairy . . .

Exactly...

> fascinating stuff. One metric that I think might be interesting would
> extract the total number of useful signatures from a program (or as a
> ratio of the total possible signatures for that file) - not only would
> you get some idea of polymorphism, but you'd also get some idea of how
> well a signature picked at random for the virus would withstand random
> modifications to the virus. This could give stats for how likely a
> signature would be of detecting various new variants with increasing
> modifications. Because it's signature-based, the effect of moving
> sections of code around from original to variant is much less over

Hmm, that sounds interesting... Could you write some program that
implements this idea? Would be nice to test it in practice...

Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:[phone], Fax: [phone]      Fachbereich Informatik - AGN
< PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [e-mail]    D-2000 Hamburg 54, Germany

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

Date:    Thu, 14 Jan 93 19:43:47 +0000
From:    [e-mail] (robert heuman)
Subject: Export restrictions on anti-virus software

Date Entered: 01-14-93 13:33
[e-mail] (McAfee Associates) posted part of the material re
Export controls and then asked a question as follows:


> Question: Does "In the public domain" mean a program that is not
> copyrighted, e.g., "free" as in the context of "public domain"
> software, or does it just mean a program is widely available to the
> public, and thus not subject to export controls--even if it is
> shareware, e.g, publicly-available but copyrighted?

I asked the bureaucrats this same question, and was told it meant what
it said, and that they would not define it any further - and would
interpret it on a case by case basis.... however, they also said that
something being widely available, or even imported electronically, did
not mean a thing.... If it had a price attached to it, and was not
marketed according to the strict interpretation they had for packaged
software, it came under the rules.  Therefore although I had
'imported' F-PROT electronically, I could not send it electronically
to our offshore locations.... That would be a violation of the act.  I
know it is silly... you know it is silly (and unenforcable)... but
that is the way THEY intrepret it, and THEY MUST be right, right?

Even sillier was that I then asked that if I did apply for the export
permit, could I export it electronically once the permit was obtained,
and was told - NO!  It had to go through Customs, with the permit
attached, and couldn't if in a communication! (Of course they are
correct - it can't, but who needs postal delays on time sensitive
material?)

I do not suggest that any of the rule makes sense - it doesn't in the
context of either F-PROT or SCAN/CLEAN, etc.  These posts are for
everyone's information.  However, I do ask if someone could check the
latest rules for the US and other COCOM countries, and see if they
have the equivalent. I suspect they do, and wonder how each
bureaucracy would interpret this same issue.

Bob
- ---
   RoseReader 1.70 P001886: This Canadian has an Opinion...His Own!
   RoseMail 2.00 : RoseNet<=>Usenet Gateway : Rose Media 416-733-2285

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

Date:    Thu, 14 Jan 93 17:54:31 -0500
From:    [e-mail] (Fred Cohen)
Subject: Re: on the definition of virus


   In a recent virus-l, someone wrote that they liked Alan Solomon's
redefinition of a `real virus' as `a program that replicates without the
user's awareness and cooperation' (p602 V11N7 Computers and Security).

   There are some minor problems with this definition that I would
like to point out.

1) If a user is aware of the `Brain' virus on a floppy disk, and inserts
it anyway and boots, it is a virus? According to Solomon's definition it
is NOT a virus because the person was:

   a) aware
   b) cooperative

   HOWEVER - If another user does exactly the same thing without
knowing that the disk contains a virus, then it IS a virus!

   My problem is that I now have to assess the state of mind of the
user to determine whether the thing we call `Brain' is a `real virus' or
not.  We know for certain that it is a `virus', but whether it is a
`real virus' changes as the user's awareness level changes.  Careful -
if you go to sleep - it's a `real virus' - but don't worry - when you
wake up it isn't.

   How about in a multiuser environment? The same sequence of bytes
is both a `real virus' and not a `real virus' because one user is aware
that it replicates and another is not. If `backup' a `real virus'?  It
was a few days ago, but now that you are all aware that it is a `virus',
it is no longer a `real virus' for you.

   What about fully automated systems, where there are no `users',
EVERY replicating program is a virus, because there is no user
awareness.

   How about designer awareness? Administrator awareness? I guess
that my maintenance viruses are `real viruses' because the users aren't
aware of them.  Even if I tell them about the viruses - they are still
`real viruses' because the users don't have to explicitly cooperate in
order for the maintenance to take place.  So I guess we can have benevolent
`real viruses' as well.

   What is all this leading to? The environmental factor that
determines what meets Solomon's definition of Solomon's `real virus' has
to do with the state of mind of the `user'.  That means that there is no
objective test to determine whether or not something is a virus because
two different observers could draw completely different conclusions and
both be right.

   Solomon then goes on to state that ``useful (antivirus software)
differentiates between (`real viruses') and non(`real viruses')''!!! But
this means that useful anti-virus software can differentiate between the
states of mind of different users! Fantastic!!!  It read's your mind,
and only warns you if you aren't already aware or you aren't cooperating!
Of course, in testing, it never tells you about a virus, because there
are no `real viruses' in a test - after all, you know about the test and
you are cooperating.

   HUMOR ON!!! (I wouldn't want to offend anyone's sensibility)

   Is that why Solomon's toolkit does so poorly in tests? (NOTE
Solomon's toolkit is really quite good at detecting known viruses - even
in tests).  We must conclude from this that Solomon's antivirus products
are not useful - by his own claims.  But I think he wants us to believe
that they are useful, so I am anxious to find out how they detect the
state-of-mind of the user.  ...  Sorry - they don't do that yet.

   HUMOR OFF!!

   Maybe Solomon's product is very good - but his definition isn't.

__________________________________________________________________________
8:30AM-2PM Eastern      Protection     2PM-8:30PM Eastern
US+412-422-4134          Experts       US+907-344-5164
   FAX US+412-422-4135 -OR- 907-344-3069 24 hours - 7 days
__________________________________________________________________________


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

Date:    Fri, 15 Jan 93 00:39:05 -0500
From:    Big Foot <[e-mail]>
Subject: Virus Calendar

    To all those experts out there,

       I'm  trying to  compile a  calendar,  specificing just those  virusses
    that hit on [a]  certain day[s], like Payday on every friday except 13th.
    I already have the list from VSUM.

    I think I have heard others on this list trying to do the same, but never
    heard  anything about a  completed (as far as that's  possible, with viri
    getting created in bunches .. :-( ) one.

    So, I would like al of you who gave up (?), or just have some information
    to e-mail me.  At the  moment, I'm  compiling month by month, and think I
    got next Februari covered ...

    Second, is there a way to scan the VIRUS-L backlogs.  Listserv@lehigh did
    not understand my mails (I got several ideas from HELPNET, but no way ..)
    I just wanted to find the ones containing "calendar" or something similar

[Moderator's note: Yes, there is a way to scan the backlogs.  All
postings to VIRUS-L/comp.virus, since day one, are archived on
cert.org in pub/virus-l/archives.  The old listserv@lehiibm1 no longer
has any VIRUS-L archives on it.]

    Third, a Dutch  magazine  mentioned the Hymn virus, which seems to hit on
    the day with the same number as the month, so Jan. 1th, Feb. 2nd, etc ...
    VSUM and F-prot did not know about it ?!?

    aTdHvAaNnKcSe,

- --
       Marc du Bois                                  .--------_____  _/
       Systems & Network operator EDP-CC             |__o       __ ==
       AT&T Network System Netherlands bv.            `---\\----


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

Date:    15 Jan 93 05:10:14 +0000
From:    [e-mail] (Vesselin Bontchev)
Subject: Re: A-V virus

[e-mail] (Fred Cohen) writes:

>  I think that an alternative to off-line checksums is access
> control. This has worked in IT for several years, and defeats all of the
> other attacks against the crypto-checksum I am aware of.

I disagree, for several reasons:

1) As you admit yourself, access control requires the proper hardware
that is able to provide memory protection, and proper software that
actually uses these possibilities that the hardware provides... In
practice it means - not an MS-DOS, or MacOS, or AmigaDOS, etc. system.
But the current viruses are a problem exactly in these systems - if
you switch to something else, they are not (at least not yet) a
problem. Not that they are impossible - they are just not a problem.
However, what to do with the -current- systems? They are going to be
with us at least for the next ten years...

2) Wasn't it you who has proven that discretionary access controls are
unable to stop the virus spread, unless they limit the sharing or the
transitivity of the information flow? They can at most slow down the
spreading of the virus, or limit to a cluster of users (if POSets are
implemented)...

3) Access controls do not prevent at least one of the virus attacks
against integrity checkers I can thin of. They are unable to stop the
slow viruses. In fact, the first slow virus was developed exactly as
an attack against monitoring programs and only afterwards it was
noticed that it is also very effective against integrity checkers...

Maybe something could be done by introducing strongly typed labeled
objects and strict distinction between code and data... I've heard
that such systems tend to be pretty clumsy and unusable...

> >Actually, that definition isn't useful.  If the "environment" includes
> >a user typing "copy", then any file is a virus.

>  I disagree strongly.  You are right that under my definition, if
> the environment is such that all programs are always copied, then all
> sequences of symbols are viruses.  I published this result in 1985 in
> some detail, and showed a Turing machine example where all sequences are
> viruses.  You are not right that just because one user copies one
> program one time, it makes the copied program a virus.  The reason is
> that the copied program won't necessarily copy itself when you run the
> copy.  That is the reason we have the `ad infinitum' at the end of the
> linguistic version of the definition.  To qualify as a virus, given a
> proper environment, the program must ALWAYS reproduce.

Well, consider the following example:

Program: XCOPY.EXE

Proper environment:
   a) MS-DOS computer, which is turned on, contains the file
XCOPY.EXE in the current directory on the current drive and has a
formatted empty diskette in drive A:
   b) user, typing XCOPY XCOPY.EXE A:

Under this "proper environment" the program XCOPY.EXE always
reproduces itself. So - is the program XCOPY.EXE a virus in this
environment?

Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:[phone], Fax: [phone]      Fachbereich Informatik - AGN
< PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [e-mail]    D-2000 Hamburg 54, Germany

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

Date:    14 Jan 93 12:00:49 +0000
From:    [e-mail] (Vesselin Bontchev)
Subject: Re: OS2SCAN99 checked (OS/2)

[e-mail] writes:

> OS2CLEAN: at least I found no problems, when I tried to clean my system from
> [JERU].

Are you -absolutely- certain about that? You see, Jerusalem makes some
silly assumptions about the format of the EXE files. As a consequence,
it destroys some EXE files it infects (e.g., WordPerfect). It is my
understanding, that it will destroy all Windows applications, and I
think that OS/2 applications have a similar structure. Therefore, no
disinfector would be able to recover such files, although some
intelligent disinfectors warn the user that these files are destroyed.

> Is there a reason, why you still
> don't scan *.DLL?

At least I do not know any virus that could infect them... And since
SCAN is able to detect only known viruses, it doesn't make sense to
scan objects that the known viruses do not infect...

> You added new extensions, of which I never thought, they
> would contain executable code (*.PIF). So I learned some new things. If

The .PIF files contain a pointer to an executable file. Therefore, it
is possible to apply a companion-type attack to them - change the
pointer to another executable that contains the virus body and let the
virus itself execute the original program. However, no such virus
exists yet, which means that there is no need for a scanner to scan
these files. They should be checked by the integrity checkers,
however.

Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:[phone], Fax: [phone]      Fachbereich Informatik - AGN
< PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [e-mail]    D-2000 Hamburg 54, Germany

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

Date:    14 Jan 93 17:24:35 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Re: DOS Viruses under HPFS (OS/2)

[e-mail] (Chris Antkow) writes:

> Being a virus researcher myself, I find it sometimes suicidal to test
>out and disassemble new stealth and polymorphic class viruses on my
>DOS based PC. I'm deathly paranoid that it's going to escape on one of
>my floppies and infect the rest of my house... Even though I know my
>ASM a bit better than the average Joe, who knows what might happen.

Well....what you need is a "clean room" - say, a setup like the one I
saw at Symantec - a room full of XTs, ATs etc, and several guys
working full-time in there analysing/testing viruses...and not allowed
to take them out of the room.

Realizing that this might not be practical in your case, I would
suggest a special, dedicated machine, just for running viruses.

If that is too expensive, consider adding a switch to the outside, to
make the disk read-only while you are looking at the viruses.

- -frisk

Fridrik Skulason      Frisk Software International     phone: [phone]
Author of F-PROT      E-mail: [e-mail]         fax:   [phone]

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

Date:    14 Jan 93 17:06:33 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Re: how to get rid of the Naughty Hacker-1? (PC)

[e-mail] (Cournoyer Louis-Georges) writes:

>Norton anti-virus as reported the presence in my computer's memory of
>the virus Naughty Hacker-1. The Nav program says to boot with a disk
>which has the same system, which in this case is ms-dos 3.3. That i
>have done...

>however, doing so, the nav program is not able to recognize the virus...

>What should i do?

Well, one suggestion might be "Get another A-V" program :-)

>Another funny thing is happening: if i take the ansi.sys out of my
>config.sys file, the nav isn't able to find the virus...

It looks to me as if this might be a false alarm, but I was not aware of
NAV causing this particular false alarm.  You could start by calling them,
and checking if this is a known problem with the version of NAV that you are
using.

- -frisk

Fridrik Skulason      Frisk Software International     phone: [phone]
Author of F-PROT      E-mail: [e-mail]         fax:   [phone]

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

Date:    14 Jan 93 11:41:05 +0000
From:    [e-mail] (Vesselin Bontchev)
Subject: Re: Monkey [Mon] and Multi-2 [M12] viruses (PC)

[e-mail] (Libbie Counselman) writes:

> The first one discovered was the Monkey [Mon] virus.  It affects the
> File Allocation Table.  SCAN discovers it, but does not disinfect, but
> Norton Disk Doctor will recover the clean FAT.

> The second is known as Multi-2 [M12].  It has a predecessor called
> Multi [M-123], also not recognized by F-Prot.  This one infects .COM
> files, .EXE files, overlays and becomes memory resident.  CLEAN
> apparently disinfects it.

Sigh... Yet another identification problem... SCAN 99 does not report
as [Mon] or [M12] anything from our virus collection, so obviously we
do not have these viruses. SCAN 99 reports as [M-123] the virus with
CARO name SD-123. This virus -is- detected by F-Prot 2.06a, so
obviously you mean a different one...

Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:[phone], Fax: [phone]      Fachbereich Informatik - AGN
< PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [e-mail]    D-2000 Hamburg 54, Germany

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

Date:    14 Jan 93 10:36:56 +0000
From:    [e-mail] (Vesselin Bontchev)
Subject: Re: How do MtE utilizing viruses detect themselves? (PC)

[e-mail] (Malte Eppert) writes:

> Can anybody tell me how MtE utilizing viruses detect themselves in an
> infected file?

It depends - the different MtE-based viruses use different methods.
The variants of Dedicated pad the infected files to the next multiple
of 256 when infecting it and do not infect files with size that is an
exact multiple of 256. Pogue puts an 'M' in the first byte of the
infected COM files and uses this as an infection marker. And so on.

Because those viruses to not have an exact MtE-detection mechanism,
this means that they might not infect some infectable files (they will
think that those files are already infected). This is sometimes called
"sparse infection".

> Or do they reinfect the file each time they attack it,
> like old Jerusalem?

No, they are not -that- stupid... :-)

> Can't an algorithmic scanner use the method used
> by MtE itself to detect it?

Unfortunately - not. The virus author does not care if his virus does
not infect some infectable files, while a producer of an anti-virus
program cannot permit himself to erroneously flag a perfectly valid
file as infected... The only thing that can be done is to use the
infection marker of the virus as an heuristic to sieve out the files
that are obviously not infected. For instance, if you need to detect
only Pogue, you can check if the file is a COM file and its first byte
contains the character 'M'. If it is not or it doesn't, then you know
that it is not infected by Pogue and don't need to spend more time
checking... Only if it looks like a Pogue-infected file, you'll have
to apply your algorithmic detection...

Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:[phone], Fax: [phone]      Fachbereich Informatik - AGN
< PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [e-mail]    D-2000 Hamburg 54, Germany

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

Date:    Thu, 14 Jan 93 18:17:09 +0000
From:    [e-mail] (McAfee Associates)
Subject: CLEAN removing Jerusalem (Was: Re: Jerusalem (Israeli) Virus (PC))

Hello Vesselin,

You write:

>Due to the infection method that this virus employs, it destroys EXE
>files with internal overlay structure (e.g., WordPerfect). Such files
>will crash when executed. They will still crash after disinfection,
>although McAfee's Clean does not warn you about that. If you have an
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>outbreak of this virus, the best solution is to delete all infected
>files and to replace them with clean copies.

CLEAN-UP does have a limited ability to check a Jerusalem virus
infected file and warn the user that the virus can not safely be
removed.  It will then ask the user if he (or she) wants to
overwrite-and-delete the file instead.

Regards,

Aryeh Goretsky
McAfee Associates Technical Support

- --
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
McAfee Associates, Inc.  | Voice [phone] | INTERNET:
3350 Scott Blvd, Bldg 14 | FAX   [phone] | [e-mail]
Santa Clara, California  | BBS   [phone] | CompuServe ID: 76702,1714
95054-3107  USA          | USR HST Courier DS   | or GO MCAFEE
Support for SENTRY/SCAN/NETSCAN/VSHIELD/CLEAN/WSCAN/NETSHIELD/TARGET/CONFIG MGR

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

Date:    Thu, 14 Jan 93 14:24:13 -0500
From:    "David M. Chess" <[e-mail]>
Subject: Re: Clash between FDISK/MBR and scanners (PC)

> From:    [e-mail] (A. Padgett Peterson)

> ps It is my understanding (David ?) that OS/2 uses selection through a
>    replacement of the DBR (OBR ?) *not* the MBR and requires a more complex
>    approach...

There are two multi-boot arrangements available with OS/2.  One
(called "Dual Boot") works about as you say: when you boot the
machine, it comes up under whatever OS you last had.  If you want the
other one, you use the BOOT command, which swaps OSBRs (not the MBR)
and reboots.  The other one is Boot Manager, which sits in the
bootable partition on the disk, gets control from the (normal) MBR,
puts up a menu asking what OS you want to boot, and when you answer it
loads and executes the corresponding OSBR.  Neither of them does
anything to the MBR when you change OS's, that I'm aware of.  Note
that I'm anything but an Official IBM Spokeshacker on this subject,
though.  I just have a messing-about knowledge of it.

- - -- -
David M. Chess                                          mI' jIHbe' jay'!
High Integrity Computing Lab                            loD tlhab jIH!
IBM Watson Research                                          -- qama''e'


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

Date:    Thu, 14 Jan 93 21:34:27 +0000
From:    [e-mail] (Joel A. Frahm)
Subject: Mr. BIOS (PC)

    I was recently called in to work on a new PC clone, and it had BIOS
from the Mr. BIOS corporation.  And if that wasn't weird enough, this BIOS
contains some type of antivirus code, perhaps an MBR protector or something.
Does anyone out there in the real world know anything more about this BIOS
and the ramifications of BIOS based AV software?

Thanks in advance,
     Joel A. Frahm, Joint Institute for Labratory Astrofizzics.

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

Date:    Thu, 14 Jan 93 21:39:18 +0000
From:    [e-mail] (Paul M. Minutillo)
Subject: Re: Problems with PCs (PC)

Thanks to those who responded to my original post. I contacted the
McAfee people concerning my problems and apparently I have a virus
that is not caught by Scan v. 99. Here are the symptoms: Every
executable or com (maybe others) that is run, increases in size the
first time it is run if the virus is in memory. Every so often I get a
sharing violation on drive C (my hard drive), sometimes I get overflow
or divide errors. I don't think anything is being deleted, but a
couple of executables won't run because they have been modified. For
the most part I can still run everything. I never get errors while
within programs, but after I exit a program and try to do something
else I will occasionally get a sharing violation error. If anybody has
any other virus program or knows of a way to get rid of this please
let me know.  If there was a way to compare an infected program and a
non-infected one to find what is different, would I be able to take
the difference, plug it into Scan and delete that part from my
executables? As before, please respond by e-mail.

- --

Send e-mail to: [e-mail]

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

Date:    15 Jan 93 05:50:16 +0000
From:    [e-mail] (Vesselin Bontchev)
Subject: Re: New way of opeing files??? (PC)

[e-mail] (Chris Antkow) writes:

>  Apparently, there is a new way of opening files which some AV
> Utilities don't catch. I've heard that the NuKE group is starting to
> use function AX,6C00h/INT 21h to open files...

First, the method is not new - it was introduced in DOS 4.0. Second,
it is not backwards compatible - if a virus uses it, it will not run
under DOS 3.30 and below. Third, there are already viruses using this
function (or intercepting it) - since quite a lot of time... :-)
Fourth, the knowledge of the members of the NuKE group about the
internals of DOS is not very impressive, if one takes a look at the
incredibly boring and silly viruses they continue to produce...

> Can anyone confirm the
> use of this function and are there any AV programs that trap this
> function?

I don't know, but why bother? First, even if a monitoring program
traps this function, it can be easily bypassed, using one of the many
tunneling techniques. Second, with this function it is possible only
to open or create (i.e., destroy) a file. If the virus wants to infect
it, it has to Write to it, and most monitoring programs I am aware of,
do trap the write operation...

Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:[phone], Fax: [phone]      Fachbereich Informatik - AGN
< PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [e-mail]    D-2000 Hamburg 54, Germany

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

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