RADAI@HUJIVMS.BITNET (Y. Radai) (06/06/91)
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
ccml@hippo.ru.ac.za (Mike Lawrie) (06/08/91)
RADAI@HUJIVMS.BITNET (Y. Radai) writes: > 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 >>.. >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. We were hit with Plastique. Having inspected it, there seemed to be reason for me to believe that other viruses might use a similar method to trigger the infection algorithm. > 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.) Indeed, McAfee contacted me (good Company, they were concerned). We had an old SCAN at the time, but sooner or later this scenario will re-occur, as you will get hit with a similar type of virus that McAfee has not yet catered for, even if you have their very latest version. You then end up with your RAM infected, but you are living in Disneyland (like we did) believing otherwise, and you then proceed to zap your hard disk. Sure, theory says that it won't happen. hahaha. > 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?? We have a checksumming program as well - the original article to which I tried to reply asked for comments on such a thing. The checksumming program indeed may let you know that you _have_ been infected - big deal, in my opinion, if any advert lulls you into a sense of security because you have a checksummer in place. A checksummer gives you no security whatsoever, because it does not prevent a viral infection. Not that much else does either, for that matter, but that is not the point, the advert needs to be taken with a hefty pinch of salt. Just that our experience that I wished to share was that with a checksummer in place and use of SCAN, you can end up with every last EXE/COM file on you hard disk looking very sick indeed. Mike - -- Mike Lawrie Director Computing Services, Rhodes University, South Africa ....................<ccml@hippo.ru.ac.za>.......................... Rhodes University condemns racism and racial segregation
RADAI@HUJIVMS.BITNET (Y. Radai) (06/17/91)
Mike Lawrie writes: > ... sooner or later this scenario [infecting >files by performing SCAN while a virus like Plastique is in RAM] will >re-occur, as you will get hit with a similar type of virus that McAfee >has not yet catered for, even if you have their very latest version. Right; I specifically stated that that could happen, and I mentioned that in order to prevent such occurrences, you could add a good gene- ric monitoring program. You didn't reply to that suggestion. But actually, there is a surer solution which I mentioned only later on in my posting, but which I should have mentioned here also: If you want to be certain that such occurrences cannot occur, never run a program like SCAN or a checksummer except when you are certain that RAM is clean, i.e. only immediately after booting from a clean disk- ette. (Authors of such programs should mention this; if they don't, and that apparently includes McAfee, you have a legitimate gripe against them.) > A checksummer gives you no >security whatsoever, because it does not prevent a viral infection. True, a checksummer does not prevent infection, but at least it can *detect* infections, and that's a lot better than no security at all!! Knowing that certain files are infected, you can restore your files from backups or use a disinfector, something which you wouldn't do if the infections were not detected. Moreover, if the checksummer is properly designed and implemented, (1) it can detect *all* infections, and (2) it cannot be neutralized or circumvented by hostile software. These are advantages that are almost impossible to find in any other anti-viral software. In my opinion, the best software solution is a *combination of several* programs: a good checksummer (like V-Analyst), a good generic monitor (like Secure), a known-virus scanner (too many to mention names), a program which prevents infections through floppy boots (to be mentioned soon), and more. I use all of them; the resident programs don't take up much RAM, and they coexist peacefully (well, most of them ...). >Just that our experience that I wished to share was that with a >checksummer in place and use of SCAN, you can end up with every last >EXE/COM file on you hard disk looking very sick indeed. Quite true ... *if* you don't take the proper precautions. Y. Radai Hebrew Univ. of Jerusalem, Israel RADAI@HUJIVMS.BITNET RADAI@VMS.HUJI.AC.IL
padgett%tccslr.dnet@mmc.com (A. Padgett Peterson) (06/19/91)
>From: Y. Radai <RADAI@HUJIVMS.BITNET> > Mike Lawrie writes: >> ... sooner or later this scenario [infecting >>files by performing SCAN while a virus like Plastique is in RAM] will >>re-occur, as you will get hit with a similar type of virus that McAfee >>has not yet catered for, even if you have their very latest version. >Right; First, organizations have been woefully lacking in training of personnel expected to deal with malicious software (a management problem). Our technicians get two days of targetted training before being certified to respond to suspected viruses. That said, since employees are instructed to power down and quarentine any PC suspected of having a virus, the first action after questioning the employee for symptoms is to cold boot from a write-protected floppy and check the system out in that manner including a "scan" of the disk and examination of the MBR and DOS Boot Record Only if that comes up negative is the PC allowed to boot itself. At this point the system integrity is repeatedly validated using MEM/DEBUG and CHKDSK to determine if something is trying to go resident. At this point, McAfee's SCAN is often used in a different way: the command "SCAN NUL /M" results in only memory (no files) being checked for all viruses it knows about. If this fails then file comparisons are done and the audit trails are checked (all PCs including employees home machines are authorized to use a site-licensed checksumming program). Again a layered approach by trained personnel is necessary to protect against the sort of global disaster mentioned (incidently, during my training session at the CSI Conference in Denver, I thoroughly infected the demo PC with the 4096 only to discover that there was no 5 1/4 boot floppy to use for recovery - Had several 3 1/2s for the laptop, but no 5 1/4s. Entertaining.) BTW the McAfee product .DOCs do mention in several places the advisability of booting from a known clean, write-protected floppy first. >>A checksummer gives you no >>security whatsoever, because it does not prevent a viral infection. >True, a checksummer does not prevent infection, but at least it can >*detect* infections, and that's a lot better than no security at all!! Depends on the checksummer - the one we use performs the checksum routine on any program presented for execution. If the program is not known to the audit trail, a screen warns the user that the program is unknown. Depending on the setting, the user may or may not be permitted to execute the program. I suppose that this really comes under the heading of access control but should be part of any integrity management solution. >... a program which prevents infections through floppy boots (to >be mentioned soon)... I believe that VSHIELD protects from hot-boots now - do not believe that prevention from cold boots can be done without hardware or special BIOS. My next project now that DISKSECURE is essentially complete will be a small addition to warn the user on boot if a floppy is in the drive - should not be difficult or require much code (trap cntrl-alt-del, check for floppy, write warning message, loop for response), several viruses make use of this technique already so it cannot be too difficult (famous last words). Cooly (a/c working again) Padgett