Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!samsung!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!netnews.upenn.edu!vax1.cc.lehigh.edu!cert.sei.cmu.edu!krvw
From: rwallace@vax1.tcd.ie
Newsgroups: comp.virus
Subject: Re: Universal Virus Detector
Message-ID: <0003.9004101500.AA09233@ubu.cert.sei.cmu.edu>
Date: 9 Apr 90 13:45:20 GMT
Sender: Virus Discussion List <VIRUS-L@IBM1.CC.Lehigh.EDU>
Lines: 44
Approved: krvw@sei.cmu.edu

jmolini@nasamail.nasa.gov (JAMES E. MOLINI) writes:
> I am working with a colleague on defining a robust virus detection
> utility.  The following is an extended abstract of a paper which
> discusses an approach we are investigating.  The work was undertaken as
> part of a research project sponsored by the National Aeronautics &
> Space Administration at the Johnson Space Center.  Please look it over
> and tell us (or Virus-L) what you think.

This is I think the fourth serious attempt on this newsgroup to propose a
universal virus detector. Unfortunately like all the rest it won't work.

        (theoretical UVD discussion)

> So to put our theoretical UVD into practice, on, for example, an IBM
> PC, we would do the following:
>
> a.  Begin by validating the integrity of the detector code.  This has
>     been discussed above. [not included in abstract]

How? I haven't copied your entire posting in this followup because it was too
long but I couldn't see any proposed method for validating the detector code.
And an obvious way to defeat your mechanism is to overwrite the detector
program with code that always says "OK".

        ...

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

What do you mean? Another obvious way to defeat the detector is to recalculate
CRCs for infected programs and put the new CRC value into the table. I don't
see any way to prevent this other than storing the table offline (which would
create what most users would consider unacceptable hassle).

Also your detector would detect most resident programs as well as multiuser
systems and upgraded versions of the operating system as viruses because it
checks the system call vectors.

"To summarize the summary of the summary: people are a problem"
Russell Wallace, Trinity College, Dublin
rwallace@vax1.tcd.ie