Hacker 2/HACKER2.mdf/virus/virusl3/virusl3.30

Text File | 1995-01-03 | 28KB | 637 lines

VIRUS-L Digest   Friday,  2 Feb 1990    Volume 3 : Issue 30

Today's Topics:

Re: Signature Programs
Re: And another WDEF infection (Mac)
Re: Universal virus detector
Re: Internet Worm
Statistical Distribution of Viruses
Re: Universal virus detectors
4096 virus detection (PC)
Jerusalem Disinfectors (PC)
Trojan Alert (MAC)
Help with removing virus requested (PC)
The Ultimate Anti-Viral Solution?
Timestamp virus protection
FSP+ Checksumming

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

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

Date:    31 Jan 90 20:14:06 +0000
From:    well![e-mail] (RSA Data Security)
Subject: Re: Signature Programs


          The following  paper is  presented for review and discussion.  It
          will be submitted to a number of conferences and MD4 will
            be proposed to a number of standards organizations. We encourage
            people to study and evaluate MD4.
          _________________________________________________________________

                          The MD4 Message Digest Algorithm
                          --------------------------------

                                 by Ronald L. Rivest
             MIT Laboratory for Computer Science, Cambridge, Mass. 02139
                                         and
               RSA Data Security, Inc., Redwood City, California 94065


                  (C) Copyright 1989, 1990 RSA Data Security, Inc.

                                          (Version 1/29/90)



          Abstract:
          ---------

          This note  describes the  MD4  message  digest  algorithm.    The
          algorithm takes as input an input message of arbitrary length and
          produces  as   output  a  128-bit  ``fingerprint''  or  ``message
          digest''  of   the  input.   It  is   conjectured  that   it   is
          computationally infeasible  to produce  two messages  having  the
          same message  digest, or  to produce  any message  having a given
          prespecified target  message digest.   The  MD4 algorithm is thus
          ideal for digital signature applications, where a large file must
          be ``compressed'' in a secure manner before being signed with the
          RSA public-key cryptosystem.

          The MD4  algorithm  is  designed  to  be  quite  fast  on  32-bit
          machines.    On  a  SUN  Sparc  station,  it  runs  at  1,100,000
          bytes/second.     On  a  DEC  MicroVax  II,  it  runs  at  70,000
          bytes/second.   In addition,  the MD4  algorithm does not require
          any large  substitution tables;  the algorithm can be coded quite
          compactly.


[Ed. Due to the length of this paper, I've placed it on the
VIRUS-L/comp.virus document archive at cert.sei.cmu.edu, where it is
available for anonymous FTP.  The filename is:
pub/virus-l/docs/md4.rsa.paper.]

          (C) Copyright 1989, 1990 RSA Data Security, Inc.
          All rights reserved.

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

Date:    Thu, 01 Feb 90 14:01:00 -0500
From:    Peter W. Day <[e-mail]>
Subject: Re: And another WDEF infection (Mac)

The WDEF virus has infected the public computing Labs at Emory
University.

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

Date:    01 Feb 90 00:00:00 +0000
From:    "David.M..Chess" <[e-mail]>
Subject: Re: Universal virus detector

>        Any time later, I can generate a new list and compare.  It is
> then up to me to decide whether any differences that show up are
> legitimate - but I have the absolute assurance that I WILL get an
> indication of any changes.

Sure, and that's certainly a good first step.  But I still claim that
it isn't by any means a universal virus detector, and would not solve
the virus problem, because the thing that is "up to you" is just too
hard.  The system can tell you that only files that you expect to have
changed have changed, but it *can't* tell you that they've changed
only in innocent ways.  That's one of the largest problems of virus
protection; the system can't in general tell, and certainly can't tell
down below the "which file was changed" level, which modifications to
the executable-set were intended by the user, and which were not.  A
system like this might catch any viruses that we know of today; on the
other hand, if it became widespread, viruses that it would not catch
(or, more accurately, that a human using it would not catch) would
shortly appear.

> Another alternative is to add another bit, the "may create
> executables" bit.  Only code running from a block marked with this bit
> may turn on the "executable" bit for another block.  Normally, only
> the linker and an image copier would have this bit set.  A virus could
> still be written - but it couldn't modify existing code directly, it
> would have to produce object code and pass it through the linker.

Or it could create the object that it wanted, and call the copy
utility.  Or is it impossible for a program to copy a non-executable
thing to an executable thing?  That would help a little, but would
also make the system less convenient to use.  How do you get a new
copy of the linker?  How do you write a patch program?

