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

Text File | 1995-01-03 | 16KB | 366 lines

VIRUS-L Digest   Wednesday, 11 Apr 1990    Volume 3 : Issue 74

Today's Topics:

Signature Programs
Re: Death of a Virus
Re: Death of a Virus
Re: Universal Virus Detector
FTPing Disinfectant
Re: Death of a Virus
validation
False Indications from VIREX 2.5.1 (MAC)
Virus on Apollo? (UNIX)
Re: Validating Virus Software

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

   Ken van Wyk

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

Date:    10 Apr 90 09:36:58 -0400
From:    Bob Bosen <[e-mail]>
Subject: Signature Programs

Several weeks ago, Ross Greenburg challenged me to obtain and post
descriptions of tests and user experiences involving use of
sophisticated authentication algorithms in the "real world" against
real viruses. Because I represent a commercial software vendor I
was hesitant to publish my own test results out of fear I would sound
biased. Most of my clients are rather secretive, and it took a while
before I was able to arrange for the following to be written and
cleared for posting. The following is a message forwarded from
Padgett Peterson, a well-known (in some circles) virus researcher,
employed by a well-known Defense Contractor. He speaks only for
himself.

Padgett conducted a detailed evaluation of a great many viral defense
products, subjecting them to a collection of viruses and stressing
them in other ways. I am posting his words for him because at the
moment, his internet access is rather awkward. He comments on valuable
ways to use authentication algorithms at all ends of the spectrum, and
I find his views similar to my own, inasmuch as my product offers
authentication algorithms at all ends of the spectrum and allows
users to "fine-tune" the sophistication of the algorithm to suit all
the extremes and norms Padgett discusses. But there are things in his
views that'll make a lot of folks happy. The following are his words:


FOR POSTING

                                                 A. Padgett Peterson


Recently, following a hiatus from the VIRUS-L forum, I have had the
opportunity to examine the continuing authentication (thank you
WordStar) saga.  All of the people involved appear to be knowledgeable
and concerned participants, yet they seem to be arguing the same side
of two different questions:

1)  Authentication of known software in a controlled unique environment

(Radai and Greenberg).

2.  Authentication of unknown, publicly transmitted software (Bosen and

Murray).

The virus issue, while a valid concern, is just a complicating factor,
since, if the software were trusted, by definition it could not be
infected.  The focus of the issue is what level of authentication is
necessary for trust.  All of the participants agree that some is
necessary - the question is how much?

My personal feeling is that an authentication algorithm may be very
simple (CRC or less) provided that it is unknown (or unpredictable).
Since my 4.77 Mhz/ST-412 museum piece is capable of a simple byte
count/XOR/ROR disk file check at 50k bytes/second (and could be faster
if done in RAM by a TSR between LORD and EXECUTE), performance
concerns are unnecessary (quantum economics).  This method is suitable
for any physically controlled system.

Unfortunately, Mr. Greenberg's algorithm fails this test because it is
publicly known.  A mechanism designed to subvert his programs is
feasible (worm, trojan, virus, bomb, etc.).  However, given a small
number of different algorithms (ADD/SUB/XOR followed by ROL/ROR/NOP
give nine easily) generated by a machine-unique seed (time hack at
initial algorithm load would work), a non-resident intruder would have
a very hard time subverting a system without generating a few errors
first.

This is particularly effective if even the creator of such a program
cannot predict which algorithm/seed will be used on a particular
machine.

A procedure such as this is even workable in a networked/server
environment: the file itself is stored en clair.  Each authorized user
has a unique signature file.  No two signatures match yet each will
authenticate the same file in the proper machine.  A nightmare for
intruders.

Alternatively, a publicly transmitted file for which the algorithm/key
is also public requires a much more rigorous algorithm to avoid
spoofing or infection by a determined intruder.  In this case ANSI or
DES is appropriate.

Taken together, the indication would be that for inter-machine
transmission, the more rigorous public-key methods would be
appropriate, while a much simpler one would be suitable for
intra-machine retrieval.  This would postulate a software package
that:

a:  Uses a simple (fast) but unique algorithm for known files whose
signatures are stored on the platform.

b:  Requires a much more rigorous authentication process for unknown
files (possibly also requiring authorization for load).

c:  Once (b) is satisfied allows a file to migrate to (a).

