Xref: utzoo comp.sys.atari.st:14749 comp.sys.mac:28675
Path: utzoo!attcan!uunet!lll-winken!ames!killer!pollux!ti-csl!m2!holland
From: holland@m2.csc.ti.com (Fred Hollander)
Newsgroups: comp.sys.atari.st,comp.sys.mac
Subject: Re: Virus 101: Chapter 3
Message-ID: <72651@ti-csl.csc.ti.com>
Date: 18 Mar 89 21:05:21 GMT
References: <4035@ttidca.TTI.COM> <11179@ut-emx.UUCP> <7494@boulder.Colorado.EDU> <389@biar.UUCP>
Sender: news@ti-csl.csc.ti.com
Reply-To: holland@m2.UUCP (Fred Hollander)
Followup-To: comp.sys.atari.st
Organization: TI Computer Science Center, Dallas
Lines: 56

In article <389@biar.UUCP> trebor@biar.UUCP (Robert J Woodhead) writes:
>In article <7494@boulder.Colorado.EDU> fozzard@boulder.Colorado.EDU (Richard Fozzard) writes:
>>
>>These points are well taken, but just to stimulate the debate, this is from 
>>the official statement by Computer Professionals for Social Responsibility
>>(CPSR) on the Internet virus :
>>
>>"An effective way to correct known security flaws is to publish descriptions
>>of the flaws so that they may be corrected.  We therefore view the efforts to
>>conceal technical descriptions of the recent virus as shortsighted."
>>
>>from the Winter 89 CPSR Newsletter
>>
>Ah, "technical descriptions" is one thing, "source code" is another.  Also,
>the Internet virus exploited security flaws that were within the power of
>system administrators to change.  Macintosh viruses use published features
>of the OS that are not likely to change anytime soon (such as the resource
>manager).  Publishing a description of "this is what Virus X does; you
>can detect is by looking for Y;the following procedure Z will remove it"
>is appropriate and laudable.  Publishing "Here is the MPW source code of
>the new "Trash your Hard Disk" virus" is an invitation for misbehavior.

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 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'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.

Fred Hollander
Computer Science Center
Texas Instruments, Inc.
hollander@ti.com

The above statements are my own and not representative of Texas Instruments.