Path: utzoo!attcan!uunet!lll-winken!csd4.milw.wisc.edu!mailrus!cornell!biar!trebor
From: trebor@biar.UUCP (Robert J Woodhead)
Newsgroups: comp.sys.atari.st
Subject: Re: Virus 101: Chapter 3
Message-ID: <395@biar.UUCP>
Date: 19 Mar 89 05:25:37 GMT
References: <4035@ttidca.TTI.COM> <11179@ut-emx.UUCP> <7494@boulder.Colorado.EDU> <389@biar.UUCP> <72651@ti-csl.csc.ti.com>
Reply-To: trebor@biar.UUCP (Robert J Woodhead)
Organization: Biar Games, Inc.
Lines: 67

In article <72651@ti-csl.csc.ti.com> holland@m2.UUCP (Fred Hollander) writes:
>Ah, but they are within the power of software developers to foil these
>viruses.  Knowing exactly how these viruses work (source code helps,
>effects may not), applications can protect themselves from infection
>or from spreading a virus once infected.  A few simple examples
>include: checking the number of code resources present, the size of
>the code resources, a checksum of each code resource, etc.  Concealing
>the method of the viruses puts everyone at a disadvantage relative the
>creators of the viruses, and leaves us all extremely vulnerable.  You
>may argue that it's okay to discuss the methods but, not list source
>code.  A fine line, indeed.

I believe that I made my position clear in a previous posting; publishing
methods for foiling virus attacks is legitimate.  However, you (as a
developer of software) don't need copies of virus source code to do this,
as you just proved in your reply!!!  I'm all for disseminating information
such as "Viruses infect by a) adding a code resource and modifying code 0,
b) adding code to the end of a code resource and modifying an entry point,
c) adding and INIT, (etc, etc).  You can protect your programs by doing X".
This fills the need, and does not materially help virus authors.  To use
an analogy, I don't need source code for the Mac Roms to understand them
and use them properly; you don't need source code for viruses to defend
against them.  In fact, abstracted information about a particular virus
is more useful to you than source, because someone else has done the work
of picking it apart for you, and doesn't help virus authors.
  
>I don't have the most thorough knowledge of virus protection software,
>but, it appears that GateKeeper provides the most effective "before
>the fact" protection.  The problem is that you need to relax the
>protection for many applications to work.  If each individual
>application would protect itself from infection (or refuse to run if
>it detects infection), the protection would be far more effective and
>transparent to the user.  It should eliminate the need for "after the
>fact" virus detectors/eliminators.  This could even be applied to
>system software and by requiring advance permission before running
>INIT's, most, if not all, of the *simple-minded* viruses would be
>foiled.

I agree.  Gatekeeper is a wonderful bit of software; I use it myself.
As for detecting infections, I have already published a method similar
to the one you mentioned above here previously.  It's simple, and it
works.  Virex has a similar system embedded into it so that if it gets
infected, it can be used to determine if a new strain has been found
(for, if a good copy of Virex can't remove a virus from a copy that
says it's infected, you've found a new virus).

>I'm sure that this would encourage a better strain to develop, but, it
>would require more intelligence and would therefore be less common or
>frequent.  And when it does come along, publish the details so
>developers can take further precautions to combat the new strain.

This is already done.  The fact is, while you cannot protect your application
against any viral attack (even if you keep duplicates of each code segment
so you can repair, a virus could be written that understands and attacks
your program), you can write a checksumming routine that will reliably
detect a viral infection, and that is simple and robust enough that you
can mutate it every so often so that a targeted virus would only attack
a subset of your users, thus blunting it's reproductive capacity.

I guess I could boil down my analogy to this:  It's irresponsible to
publish information on how to make an atomic bomb, but it's laudable to
publish information on how to detect that your neighbour is building one.

-- 
* Robert J Woodhead * The true meaning of life is cunningly encrypted and *
* uunet!biar!trebor * hidden somewhere in this signature...               *
* Biar Games, Inc.  *                       ...no, go back and look again *