Considering the viral threat, if a virus is accompanied by a valid
signature, ANY authentication scheme will pass it, however, as aoon as
a resident file is infected, the unique resident signature will become
invalid.

The point was raised concerning Boot and Partition Table Infectors
(Hidden Sector, FAT, Root, RAM-Resident, and Bad Sector Infectors are
also possible).  This is a different question from that of
authenticating a file.  At present I know of only one package that
provides complete coverage: Enigma-Logic's Virus-Safe which I use.

However, over 90% of all PC virii could have been caught early by a
CLI that occasionally compares the Top-Of-Memory, the end of DOS/TSR
memory, and the first byte of the Boot Sector against known values.
MS-DOS doesn't.

(END OF PADGETT PETERSON POSTING)

Thank You,


Bob Bosen
Enigma Logic Inc.

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

Date:    Tue, 10 Apr 90 11:39:00 -0500
From:    [e-mail]
Subject: Re: Death of a Virus

A more accurate analogy might be the introduction of clean water
systems rather than the elimination of smallpox.  The widespread use
of modern operating systems with memory and device protection will
greatly hinder the spread of viruses, but by no means prevent their
spread.  I can think of methods to implement Unix and VM viruses.
Most of these depend upon sloppy system administration methods for
rapid spreading, but at least for now sloppy administration is the
norm.  Some of these have been demonstrated by attacks like the
Internet Worm.  But with a more modern hardware and operating system
it is much harder to spread and easier to cure.  This is similar to
what you find today with water-borne diseases.  Typhoid, cholera, and
dysentery are by no means eliminated in the US, but they are no longer
a normal cause of death.  They promptly return after disasters break
down the water systems (well cholera is still rare, but would recur if
the breakdowns lasted long enough).

Probably the greatest strength of most current systems is the
diversity of hardware and operating system revisions.  This forces the
use of source (non-executable) for most inter-machine transfers and
greatly hinders the spread of viruses and worms.  The strong
commercial push for standard binary interfaces is a danger in that it
will greatly increase the size of the computer population that is
vulnerable to any one specific attack.

R Horn  [e-mail]

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

Date:    10 Apr 90 00:00:00 -0500
From:    "David.M.Chess" <[e-mail]>
Subject: Re: Death of a Virus

[e-mail] (Kelly Goen) writes, apparently in response
to a posting of mine:

> Yes dave but under environments which use say the VM8086 model on
> the 386 (such as VPIX) file writability and/or hardware acces is
> TOTALLY under the control of unix...  weak unix security weak dos
> security good unix security = good dos security in this case....

My point was that putting file access under the control of the
operating system *doesn't help*, at least not as much as people
generally assume.  Viruses spread by writing to files that they are
*allowed* to write to; they don't depend on a lack of security.  If
most programs have write access to only a few other programs, viruses
may not be able to spread as fast; but lowering the exponent on an
exponential spread helps surprisingly little.

Now of course this may be what you were saying; I'm not entirely sure
I understand the posting...

DC

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

Date:    10 Apr 90 22:44:00 +0000
From:    [e-mail] (Alan L. Pope)
Subject: Re: Universal Virus Detector

A Universal Virus Detector?  Go reread Goedel's Incompleteness Theorem.
                                        Alan Pope <[e-mail]>

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

Date:    Tue, 10 Apr 90 15:49:57 -0400
From:    [e-mail] (Eloise Kleban)
Subject: FTPing Disinfectant

Someone recently commented on the difficulty of downloading
Disinfectant from Simtel20.  I would say it is easier to
access sumex-aim.stanford.edu for Macintosh software.  Simply
FTP the files in ascii mode (non-binary) to your CMS account,
then download them (again, in ascii) to your Mac.  On the Mac
use Stuffit to decode and un-archive the applications.  I
recently acquired Disinfectant 1.7 this way with no trouble.

Eloise Kleban                     BITNET:   ELOISE@MAINE
Academic Coordinator              INTERNET: [e-mail]
Computing Center                  Phone:    [phone]
University of Maine
Orono, ME, USA 04469

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

Date:    Tue, 10 Apr 90 22:50:39 +0000
From:    Dave Ihnat <[e-mail]>
Subject: Re: Death of a Virus

