Phoenix Rising BBS/phoenixrising.zip/phoenixrising/vir-docs/v05i118.txt

Internet Message Format | 1992-09-27 | 41KB

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 V5 #118
Reply-To:  [e-mail]
--------
VIRUS-L Digest   Monday, 22 Jun 1992    Volume 5 : Issue 118

Today's Topics:

Viruses, Anti-virals, & change (PC)
"Wonder-2" False Alarms in NAV 2.0 update 4 (PC)
Untouchable Network. (PC)
No Frills 2/3 Scanner needed! (PC)
scan 91 et al - reported as trojan?? (PC)
Request for Info on PC-Cillin (PC)
Re: Zipped Viruses (PC)
Re: VIRx version 2.3 released (PC)
Virus Warning (PC)
Is there a virus in Identity Scanner software? (PC)
Re: ISPNews & Virx (PC)
Re: Zipped Viruses (PC)
Help! Does anyone know about any known UNIX viruses (UNIX)
Re: MVS Virii (IBM MVS)
Scanning for encrypted viruses
Re: Taxonomy of viruses
Re: Theoretical questions
Re: Teoretical questions
New files on eugene (PC)
Eugene has a new name!! (PC,Mac,etc.)

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]
(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.  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:    Fri, 12 Jun 92 09:56:15 -0400
From:    [e-mail] (A. Padgett Peterson)
Subject: Viruses, Anti-virals, & change (PC)

>From:    [e-mail] (Vesselin Bontchev)
>Subject: Detecting the MtE (PC)

>3) I(n) my message on Virus-L/comp.virus I clearly stated that ALL the
>three scanners tested FAILED the test.
>...Both me and Dr. Fred Cohen
>clearly explained in our messages why anything less than 100 %
>detection of a particular virus cannot be acceptable.

It is evident that two things are happening, one: commercial vendors are
starting to dominate the industry and two) Single point answers are clearly
no longer sufficient.

The first is something that I have seen several times before, in fact any time
a "new" industry appears. At first, the only people interested are the
talented amateurs who freely exchange information in much the same way
as information on atomic theory was exchanged in the '20s & '30s.

Generally the next interest is by educational and governmental institutions
which begin to formalize study and which have the assets required for study.
Concurrently the first restrictions on information flow appears. Meanwhile
small commercial organizations spring up to take advantage of a new market.

Thirdly, the niche commercial interests begin to dominate and public discussion
centers on the virtues/limitations of various products rather than underlying
theory. Entry into the market at begins to becone more difficult.

Finally, once workable standards and mechanisms appear that do not need
constand tweaking, the broad-base commercial interests fold the new technology
into their products while most of the original companies either are absorbed,
become broad-based, resign themselves to ever smaller nitches, or disappear
entirely.

At present, it would appear that the anti-virus industry is reaching the
middle of the third stage with elements of the fourth stage beginning to
manifest.

With the introduction of the mTe toolkit, the limitations of pure scanning
are beginning to manifest. With one jump we have gone from over 1,000 viruses
(I know) to over 10,000. "100%" detection is now expected. The only way (on
soapbox) to achieve this is through integrity management. 100% is achievable
through change detection with some of the most effective products (PC-DACS,
Enigma-Logic) remaining effective year after year with little or no change.

Meanwhile, the scanners are recognizing this. Frisk's heuristic analysis and
McAfee's /AF and /CERTIFY switches are good examples. More and more good
systems first determine that *something* has happened before trying to
determine *what*.

Since most programs resident on a machine do not change or change only at
specific quantum points, exception conditions are necessary but not necessarily
onerous. (Enigma-Logic's PC-VirusSafe is a good exemple that I have been
using for some time (plug). If I change a program, on the next invocation a
screen appears letting me know that it has changed and asking for instructions
- - update audit-trail/checklist, allow to run once, abort. If I perform a major
change such as installing a new version of a package, I can tell it to update
an entire directory, subdirectories, or drive. It is also one of the few
products that can go resident from CONFIG.SYS).

The power of such a product is that when an attack occurs, it can notify the
user. A scanner is then brought out to find out *what* has happened. Once
the problem is identified and removed from memory, the integrity management
program may then be used to determine which programs have been altered.
Since the affectede programs are now known, they may be disinfected or deleted.

