🚀 go-pugleaf

  Mike Lawrie writes:
>They [checksum programs] don't cater for this scenario:-
>
>1. Somehow infect the RAM of your PC with a COM/EXE targetting
>   virus, such as Plastique (eg run an infected program from a
>   floppy, or from a network).
>2. Run SCAN on your hard disk - this does a DOS open on all COM/EXE
>   files on your hard disk, and thus infects each and every such
>   file _after_ SCAN has pronounced them virus-free
>3. You end up with every COM/EXE file on your disk having to be
>   reloaded, but you believe otherwise until you find out the
>   bitter truth
>4. You treat checksum checking programs with utter disgust, because
>   they fooled you into believing that you had protection.

First of all, Step 2 of this scenario is certainly not characteristic
of COM/EXE infectors in general, as you seem to imply.  (E.g., it
won't happen with the Jerusalem virus.)  It has to be a very special
virus to do this.
  Secondly, what you have described shouldn't happen with SCAN, since
before scanning it checks for the presence in RAM of viruses which act
in this way, and that includes Plastique, unless you're using an old
version of SCAN.  (If this really did happen to you with a *recent*
version, contact McAfee.)
  Finally and most important, suppose we have a virus in memory which
SCAN or some other program does not recognize, and the above scenario
does occur.  What does this have to do with checksumming programs??
Checksum programs don't claim to *prevent* infection, only to *detect*
an infection *after* it has occurred, the next time the checksum pro-
gram is activated on an infected file.  And this is precisely what
they will do even in your scenario (provided you ensure that RAM is
clean when the checksum program is activated).  Thus your conclusion
in Step 4 is unjustified.  What you need in order to *prevent* scena-
rios like this is to supplement the checksum program with a good gene-
ric monitoring program.

  Padgett Peterson writes:
>Well some form of integrity checking must go resident, even if it is
>just smart enough to call the checksum program. Otherwise, what is
>going to identify that a program is new or changed. (you could handle
>"changed" with a zillion little .BAT files but new ?) Since you do not
>want to add to the pilot's workload, it must be automatic therefore
>resident.

Sorry, Padgett, but I don't understand what you're trying to say.  As
existing checksumming programs are implemented, they notify you that a
file has been changed the next time the checksum program is activated
on it (which is normally long before the virus can do any damage).
What are the zillion .BAT files needed for?
  We seem to be talking on different wavelengths, but since I don't
know where the misunderstanding lies, I'll have to start from the
beginning (sorry if what I say is obvious):
  Some types of programs can be run either *statically*, i.e. as a
non-resident program activated on demand (or via the AUTOEXEC.BAT
file) to do something to all files or a specified list of files all at
once, or (2) *dynamically*, i.e. as a memory-resident program to do
it to each executable file just before execution.  (These are my
terms; maybe you have a better suggestion.)  For example, among
known-virus scanners, McAfee's Scan is a static program, while his
V-Shield is a dynamic program.  In precisely the same way, a check-
summing or integrity-checking program can be implemented either stati-
cally or dynamically.  And if it's done statically, then just as SCAN
is not memory-resident, nothing here need be memory-resident either.
  Most checksumming programs which I know of  can or must be implemen-
ted statically, and for good reason: The surest way to ensure that no
stealth virus can hide modifications is to do static checking immedi-
ately after booting from a clean write-protected diskette.  Dynamic
checksumming is more convenient, but as far as I know, there's no way
of guaranteeing that it can't be fooled by a stealth virus.  If some-
one can produce convincing evidence that there is such a way, I'd be
glad to hear of it.
  Now perhaps what you mean to say is that only a resident program can
notify the user *immediately* that an executable file has just been
created or modified.  If so, I agree, but I see this as the task of a
generic monitoring program, not of a checksum program.  (Also, when
someone speaks of integrity checking, I assume he's referring to a
checksum program.  Do you mean something else?)

                                     Y. Radai
                                     Hebrew Univ. of Jerusalem, Israel
                                     RADAI@HUJIVMS.BITNET
                                     RADAI@VMS.HUJI.AC.IL