[e-mail] (David.M.Chess) writes:
>Unfortunately, viruses do not depend on this hardware model; viruses
>can spread in any system that allows both programming and information
>sharing, regardless of whether or not programs have direct access to
>the hardware, whether or not the system is assumed to be single-user,
>and so on.  See various papers by Fred Cohen on the subject.  As long
>as (roughly) some programs sometimes have write-access to some other
>programs, viruses can spread.
>Dave Chess
>IBM T. J. Watson Research Center

As a practical matter, I was trying to not go into a lecture on the
differences between the hardware and software models you bring up.
But the baseline is this: All of the single-user machines which are
currently the major targets of viral attack provide NO hardware model
which allows preemptive control by the OS or monitor of program access
to memory or hardware.  Thus, in such systems, it is categorically
impossible to provide a reliably virus-free environment.

Systems which provide the underlying hardware CAN be made much more
secure.  In this environment, it is still possible to improperly use
the provided capabilities and thus grant unauthorized access; but this
is not a case of CAN be secure, but DIDN'T make it secure but had the
capability.  As a real- world example, Unix and VMS systems don't see
the widespread attacks that single-user systems such as the PC and Mac
have "enjoyed."  Attacks on such multi-user/multi-tasking systems that
are successful invariably result from either errors in the protection
mechanisms (usually, not the hardware itself, but rather the operating
system which utilizes it) or errors in application of the provided
protections, either by programmers (privileged programs that don't
properly control access, etc.), or by administrators and users who
don't use such capabilities as ACL's and file permission settings.

So the point I was making is that in an environment which doesn't even
provide underlying hardware support for protection, it's impossible to
make a secure, safe system no matter how good you are in software
development.  Having the hardware, however, does not guarantee such
security; but id does make it possible.

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

Date:    Wed, 11 Apr 90 01:05:41 -0400
From:    *Hobbit* <[e-mail]>
Subject: validation

The best way anyone could validate his antiviral is to distribute the
sources.  Which most of these authors seem highly unwilling to do, for
some odd reason.  Did you ever wonder what they were hiding sometimes?
This exe-file validation stuff is a crock.

_H*

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

Date:    Wed, 11 Apr 90 08:08:22 -0500
From:    [e-mail]
Subject: False Indications from VIREX 2.5.1 (MAC)

HJC Software, authors of VIREX Virus Detection Software, has confirmed
a bug in their software version 2.5.1, ALL software written in
QuickBasic will give you a false msg of a Trojan Horse being detected.
HJC Software will be releasing version 2.6 shortly which will correct
this problem.  It will be sent to all registered users.

This was brought to my attention by a fellow ham radio operator, O.P.,
KF4TE, who attempted to use a program MacLogger.  I have personally
talked to Chris Lyons, VE3GUS, author of MacLogger and confirmed that
his software WAS written in QuickBasic.

JIM

************** From the Desk of Mr. James M. Vavrina **************
*            Comm 703-355-0010/0011  AV 345-0010-0011             *
* DDN: [e-mail]  AMPR: KA4USE @ KA4USE.VA.USA.NA *
*******************************************************************

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

Date:    11 Apr 90 12:28:16 +0000
From:    [e-mail] (Nils Hagner)
Subject: Virus on Apollo? (UNIX)

Does anyone know whether any viruses have been found on Apollo
workstations? In that case, are there any available anti-virus tools?

==============================================================
Nils Hagner | UPMAIL: [e-mail]                   |
            | Infologics: [e-mail]                   |
==============================================================

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

Date:    11 Apr 90 12:55:19 +0000
From:    [e-mail] (SRB)
Subject: Re: Validating Virus Software

In article <see References:> (Gary Mathews) writes:
>In fact, a list of must commonly used programs should be included on
>such a list, but for now the validated strings of the lastest versions
>for the scan and clean programs should be publically accessible.  Many

I always wondered: shouldn't the crc-32 and crc-16 of zip and arc files be
unique enough to validate any file?

Why can't we just put these checks and the length of a file on the net.
If you insist, then of course you could add any propietary validation values
like the ones obtained from the validate program.  But I'm pretty sure that
most people trust their favorite zip or arc program more than some kind
of a so-called validate program.
- --
Sincerely,                         | [e-mail]
           Stephen R. van den Berg | ...!uunet!mcsun!unido!rwthinf!cip-s01!berg

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

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