Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!netnews.upenn.edu!vax1.cc.lehigh.edu!cert.sei.cmu.edu!krvw From: RADAI@HUJIVMS.BITNET (Y. Radai) Newsgroups: comp.virus Subject: Checksumming (was: Interesting advert) (PC) Message-ID: <0012.9106061535.AA06556@ubu.cert.sei.cmu.edu> Date: 6 Jun 91 11:22:00 GMT Sender: Virus Discussion List Lines: 83 Approved: krvw@sei.cmu.edu 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