Don't get me wrong: I think these are all good ideas for future,
more virus-hardened systems.   I just want to point out that,
even if implemented perfectly, they don't make the problem go
away...

DC

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

Date:    Thu, 01 Feb 90 19:07:04 +0000
From:    grimesg@annapurna (George Grimes)
Subject: Re: Internet Worm

[e-mail] (Geoffrey H. Cooper) writes:
lines deleted ......
>
>One thing that makes me wonder: A newspaper article claims that Morris
>wanted to stop the worm when it started to get out of control, and
>decided that he wasn't able to.  When the Internet group started to
>try and control it, why didn't he offer to help?  At least a copy of
>the source code would have been of great assistance.  Instead, he
>hides and waits for the FBI to find him.
>
>Would not this have been his best opportunity to show his benign
>intentions?  Or perhaps he was advised not to help by someone.

Haven't you ever screwed up badly and then panicked?  Were you
thinking clearly and rationally at the time?  Heavy adrenalin flow is
conducive to flight, not thought.

George

*******************************************************************************
       I speak only for me...let my company form their own opinions!
*******************************************************************************

   +-------------------------------------------------------------------+
   | DOMAIN: [e-mail]        | George Grimes             |
   | INTERNET: [e-mail]         | [phone]             |
   +-------------------------------------------------------------------+

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

Date:    Thu, 01 Feb 90 16:26:00 -0500
From:    [e-mail]
Subject: Statistical Distribution of Viruses

Greg Gilbert asks:

>Should I purchase the subscription or should I buy each update?  i.e.
>What is the probability in the next year that more than four viruses
>(strains, clones, etc....) will occur?

