VIRUS-L Digest Thursday, 26 Jan 1989 Volume 2 : Issue 26 Today's Topics: nVir (init 29) (Mac) Viral protection by checksum registration? --------------------------------------------------------------------------- Date: Wed, 25 Jan 89 15:13:46 EST From: SCOTT Subject: nVir (init 29) (Mac) I have encountered this new strain of nVir on a bunch of Mac II's with Interferon, but have not been able to successfully eradicate the infection. Also Ferret, VirusRx, and virus detective are not able to identify this virus. The virus also shows up as a code segment ID 255 or 256 which is 712 bytes long as previously noted. What is the best way to eradicate this "thing"? Is this new strain of any potential danger to documents saved on a different disk or will it just cause memory problems when the infected machine is used? Help!! Scott. ------------------------------ Date: Wed, 25 Jan 89 14:44 MDT From: Pete Klammer 303/556-3915 Subject: Viral protection by checksum registration? We could have some protection against viruses if we could compare a characteristic "signature" of a program file against a "register" of known program signatures. The "signature" would have to be fairly strong, and the problems of trusted registration and distribution of copies of the register are non-trivial. Furthermore, a virus attack can spread more quickly than registered-signature checking can be done, but at least this method offers some assurance when we're looking at a clean system. For that matter, it would let us know if we're looking at identical copies of a known virus, vs. slightly twiddled ones. What I'm suggesting is that something like a checksum be defined, but it must be long and complex enough, and include the file size, such that a counterfeit file of the same size and signature which could even execute at all, let alone do any useful viral-like damage, would be too hard or too expensive to come up with. A checksum is too weak: I can produce any checksum I want from any file if I have a few spare bytes to "seed" with checksum-compensating values. Rather, the algorithm for the "anti-viral-signature" of a file would have to be more like a high-order cyclic redundancy check or one-way trap-door encryption. I'm also suggesting that a common, trustworthy repository for registration of program files be set up. I could then know that FORMAT.COM for PC-DOS 2.1 has signature "1140745HL2K6G76G724", and FORMAT.COM for Zenith MS-DOS 3.1 has signature "1047HD2468K7G6762GR4", and so forth. Over time, that could get to be a long list: how many legitimate versions of C1.EXE (or whatever) for Microsoft C have actually been distributed (3.0, 4.0, 4.01, 4.1, 5.0, 5.01?, 5.1...?). And of course, versions of the "anti-viral-signature-checker" would have to be registered, too. With these tool, one could, on occasion or even constantly in "TSR background spare time", scrutinize a file system for corruptions. The "background" method is itself vulnerable to viral infiltration, but I should still be able to boot up from a trusted write-protected* floppy and scan my files whenever things get suspicious. (*NOTE on that noisy subject: PC floppy drives implement write protection in the hardware quite simply: the "write-enable" pin of the floppy-disk-controller chip receives its signal from an AND gate -- i.e., whenever you ask to write, AND the write-enable notch is detected, it writes. Commodore-64 drives (1541's) do not have such a hardware AND gate, and in fact, their ROM firmware can be overridden by executable code downloaded into into on-board RAM. [Speculation now:] Since Apple ]['s do so much disk control, and so economically, from inside the 6502 processor, I suspect Apple ][ write protection is firmware-based, too. These kinds of implementations feed the write-protect misunderstanding. REAL drives cannot write over a write-protect tab.) I recognize the anti-viral-signature method might be too cumbersome to catch a virus in the act, but wouldn't it be worthwhile to have a way to check if the ARC v5.13 or the MS-KERMIT v2.32A you just downloaded from somewhere is clean or crooked? * --poko Pete Klammer, Systems Programmer, (303)556-3915 * CU-Denver Computing Services / Campus Box 169 * 1200 Larimer St NC2506 / Denver CO 80204-5300 * BITNET: PKLAMMER@CUDENVER * INTERNET: PKLAMMER@PIKES.COLORADO.EDU * " I'm half Estonian, which makes up for the other half. " [Ed. Ideas like this have been tossed around quite a bit, and they certainly hold some promise (imho). They also have a lot of potential logistics problems (e.g., who distributes the CRC program itself, and how do we assure that *it* is not corrupt? a computing environment in which everyone uses the same CRC (or checksum...) would be, as it is now, relatively homogeneous - a virus could make use of this fact, and propagate freely throughout the environment.). Comments?] ------------------------------ End of VIRUS-L Digest ********************* Downloaded From P-80 International Information Systems 304-744-2253