Further, an execution audit trail may be examined to determine which program
caused the problem. Unless a specifically directed attack is made, (and there
are ways to guard against this as well) the above method works. 100%.

Of course there is a cost. At the moment this is in the range of 7-11k of RAM.
On an XT a minor performance hit is noticable. With a 286/386/486/etc machine
it is effectively nil unless an exception occurs.

As far as anti-virus products are concerned, they are out there. At present, I
do not know of any case of "one size fits all", it takes layers. At home I use
four different ones (five if you count frequent BACKUPs) but this is probably
overkill.

Getting back to the original subject, scanners have been called "flawed" for
a 95+% detection rate. To me this is acceptable because there is another means
for achieving 100% every time. Once you know that "something" has happened,
all else falls out. The hard part is being able to say "This is enough".

                    Warmly,

                        Padgett

            Who is John Galt ?

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

Date:    Fri, 12 Jun 92 16:36:18 +0000
From:    [e-mail] (Matthew J. D'Errico)
Subject: "Wonder-2" False Alarms in NAV 2.0 update 4 (PC)

Hi, all...

Updated and "Final" Info !

I thought I'd pass along the essence of a thread from compuserve
in which some false alarms have been caused by Norton Anti-Virus'
update (04) for version 2.0 which was released on June 1st...

Several instances have been reported where this update reported infections
of the "Wonder-2" strain of the "Wonder" virus in commercially distributed
software...  These infections include files from :

    Borland C++ 3.0 (TOUCH.COM)
    Mavis Beacon Teaches Typing 2.0
    Stacker 2.0
    VCD.COM (from VCD.ZIP - shareware ?)
    Intermission 3.0 (IMSETUP.COM)
    SHEZ v7.1 (3 different files : SHEZCFG.COM, SGREG.COM and DUMPMAC.COM)

    among others...

IN most of these cases, the infection was reported to the authors or
companies involved who have in turn verified the files as correct, and thus
not infected...  SYMANTEC subsequently backed out the Wonder-2 definition
from it's release calling it "over-agressive" and promising a corrected
detection in its 06 update due out soon...

The back-out is available in an update 05 which is the same as update 04
but without the Wonder & Wonder-2 definitions...

- -- Matt
+-------------------------------+---------------------------------------+
|    Matthew J. D'Errico    | DOMAIN:    [e-mail]    |
| Magna Software Corporation    | uucp:        uunet!magna!mderrico    |
|     275 Seventh Avenue    | CompuServe:    70744,3405        |
|     20th Floor        +---------------------------------------+
|    New York, NY   10001    |    Voice    : 212 / 727 - 6737    |
|        USA            |    Fax    : 212 / 691 - 1968    |
+-------------------------------+---------------------------------------+

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

Date:    Sun, 14 Jun 92 19:59:54 +0000
From:    [e-mail] (Keith Basil)
Subject: Untouchable Network. (PC)

I read an ad placed by Fifth Generation for thier "Untoucable Network"
security package.  I'd like some additional information on this
product from a user's standpoint. (installation, etc..)

Thanks.
Keith

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

Date:    15 Jun 92 11:18:35 +0000
From:    [e-mail] (Prince Of Darkness)
Subject: No Frills 2/3 Scanner needed! (PC)

I have a suspicion that i have the No Frills virus on my pc, i've been
looking for a scanner to find out for sure, but have been unable to
find one, can anybody help.....It's no frills vers 2 or 3, and i've
heard it can do screwy things to your FAT, i've had nothing really bad
happen yet, but a friends computer has, and so have others he's had
contact with, so i think he may have given it to me, are there any
non-comercial scanners out there that can detect No frill sna d kill
it?  If not what's the best (qand cheapest) commercial scanner that
will get rid of it?

Thanks

- -Chris

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

Date:    Tue, 16 Jun 92 00:56:54 +0000
From:    [e-mail] (P Tyers)
Subject: scan 91 et al - reported as trojan?? (PC)

A recent PC Update (published by the Melbourne PC User Group in Melbourne,
Australia) made comment that versions 90 and 91 of scan have been found as
trojans. Since I have distributed scan91 to a number of machines on this
site I would appreciate comment. The versions I distributed were sourced
from the mirror site archie.au and the validate results matched the message
on comp.virus (Message-ID: <[e-mail]>
        Date: 28 May 92 23:21:22 GMT) from mcafee Associates.
All executables passed a scan by scan89b as well.

Do I have a potential problem?
Has scan91 and/or the associated clean/vshield etc been identified as
trojans anywhere?
If so from what sites?

thanx in advance
P Tyers, Tel. [phone]   JANET: [e-mail]
ACSnet:    [e-mail]   UUCP:{uunet,hplabs,ukc}!munnari!trl.oz.au!p.tyers
CSnet: [e-mail]   ARPAnet: [e-mail] HAM: VK3KTS
MAIL: Telecom Research Laboratories,P.O. Box 249,Clayton,VICTORIA 3168,AUSTRALIA

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

Date:    Tue, 16 Jun 92 08:28:08 +0700
From:    Vincent Tracey <[e-mail]>
Subject: Request for Info on PC-Cillin (PC)

Hello Netters,

     Has anyone any information concerning a virus protection system
called ** PC-cillin **. The only information I have is a claim that it
can - stop - all known virus'- ?:^(  The package includes an RS 232 device
for *trapping* virus'. Any assistance in this matter is appreciated.
     Replies can be sent to the e-mail addresses shown below or via
the Digest (if Ken doesn't mind -?;^).

Thanx,

Vincent Tracey                E-mail:  [e-mail]
Security Investigator                  [e-mail]
411th BSB Security Office      Phone:  [phone]/6456
APO AE 09102                           DDN 370-8054/6456

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

Date:    Tue, 16 Jun 92 09:30:21 +0200
From:    Magnus Olsson <[e-mail]>
Subject: Re: Zipped Viruses (PC)

[e-mail] writes:
>In VIRUS-L v005i111 Magnus Olsson <[e-mail]> writes:
>>[e-mail] writes:
>>
>>[excellent description of stealth viruses deleted]
>>
>>Thanks for a very informative article! There's one point I think
>>you're missing, though, when describing the dangers of using scanners
>>on an infected system:
>>
>>>Here's what happens: Your virus scanner is infected with a stealth,
>>>fast infecting virus.  It isn't currently active.  You run the scanner,
>>>telling it to scan your entire hard drive.  First the virus gets control:
>>>It goes resident, takes over, then runs the scanner.  Now the scanner
>>>attempts to perform a self-check on its file.  This detects nothing,
>>>because the virus disinfects the file as it reads it.  Now your scanner
>>>goes through your entire hard drive, reading all programs.  Not only
>>>does it have no chance of catching the virus in any program, but every
>>>program (even ones which weren't infected before) will get infected!!!
>>
>>At least McAfee's scanner doesn't only check files on the disk and
>>make a self-check, but also scans memory for viruses before doing
>>anything else. Doesn't this cure the above problem, as the
>>memory-resident stealth virus would be detected in memory?
>
>Not if the afore mentioned virus is a new one which the scanner does not
>yet detect.  In that case, you're in big trouble.

Thanks for your comments (and thanks to the other people who've written
similar replies).

I'm well aware that a scanner can't protect against an unknown virus.

What I'd like to point out, however, is the following (I'm sorry if it
wasn't clear from my post):

The original post stated a number of reasons why stealth viruses are
especially dangerous, ending with the point quoted above about
scanners. Now, with a scanner that first scans memory, there are two
cases:

a) The scanner recognizes the virus. In this case, it will be caught
already in RAM, *before* the scanner starts reading files (where
the virus won't be recognized). Therefore, no files are infected by
the scanner.

b) The scanner doesn't recognize the virus. In this case, all the
files scanned will of course be infected. But this is not specific for
stealth viruses; *any* unrecognized virus of the file-infecting
variety does this.

In short, my point is that *if* the scanner checks RAM before it
starts checking files, stealth viruses are *not* any worse than
"ordinary" viruses _in the context of what happens when you're running
the scanner_ (though they are from other aspects).

The reason I'm writing this is *not* that I think the advice presented
here (when suspecting a virus infection, always boot from a clean disk
before scanning) is wrong - on the contrary!

But I feel that in the field of computer virology, everybody should
have as precise information as possible, even on minor issues like
this one. IMHO, exaggerating the dangers of, say, stealth viruses is
potentially dangerous, as it may lead to exaggerated actions by people
who believe they're infected - such as people throwing away SCANV
because hey've heard somewhere that "scanners are dangerous".

- --
Magnus Olsson                   | \e+      /_
Dept. of Theoretical Physics    |  \  Z   / q
University of Lund, Sweden      |   >----<
Internet: [e-mail]     |  /      \===== g
Bitnet: THEPMO@SELDC52          | /e-      \q

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

Date:    16 Jun 92 08:29:44 +0000
From:    [e-mail] (Vesselin Bontchev)
Subject: Re: VIRx version 2.3 released (PC)

[e-mail] (Anthony Naggs) writes:

> Vesselin you are over looking the fact that there are already 2
> versions of MtE in circulation, one ('0.92' I think) is found on
> "Dedicated" & "Fear" and the other ('0.90') is on "Pogue".  I have
> only looked at the one on "Pogue" so far, and around 20% of the files
> I infected were corrupt.

No, all the three viruses - Dedicated, Fear, and Pogue use one and the
same version of MtE - 0.90-beta. Look at the code and you'll see that
I am right. If Pogue destroys some files, the reason is that the virus
is buggy, not the MtE. MtE has another bug - that in about 10% of the
cases it produces non-encrypted mutations.

> If the MtE detection tests that you are performing are going to be of
> relevance you will need to test for the variations produced by "Pogue"
> as well.

I am testing the scanners for detection of MtE-based viruses.
Therefore, it doesn't matter what virus I am using for the tests
(except in the case of the non-encrypted mutations). If Pogue is buggy
and damages some of the infected files, then this is yet another
reason not to use it for the tests - I'll have to determine which
files are damaged and to remove them. This will be quite
time-consuming.

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

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

Date:    16 Jun 92 09:38:31 -0400
From:    Charles Rutstein <[e-mail]>
Subject: Virus Warning (PC)

    Just a heads-up, folks.  Here at the ICSA Virus Research
Center in DC, we've received several calls for help in the last few
days concerning the fish boot infector.  Calls have come from all
parts of the continental United States.
    This morning, one of the infected users called back to tell us
that he had traced the infection to the original disk from a hand
scanner he'd recently purchased.  The disk was infected and still
factory write-protected.  He then claims to have gone to the store
where he purchased the product and convinced them to open another
package.  Guess what?  You got it...fish (boot).
    The disks allegedly infected are from a company called
IDENTITY.  No product name was given.  Note that we do not yet have a
copy here...there are several on their way to us.
    There should be no need for general panic (please!), as nearly
all recent scanners will detect the virus.  We'll provide more info as
it becomes available and after we've had a chance to contact the
company.  While we can't confirm the infection just yet, it *looks*
initially like a solid bet.
    Phone number here is 202-364-8252 for questions, etc.

                    Charles Rutstein
                    ICSA Virus Research Center

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

Date:    Tue, 16 Jun 92 15:46:36 +0000
From:    [e-mail] ([*BARK*])
Subject: Is there a virus in Identity Scanner software? (PC)

I am buying a Identity Scanner over the net and recently, someone
told me that the software that comes with the scanner contains virus.
Could someone tell me if this is true? Another thing is could
someone tell me  the best way to cure the software if the disk
is really infected.  Please include info on the best method
to scan and clean the disk.  Thank you all.  Prompt reply please.

- --
*******************************************************************************
*  Alex J Chuah                     *        *BARK* *BARK* *BARK*             *
*  [e-mail]                  *        In Love with OS/2???             *
*  [e-mail]        *                                         *
*******************************************************************************

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

Date:    16 Jun 92 13:41:05 -0400
From:    "Ross M. Greenberg" <[e-mail]>
Subject: Re: ISPNews & Virx (PC)

>Date:    12 Jun 92 10:38:19 +0000
>From:    [e-mail] (Vesselin Bontchev)

>...Wait a minute. What do you mean by "some of the above mentioned
> 10,000 viruses"? Do you have them?

Sorry: I was referring to the 10K viruses I've generated here, mostly
from Dedicated/Fear and Pogue.  Had a problem in generating that many
due to a small disk, but there's always .ZIPing subsets....

>...Or are you speaking about a different (not ours) test set?
> Because I had a look at some of the non-detected files and they seem
> to be perfectly in order...

The problem with the non-detected ones was due to an optimization we
did on the algorithm immediately before release without adequately
testing the change(s)....it looked like such a simple change,
too....Sigh. Fixed, of course, and due out as soon as it goes through
a more extensive beta.

Ross

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

Date:    17 Jun 92 08:51:42 +0000
From:    [e-mail] (Vesselin Bontchev)
Subject: Re: Zipped Viruses (PC)

[e-mail] (007) writes:

> Would it be feasible to write a virus defense package that would ONLY
> run after booting from a clean, write-protected floppy?  The

Feasible - yes. Practical - probably no. Suppose that you have a
computer with only one floppy disk drive and want to scan a huge
number of possibly infected diskettes. This means that the product
must load entirely in memory (all the fancy menus, virus signatures,
etc.), or constantly ask you to swap diskettes. The former is
achievable, but requires a lot of memory, and the latter is so
inconvenient that nobody will use such a product.

> programming aspect is fairly straightforward,

It is not that straightforward. How do you detect that the user has
booted from a floppy? I mean - reliably? You can check COMSPEC, but it
means nothing since the user could change it. Under DOS 4.0 and above
you can ask about the drive the system has been booted from, but what
about the other DOS versions? You can check whether the product is run
from a floppy, but this does not mean that the user has booted from
there.

I don't say that it is impossible - just not so easy as you probably
think...

> but would people accept a product like this?

Probably not. A simple and stupid integrity checker is able to detect
all of the currently existing viruses, if you always boot from a
floppy before using it. (If you want to make it resistant to some
advanced attacks, you need to make it more intelligent.) Yet people
either prefer to use scanners (none of which is able to detect -all-
of the currently existing viruses), or if they use an integrity
checker, they almost never boot from a floppy...

> Ideally it would include a known clean copy of
> DOS with it, but this could cause problems with copyright laws, etc.

Indeed. It is possible to use only the two DOS hidden files (i.e., no
command interpreter), but the license fee will be still to high... A
better way is to make the program run when you boot the diskette and
use no DOS or file system at all - like some games do, but this
requires some programming efforts, makes updating the scanner not so
easy, and the whole program inconvenient to the user.

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

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

Date:    Tue, 16 Jun 92 12:42:47 -0500
From:    [e-mail] (Speaker to Bittyboxen)
Subject: Help! Does anyone know about any known UNIX viruses? (UNIX)

John Guh writes:
|> A customer of mine is worried about computer virus on tapes which
|> contained Timeplex`s application software to be loaded on a SUN
|> SPARCstation.
|>
|> Has anyone ever heard of computer virus on UNIX systems?  Are there
|> any virus detection program for UNIX?

Short answer: in the wild, no. Unix has so far been protected by the
variety of OS variants, I/O media, and machine architectures.  Unix
viruses are far from impossible, and have been created for research
purposes; but they are not a significant factor in the Real World(tm)
yet. Lest you be too sanguine, though, I'd predict that the first real
Unix virus will infect Sun systems just because there are so many out
there (recall that the famous Internet Worm of 1988 affected only
VAXen and Sun3's, but still reached about 6000 hosts). Quoting with
permission (mine :-) from an internal Intergraph paper on this
question:

The potential threat, even in the current mixed-up mess of different
Unix flavors, instruction set architectures, and directory layouts,
is greater than what has actually been observed. Theoretical results
\footnote{Fred Cohen: Computer Viruses: Theory and Experiments,
in {\it Computers and Security} 6 (1987) pp. 22-35, Elsevier
(North-Holland)} indicate that viruses can spread anywhere that
programs are shared, and that the general problem of detection is
not tractable. These results hold even in compartmented systems.
Duff \footnote{Tom Duff: Experience with Viruses on
Unix Systems, in {\it Computing Systems}, Vol. 2 No. 2 (Spring 1989)}
gives the text of a virus that can infect all the
writeable shell scripts on a System V machine. Such a virus is trivial
to detect and disinfect, but since every system has a {\sf /bin/sh} and
anywhere from hundreds to thousands of scripts, the possibility of
a virulent shell script virus getting out of hand cannot be blithely
discounted.

It follows from Cohen's model that any enhancement in the ability to
share programs between PCs is an enhancement in the virulence of any
infection that does arise. A very good culture medium, therefore, is
a LAN with many PCs and one or a few file servers. In this environment,
a non-PC file server could be carrying programmed threats to which
it is itself immune, and passing them on to PCs which execute programs
from the file server (the Typhoid Mary syndrome).
- -- end quote --

Therefore a good crypto-checksum program would be a nice addition
to any network. It is possible to roll your own such facility on
any Unix system that has a decent crypt command (see Garfinkel
and Spafford for a simple recipe).

- --  *************************-><-*************************
    ** Craig "Interferon" Presson [e-mail]  **
    *************************-><-*************************

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

Date:    16 Jun 92 08:16:30 +0000
From:    [e-mail] (Vesselin Bontchev)
Subject: Re: MVS Virii (IBM MVS)

[e-mail] (Robert Slade) writes:

> While not, in the very strictest sense, a virus, the CHRISTMA EXEC of
> 1987 nevertheless was a self-reproducing object which operated with
> IBM mainframe systems and over mainframe network links.

More exactly, the CHRISTMA EXEC was a chain letter, not a virus or a
worm. It depended on the user action to spread.

Anyway, for more information about virus-related problems on MVS, I
suggest the paper

King M., "Viruses and Related Mechanisms in MVS", Software World, Vol.
20, No. 1, pp. 2-4.

> While no data was at risk, CHRISTMA resulted in denial of service and
> extra time expended in its removal.

I think that a destructive variant has been detected in the USA.

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

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

Date:    Fri, 12 Jun 92 13:34:25 +0000
From:    [e-mail] (Raphael Finkel)
Subject: Scanning for encrypted viruses

If a virus encrypts itself by a variable key that is a single byte, and
uses that byte to xor its code, then the xor of adjacent bytes of its
code is unaffected.

So a 'first-derivative' scan string could contain not the bytes of the
virus, but the xor of adjacent bytes of the virus.  This scan string
would still be very virus-specific, but would be encryption-invariant.
If the key is longer than a byte, the same idea works, with appropriate
adjustments.

It will not work if the virus is variable in other ways, or if it uses
a different encryption method, or if it chooses among several
encryption methods.

I have not seen this idea suggested here, but perhaps it has been.

Is it viable?

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

Date:    16 Jun 92 08:25:21 +0000
From:    [e-mail] (Vesselin Bontchev)
Subject: Re: Taxonomy of viruses

[e-mail] (Mary K. Kuhner) writes:

> Taxonomy was originally based on the biologists' intuitive ideas about
> organism relationships too, but algorithms for describing and
> systematizing these intuitions still proved useful.

> I agree, however, that it will be very hard to do anything mechanical
> about classifying viruses.  It was hard for biologists, and a
> biological organism is easier to get a grip on than a computer virus.

More important, the classification of the live organisms is based on
our knowledge about the natural laws (e.g., evolution, natural
selection, etc.). The computer viruses do not evolve naturally - they
are created and modified by humans. That's why, the same classification
approach cannot be applied to them.

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

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

Date:    16 Jun 92 14:16:25 -0400
From:    "David.M.Chess" <[e-mail]>
Subject: Re: Theoretical questions

> From:    Homo homini lupus! <[e-mail]>

>  What is a POset?

A partially ordered set.  Which means (as I recall) for at least some
elements x and y in the set, x>=y, and the >= relation obeys the usual
rules.  The "partial" means that perhaps for some x and y, neither
x>=y nor y>=x.  Something like that...  *8)

> ... if for all i in N, v(i)>=i then v is absolutely isolable.

This means that if a virus v makes programs larger, it's possible to
tell whether a given program P is the result of v infecting some other
program.  This works for any notion of "larger" for which it's true
that there are a finite number of programs not larger than any given
one (so it works for bytes, but probably not for runtime.)

Adelman says that the proof is trivial, and it is in a sense.  If you
have a program P of length L, and you want to see if it is the result
of infecting some other program with v, "all" you have to do is apply
v to every program of length less than L, and see if the result is
ever P.  This is of course utterly and completely impractical for any
real example ("Is this 25,000 byte file infected with the 1701 virus?
Well, let's try infecting every possible file of 24,999 bytes or less
with the 1701, and see if any of the results match!").

Now in practice, of course, all the viruses that we know of are
absolutely isolable, in that it's easy to write a program to answer
"is this given file infected with this given virus?".  I admit that I
*don't* understand Adelman's proof that some viruses aren't absolutely
isolable.  Is there anyone out there who does understand it?  I don't
understand what his example of a non-abs-isol virus would be like.
(Of course, if the answer would help a virus-writer do something
nasty, I'd appreciate an answer offline instead of here!).

>that checksum( pi ) = checksum( pj ) for some
>programs pi and pj of a length greater than the checksum

>isn't this a fundamental weakness in the checksumming concept.

Whenever a checksum is shorter than the objects being checked, the
pigeonhole principle ensures us that there will be at least two
objects with the same checksum.  In practice that's OK, though, as
long as the checksum is calculated in such a way that it's vanishingly
unlikely (even given an intelligent attacker) that an infected object
will have the same checksum as the original.  That's not hard to do;
Radai has a good paper or two on the subject.

- - -- -
David M. Chess                         |             "I been ionized,
High Integrity Computing Lab           |              but I'm OK now."
IBM Watson Research                    |             - Buckaroo Bonzai

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

Date:    17 Jun 92 07:58:39 +0000
From:    [e-mail] (Vesselin Bontchev)
Subject: Re: Teoretical questions

[e-mail] (Homo homini lupus!) writes:

> 1) Having read some of F. Cohens work, I've seen many references to
> a POset. What is a POset?

I guess Dr. Cohen can answer this better, but nevertheless here it
goes.

"POset" means "partially ordered set". It is first defined in

Cohen F., Protection and Administration of Information Networks under
Partial Orderings, Computers & Security, 6 (1987), pp. 118-128.

A good explanation of the POsets can be found also in

Cohen F., A Short Course on Computer Viruses, ASP Press, 1990, ISBN
1-878109-01-4.

and in

Cohen F., A DOS-Based POset Implementation, Computers & Security, 10
(1991), pp. 541-551.

The basic idea is to limit sharing of information in a computer system
(between users/nodes/accounts/etc.). As Cohen has proven in his Ph.D.
thesis, the only way you can stop computer viruses is to limit either
sharing, or transitivity, or functionality. The POset idea consists of
"ordering" the different domains in a computer system in such a way
that only some subsets of them can share information and the
information flow follows a limited number of predictable paths. This
way a virus can spread only to a limited part of your computer system
(because the different POsets are isolated) and you can determine
where it came from (because you know the paths of the information
flow).

> 2) L. Adleman present a theorem (Theorem 3, p.366; Leonard Adleman: "An
> abstract theory of computer viruses", Lecture notes in Computer
> Science, vol.403, Springer 1990, pp. 354-374) stating:
>     ... if for all i in N, v(i)>=i then v is absolutely isolable.
> Can those of you, who have read Adlemans note explain to me, what is
> meant by ">=". Does it mean that one can detect every virus which does

I have read Adleman's paper. Several times. Carefully. Shame on me, I
still fail to understand it... :-( I probably lack the appropriate
mathematical background - all those Goedel numberings, partially
recursive functions, etc.

BTW, Theorem 3 does not speak about detection, it speaks about
isolation.

> not shrink the infected program? And in what dimension is it to be
> measured? Cohens compressionvirus example make a program smaller in
> space, but as Cohen notes himself, it is a trade off between time and
> space, meaning that it will be larger on the runtime dimension. Can one

Not necessarily. On a computer with a slow disk and a fast CPU, a
compressed file will load faster than a non-compressed one - due to
the reduced amount of (slow) disk access.

> 3) Cohen notes a weakness in his defense model S3 (p. 155; Fred Cohen:
> "Models of Practical Defences Against Computer Viruses", Computers &
> Security, vol.8, no.2, s.149-160, 1989 ) - S3 is based on a checksum
> approch, which means that checksum( pi ) = checksum( pj ) for some
> programs pi and pj of a length greater than the checksum [my inter-
> pretation]. Relating that to the fact that most intregity checkers
> today is checksum based, and to the discussion considering MtE and
> 100% detection, isn't this a fundamental weakness in the checksumming
> concept.

Theoretically - yes. Since any checksum maps a (large) file into a
limited (and small) number of bits, this means that it is possible to
have two different files with the same checksums. The probability that
this can occur is quite low - if you use a 32-byte checksum, then only
two of 2^32 (=4,294,967,295) files are likely to have the same
checksum. Most computer systems have much fewer files... :-)

However, we are speaking about malicious modification, not about
random noise, so using a probabilistic model is not very appropriate.
If the checksum used is simple (add-bytes-together, or CRC) and can be
easily reversed, a virus which knows it could reverse it and after
infecting the file add a few more bytes in order to make the checksum
of the new file be the same as of the old one. By "reversing the
checksum" I mean "compute the contents of these few bytes". With CRC
it is quite easy.

There are two solutions to this problem. The first is to use a
cryptographically strong algorithm to compute checksums - something
like DES, MD4, MD5, Snerfu, etc. (DES is generally an encryption
algorithm, but you can use it to compute checksums - just encrypt the
file in CBC mode and use the last few bytes as a checksum.) MD4 and
MD5 generate a 128-byte checksum. It is algorithmically difficult
(meaning unfeasable in practical time) to reverse those algorithms. At
least nobody knows how to reverse them. (If you discover how to
reverse them, don't tell me. Tell CIA. How to contact CIA? Just pick
up the phone and talk. <smile>)

Unfortunately, the cryptographically strong algorithms tend to be too
slow to be used in practice. (I have heard the Fred Cohen has some
ideas of a relatively fast cryptographically strong algorithm, but
have no more information. Maybe he can comment?)

The second solution is to use a weak algorithm to compute the
checksums (e.g., CRC), but to implement it in a different way on the
different machines, so that the exact implementation is not stable and
the virus has no way to find out how exactly the checksum is computed.
In the case of CRC this means to use a different polynomial with each
new installation of the checksumming software. As has been shown by
Yisrael Radai, this is secure enough for practical applications.

One last remark - the MtE and all its mutations have nothing to do
with checksumming. Any good integrity checker is able to find any
MtE-based virus without any problems. The MtE is an attack against the
scanners, not against the integrity checkers.

> 4) When using MtE to exploid the "not 100% detection weakness" of
> scan- ners, it would seem worthwhile to give one own mutation a higher
> proba- bility. This means, that if five programs survive the scanning
> in the first round, and each make say three times more copies of it
> self than of other permutation, it will mean approx. 20 will survive
> round two.  This is exponential growth rather than as before linear
> growth (of course this will not increase the chance of survival in a
> checksumbased check).

Exactly. That's why anything but 100 % detection of a polymorphic
virus means no detection at all.

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

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

Date:    Tue, 16 Jun 92 08:09:05 -0500
From:    [e-mail] (John Perry)
Subject: New files on eugene (PC)

Hello Everyone!

    FP-204.ZIP has been posted for anonymous ftp on
eugene.gal.utexas.edu (129.109.9.21). If you have any probems or
questions, please send email to [e-mail].

- --

John Perry - [e-mail]


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

Date:    Mon, 22 Jun 92 13:54:10 -0500
From:    [e-mail] (John Perry)
Subject: Eugene has a new name!! (PC,Mac,etc.)

Hello Everyone!

    For those of you that have been using eugene.gal.utexas.edu
for anti-virus support, there has been a slight change in procedure.
Eugene has a new domain name. In the future, please use the address
eugene.utmb.edu for anonymous FTP access rather than
eugene.gal.utexas.edu. The old name will be supported for a period of
one year but will cause extra network overhead due to additional
lookups. If you have any problems or questions, contact
[e-mail]. Thanks!

- --

John Perry - [e-mail]


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

End of VIRUS-L Digest [Volume 5 Issue 118]
******************************************
rst5-YKCsng t5-YKCsng t5-YKCsng t5-YKCsng t5-YKCsng t5-YKCsng t5-YKCsng t5-YKCsng t5-YKCsng t5-YKCsng t5-YKCsng t5-YKCsng t
Downloaded From P-80 International Information Systems 304-744-2253