Well, after all of this clinical discussion, we finally find an
epidemiologist.  (Greg, you will enjoy my paper in "Computers and
Security," Vol. 7 No. 2, April 88.)

The decision is analogous to the decision to be inoculated against a
biological virus.  Such an inoculation has some risk and is not free.
If it is sufficiently effective and if enough others take it, there will
be no one for you to catch the virus from.  This is another way of
saying that the virus no longer finds the population sufficiently
hospitable to prosper and spread.

I have never been innoculated against Polio-myelitis.  I often
experience reactions to innoculations.  I grew up in the midst of
epidemic polio, and was likely immune anyway.  If all of the children,
least likely people to be otherwise immune, took it, a large population
from the most likely vectors would be removed.  Yes, I really did go
through that rational, but mostly I just do not like shots.

We no longer innoculate against Small-pox.

If we could clean up the Universities, Info-Centers, and retail
establishments, we would go a long way toward suppressing viruses.
Indeed, we may have to shut down PC labs.  You can now buy a Toshiba
1000 for $549.00.  This is roughly the equivalent cost of my slide
rule thirty-five years ago.  We did not share slide rules.  The
economic motive behind the shared PCs in a lab has disappeared, but
the unhealthy little cess pools persist.  Clean up your acts!

Best, Bill

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

Date:    Thu, 01 Feb 90 23:34:52 +0000
From:    [e-mail]
Subject: Re: Universal virus detectors

[e-mail] writes:
> All this debate about whether virus detection is equivalent to the
> halting problem, whether real CPU's are best modeled and FSA's or
> Turing machines, and so on, is interesting but in a deep sense
> completely irrelevant.
>
> With simple hardware support, one can design a system in which all
> viruses are trivial detectable.
>
>         Technique:  The hardware will maintain, in both memory and
>         on disk, an "is executable code flag".  For practicality,
>         assume this is done on a block-by-block basis say in units
>         of a K.
>
>         The hardware enforces the following rules:
>
>         1.  Any attempt to execute code from a memory block which
>         is not marked executable fails.
>
>         2.  The only way to write into a block of memory that is
>         marked executable is from a disk block marked executable.
>
>         3.  Any attempt to write to a disk block marked executable
>         fails.  (To write to such a block, the executable flag must
>         first be cleared.)
>
>         4.  Any disk block can be marked executable at any time.
>
>         Memory blocks are marked executable only by reading execu-
>         table disk blocks into them.
>
>         5.  Associated with every disk block is a time stamp.  When
>         a block is marked executable, the hardware updates its time-
>         stamp.
>
>         6.  The system comes with physical ROM blocks, marked exe-
>         cutable, which contain at least the code needed to display
>         the timestamps on all executable blocks..

...

> Why does this work, despite all the proofs?

The proofs are not relevant to your idea because they deal with the
problem of deciding whether a piece of code is a virus BEFORE it gets
executed whereas your idea is a run-time system. I gather the point is
that only code in executable blocks on the disk can be executed, and
these blocks can never be created or altered in any way, and any
attempt to modify executable memory fails. OK, so your system won't
work unless flexibility is unacceptably reduced.

1. You can't do things like patch the operating system with utility
programs.  I have LOADS of utility programs on both Amiga and MS-DOS
that modify system jump tables etc. I'd far rather have to defend my
system against viruses myself than give up the use of these programs.
So that alone is sufficient to kill your scheme.

2. Sometimes you WANT to modify programs, the main example being use
of a file zap utility to install patches to the executable code of a
program.

3. You're going to HAVE to have a method for at least
creating/deleting executable disk blocks. What if the user wants to
delete or copy a program file? What if you want to extract a program
from an archive? What if you want to compile a program? What if you
want to download a program from a bulletin board? etc. etc... If
applications software can do these things then so can a virus. So your
system isn't going to be very usable, or else you'll have to give up
security. The timestamps are the only thing you're left with and how
many people are going to go into the ROM monitor program to display
the timestamps on every program on their ***-megabyte hard disk to
make sure nothing's been infected? Anyway you could probably work out
some way to beat this given that the virus has access to the video RAM
(which it _has_ to have).

I hate knocking down all these nice ideas. Someone please come up with
something that'll work, I'm beginning to think there isn't any
solution.

"To summarize the summary of the summary: people are a problem"
Russell Wallace, Trinity College, Dublin
[e-mail]

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

Date:    Thu, 01 Feb 90 14:07:18 -0800
From:    [e-mail]
Subject: 4096 virus detection (PC)

This is a forward from John McAfee:

          A number of people have called about SCAN's ability to detect
the 4096 virus.  When I said we could not detect it on disk, I was
referring to a system where the virus is active in memory.  If the
virus is not already in the system, then SCAN will of course identify
the virus on any file that you wish to scan before you run it.  If the
infected program is executed, however, then SCAN can only detect the
virus in memory thereafter.
          What I'm trying to say, I guess, is that once the virus gets
into memory and gains control, the only detection scheme that seems to
work is a scan of memory.

John McAfee
408 988 3832  (voice)
408 988 4004 (BBS)
408 970 9727 (FAX)

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

Date:    Thu, 01 Feb 90 14:13:02 -0800
From:    [e-mail]
Subject: Jerusalem Disinfectors (PC)

This is a forward from John McAfee:

          I have seen a few messages recently about the use of M-JRUSLM
for disinfecting the Jerusalem virus.  Please do not use this program,
since we no longer support it.  Clean-Up (CLEANP57) has replaced
M-JRUSLM and all of our other independent disinfectors.  If you have
any of the M-Series disinfectors (M-VIENNA, M-DAV, M-1704, etc.)
please assign them to the bit- bucket and replace them with Clean-Up.
Clean-Up is available on Compuserve, The SIMTEL archives or on
HomeBase at 408 988 4004.  Thank you.  John McAfee

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

Date:    Thu, 01 Feb 90 15:00:32 -0700
From:    Peter Johnston <[e-mail]>
Subject: Trojan Alert (MAC)

We have detected a new (to us) Macintosh trojan at the University of
Alberta.   Two different strains have been identified.   Both are
dangerous.

The first strain is imbedded in a program called 'Mosaic', type=APPL and
Creator=????.   When launched, it immediately destroys the directories
of all available physically unlocked hard and floppy disks, including
the one it resides on.   The attacked disks are renamed 'Gotcha!'.

Unmounted but available SCSI hard disks are mounted and destroyed by the
trojan.   The files of hard disks are usually recoverable with one of
the available commercial file utility programs, but often the data file
names are lost.   Files on floppy diskettes usually lose their Type and
Creator codes as well, making recovery a non-trivial procedure.

The second strain was detected in a Public Domain program called
'FontFinder', Type=APPL and Creator=BNBW.   It  has a trigger date of 10
Feb 90.   Before that date, the application simply displays a list of
the fonts and point sizes in the System file.

On or after the trigger date, the trojan is invoked and disks are
attacked as for the first strain.   The trojan can be triggered by
setting forward the Mac system clock.

Because the second strain has a latency period during which it is non-
destructive, it is much more likely to be widespread.   Both trojans
were originally downloaded from a local Macintosh BBS here in Edmonton.
The second version was part of a StuffIt! archive named 'FontFinder.sit'
that also contained documentation and the source code for the FontFinder
application.   This source code does NOT contain the source code for the
trojan.

A quick-and-dirty search string for VirusDetective (v/3.0.1 or later)
has been developed that appears to detect the trojan engine in both
strains.   It is:

        Resource CODE & ID = 1 & Data 44656174685472616B

Note that this will detect the currently known versions, but may or may
not detect mutated versions of this trojan.

There is some evidence that these trojans are related based on
preliminary investigation of the code.   It has been speculated that the
second is an 'improved' version of the first (more sophisticated), or
that the two versions were developed by two individual perpetrators
working with the same trojan engine.   There easily could be more
versions either circulating or being developed.

This appears to be the first deliberately destructive malicious code
that targets on the Macintosh.   There is some suspicion that one or
both have been developed locally.   There is also the possibility that
one or both were uploaded from a BBS in the Seattle, Washington area.

Our investigation is far from complete, but is continuing.
Please warn your Mac users to make proper back-ups on a regular basis,
be suspicious of all software not received from a trusted source until
tested, and generally, to practice 'safe computing'.

Any additional information on these two trojans or similar malicious
code would be appreciated.   As and when our investigation turns up more
details, they will be posted...

Peter Johnston, P. Eng.
Senior Analyst, University Computing Systems,
352 - GenSvcBldg, The University of Alberta
Edmonton, Alberta CANADA   T6G 2H1
Phone:  [phone]
FAX:    [phone]
EMAIL:  [e-mail]

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

Date:    01 Feb 90 10:44:09 +0000
From:    "Arne Gehlhaar" <uniol![e-mail]>
Subject: Help with removing virus requested (PC)

Hello !

This is my first posting (actually my second after a test) and hope
you'll excuse the chaos that I might be just producing ... Anyway I
have the following problem :

I just got an MSDOS exe-file via bitnet from the states, and I was
told that it was infected with the Jerusalem Virus.  Now this happens
to be the first contact I have with any kind of virus.  I *HAVE* been
reading most of the postings to this group, but it didn't make much
sense to me then.

My question is: Do I have to do anything against the virus, i.e. does
it do anything that I might not want ??? If so, what can I do about it
??? Where do I get "anti-virus" programs...preferably without paying
:)

