Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!netnews.upenn.edu!vax1.cc.lehigh.edu!cert.sei.cmu.edu!krvw
From: CHESS@YKTVMV.BITNET (David.M..Chess)
Newsgroups: comp.virus
Subject: re: Universal Virus Detector
Message-ID: <0009.9004101500.AA09233@ubu.cert.sei.cmu.edu>
Date: 9 Apr 90 05:00:00 GMT
Sender: Virus Discussion List <VIRUS-L@IBM1.CC.Lehigh.EDU>
Lines: 77
Approved: krvw@sei.cmu.edu

jmolini@nasamail.nasa.gov (JAMES E. MOLINI) writes:
> If you have questions, or see a flaw in the process, please let us
> know.  We are building a virus detector, which could be placed into the
> public domain, that uses the techniques below to detect virus
> infections.  Our initial tests have shown encouraging results. ...

These comments are based on the abstract only, not the paper
(I'll eventually figure out how to FTP from here...).

Modification detectors seem like a promising way of detecting at
least some "new" (not seen before) viruses.   The usual problems
faced by a modification detector include:

 1) A virus that knows about the detector (or about a class
    of them to which it belongs) might make changes that the
    detector won't detect.
 2) A similarly detector-aware virus might update the detector's
    database to reflect the changes it makes when it infects.
 3) A virus might (by luck or design) modify files in such a way
    that the user, presented with a list of files that have
    changed, will not notice anything wrong.
 4) If the virus is active in the system when the detector runs,
    it could lie to the detector about the state of the system.

A simple CRC approach runs into point (1): if lots of people start
using your detector, and it always uses the same CRC polynomial,
it's not all that hard for the virus to include code that patches
infected objects so that the CRC is the same as it was before
infection; a CRC isn't hard to invert.   My favorite solution to
this is to allow the user to specify his own polynomial (through
the use of a "key phrase" or whatever); other solutions also
exist (crypto-based MDC's and such).  I gather from the abstract
that the exact scheme used isn't fixed by the proposal; that's
a reasonable approach.

I gather that your point (f)
> f.  In order to prevent a virus from attacking the CRC table, we will
>     add a set of dynamic "State Vectors" for the machine, which define
>     the run time environment for the detector.  This creates an
>     unforgeable "fingerprint" of the detector as it exists in memory
>     and can be prepended to each file prior to computing the CRC.

is supposed to deal with my point (2), but I don't really
understand it.  If it's possible for the detector to update the
database (and it must be, when the user gets new pieces of
software and so on), then it's possible for a virus to as well,
if the database is ever r/w to the system while the virus is
active.

(3) is one of the harder problems, I think; in some of the
environments that are most important to protect (program
development environments, for instance), many executables
will be expected to change.   Helping the user figure out
which changes are OK and which are not is something that
needs considerable thinking about, I think.  Doing it
perfectly is probably impossible (a good reason to avoid
calling anything a "universal" virus detector...).

Most of the abstract seems to be devoted to (4); making sure
the virus isn't lurking anywhere when the detector runs.
This is the general computer-security problem of getting the
system into a trusted state; I tend to think that the
problem needs to be solved at the system level rather than
the application level (that is, there should be a good
wired-in procedure for getting the system into a trusted state,
rather than making every security application program do
it itself).   I doubt that any piece of software in DOS can
really determine that the system is trustworthy; checking
interrupt vectors doesn't tell you anything about the code
they're pointing to, for instance.  Painful as it is, the
only method I know of that I trust is booting cold from a
trusted floppydisk.

Sounds like an interesting project, though, and I -will- try
to get the full paper...

DC