There seem to be quite a lot of you out there who know what's going
on, so could someone please give me some hints ??

Thanks in advance

Arne

PS.: I don't have a signature file... as you can see :)

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

Date:    Thu, 01 Feb 90 15:37:00 -0500
From:    "Benjamin S. Smith" <[e-mail]>
Subject: The Ultimate Anti-Viral Solution?

An idea which rolled off the top of my head this afternoon:

Every new program which comes out for your computer also has an
"anti-virus module" with it, as a separate data file.  This module
contains information on what actions the program which you have just
acquired takes during operation.  Does the program ever change size?
Does it ever create additional files?  Is it authorized to make
changes to other programs?  What kinds of changes?  How is it allowed
to make such changes?  Does it ever run/read other programs or data
files?  and so on.  Included would be a list of all required
read/write actions which the program uses.

A central program, included with your computer from its manufacturer,
is in charge of overseeing every one of these data files.  It is a
system-wide guard against unauthorized attempts from within any
program to modify data on your computer.  If a problem occurs, the
central program spells it out for you and asks for further
instructions.

Somehow the central program would have to be referenced with every
read and write, admittedly a long process.  Maybe the program could be
a piece of hardware, a chip, or extra memory simply set aside to be
used only by the central program.  Also, the more programs you have,
the more that the central program must keep track of.  Perhaps too
much information to deal with at once.  But it sounds good, right?

This way the burden for virus protection falls on the computer
manufacturer and the software companies themselves.  No new updates of
anti-virus programs are needed, since the computer can recognize any
"incorrect" activity.  Saves your $$, as you don't have to subscribe
to an anti-virus updating service.

Feasible?  Or just too complicated?  Could such a setup be compromised
in any way short of hardware failure?  Give it some thought.....

Ben Smith
[e-mail]

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

Date:    Thu, 01 Feb 90 00:00:00 +0000
From:    "Prof Arthur I. Larky" <[e-mail]>
Subject: Timestamp virus protection

Perhaps I'm Missing Something

>Date:    Wed, 31 Jan 90 13:13:00 -0500
>From:    [e-mail]
>Subject: Re: Universal virus detector

>While it may sometimes be difficult to decide exactly what catagory
>some transitions fall into, in many cases I can be definitive.  In
>particular, there it is almost always the case that no existing
>executable should be modified, ever.  All my existing executables can
>be checked by comparing their timestamps with known-correct values.
>Think of this as a very cheap, absolutely unforgeable checksum.

>More generally, any time I am certain my system is "clean" I can
>generate and save on a secure medium a list of all timestamps on my
>disk.  Any time later, I can generate a new list and compare.  It is
>then up to me to decide whether any differences that show up are
>legitimate - but I have the absolute assurance that I WILL get an
>indication of any changes.

  I hope we're not talking about the timestamp that MSDOS puts on
a file.  Any time you want to change one, MSDOS will be glad to do
so for you since that's what Int 21H function 57H does for a living.
If you don't want to write in assembly code, it's only a few lines
in Turbo Pascal.

>For example, you can add a
>hardware-enforced switch which when in the OFF position makes it
>impossible to set the "is executable" bit at all.  In this mode, you
>can't do program development, install new executables, or even copy
>executable files - but you absolutely can't be infected either.  The
>vast majority of systems could probably spend most of their time with
>the switch in this position.

But that's what I do for a living: "program development, install new
executables, etc."  Oh, well, one can always retire to something less
challenging such as urban warfare.

>Another alternative is to add another bit, the "may create
>executables" bit.  Only code running from a block marked with this bit
>may turn on the "executable" bit for another block.  Normally, only
>the linker and an image copier would have this bit set.  A virus could
>still be written - but it couldn't modify existing code directly, it
>would have to produce object code and pass it through the linker.

  I translate this to mean "find something other than a PC or a MAC
on which to do your computing."  True, but it doesn't solve the current
problem for most of us.

Art Larky
Professor of Electrical & Computer Engineering
Lehigh University
215 Packard Bldg 19
Bethlehem, PA 18015

For all I know, this may not even be my opinion, let alone Lehigh's.

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

Date:    Fri, 02 Feb 00 19:90:53 +0000
From:    [e-mail] (Ross M. Greenberg)
Subject: FSP+ Checksumming

Y. Radai <[e-mail]> writes about the checksum *installation*
being too difficult for many people to use, and that, therefore, the
presumption I make that "nobody has complained" (basically) might not
be representative of the actual situation out there.

Well.  He could be right.  I must admit that, if I were writing the
program all over again, the installtion procedure would have been made
a lot easier.  In my wildest dreams, I never expected the program to
have the success it has.  However, in shareware, there always must be
an incentive for people to register the program - else I don't make as
much money as I could.  Registered users of FLU_SHOT+ get an
installation program that makes the job a little easier - still not as
easy as falling off a log, but a little easier.

Users of my commercial program get something that is as easy as
falling off a log, though, and get a choice of different checksum
routines.  They can even pick more than one routine, and combine the
resulting checksums/sigs into one signature.  If people are expecting
some real sophisticated checksumming stuff, though, they won;t find it
in my stuff for the reasons I've outlined before.  Perhaps I'll
include some real tough checksumming in the commercial product, if
there is enough interest.  So, far, there doesn't appear to be any
real interest, except (potentially) by *some* of the readers of this
mailing list.

>Sorry, but I don't understand why you have to get back to the "real"
>checksum.  Suppose we improve the security by making the checksums
>different for each user.  From the fact that some user's checksum has
>changed relative to *whatever* it was when that user set up his
>checksum base, we'd know precisely the same thing that you know by
>comparing with the "real" checksum, namely that his file had been
>altered (which *may* indicate infection).  So what do you gain by use
>of the "real" checksum?

I get people calling me up with problems on them checksumming already
infected files.  In most of these cases, they were not aware of the
problem.  By knowing the checksums of some popular programs (not just
the system files), I can ask them to forward me a list of their
checksummed files, ask a simple question or two and then figure out,
potentially, what file is infected.

Remember that I'm supporting (as of date) just over 20K users.  That
causes me to have to make some compromises, and more's the pity: each
update has to take longer because it affects more people, more users.
There are estimates that only 1% of the users of shareware ever
register.  If this is the case, then I have a responsibility to take
things *very* slowly with any change I make.

That's not to say that I won't consider making such a change, just
that there is a heckuva lot more that goes into making a change that
increases the security of the product by .00001% (or whatever) but
that affects 100% of the users, registered or unregistered.  I have a
wish list of changes to make to the shareware version and to the
commercial version.  For obvious economic reasons, the commercial
version gets all the enhancements first.  For certain legal reasons,
some changes can never make it into the shareware version.

Just to reiterate: I never expected FLU_SHOT+ to have the popularity
that it does, nor did I realize the restrictions such popularity
places on the author when it comes to updating the code.

Ross

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

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