VIRUS-L Digest Friday, 3 Nov 1989 Volume 2 : Issue 230 VIRUS-L is a moderated, digested mail forum for discussing computer virus issues; comp.virus is a non-digested Usenet counterpart. Discussions are not limited to any one hardware/software platform - diversity is welcomed. Contributions should be relevant, concise, polite, etc., and sent to VIRUS-L@IBM1.CC.LEHIGH.EDU (that's LEHIIBM1.BITNET for BITNET folks). Information on accessing anti-virus, document, and back-issue archives is distributed periodically on the list. Administrative mail (comments, suggestions, and so forth) should be sent to me at: krvw@SEI.CMU.EDU. - Ken van Wyk Today's Topics: CRC checking Re: Checksum programs Re: Self-checking programs (PC) Re:Virus source available in Toronto DBASE Virus and SCANV47 (PC) decompiling a virus --------------------------------------------------------------------------- Date: Wed, 01 Nov 89 00:00:00 +0000 From: "Prof Arthur I. Larky" Subject: CRC checking A CRC will work if you: (1) Keep the polynomial secret and personal. (2) Keep the comparison information secret and personal. You can accomplish (1) by having the checker ask for the polynomial (or some portion of it) when you boot up and start the checking. The checker should NOT store the polynomial on disk anywhere. You can accomplish (2) by having the checker ask for the check file name and/or path when you boot up and start the checking. Both of these are a pain to do, but losing everything on your hard drive is much more of a pain. Of course, you should still do regular backups (I do lots of program development, so I back up everything on floppy as soon as I create it) and have someone's program watching your disk for you. The basic rule is: Be Different! MSDOS is vulnerable because it is so well-known how to write lethal things to disk. If you name your checksum file "Checksum.fil", you are looking for trouble! I know I can find a name and a sub-directory for it that I wouldn't recognize a month later. Art CSEE Dept Lehigh University Bethlehem, PA Disclaimer, disclaimer, disclaimer ------------------------------ Date: 01 Nov 89 20:53:10 +0000 From: len@csd4.csd.uwm.edu (Leonard P Levine) Subject: Re: Checksum programs kerchen@iris.ucdavis.edu (Paul Kerchen) writes: > This point brings up a problem which is common to most checksumming > solutions: where does one store these checksums and their keys? If > they are stored on disk, they are vulnerable to attack just like > programs. That is, a virus could infect the program and then update > its checksum, since the key must be somewhere on disk as well (unless > the user enters it every time they compute a checksum--yecch!) and one > must assume that the checksum algorithm is known. The checksum program and the checksum should be stored in a place that is different on each machine. Furthermore, there is no special "best" crc or testing algorithm, many will do with varying polynomials. A satisfactory system is one in which each user can use a polynomial of his/her choice and where the list of files and their crc's (for example) is stored in some arbitrary location. No virus writer will be looking for YOU, rather just a collection of systems that are alike enough to infect. When dutch elm disease comes around, you should look like an oak tree. Be different enough so that only a specific attack can defeat your defences, not just some attempt to infiltrate command.com. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Leonard P. Levine e-mail len@evax.cs.uwm.edu | | Professor, Computer Science Office (414) 229-5170 | | University of Wisconsin-Milwaukee Home (414) 962-4719 | | Milwaukee, WI 53201 U.S.A. FAX (414) 229-6958 | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + ------------------------------ Date: 02 Nov 89 02:02:35 +0000 From: berman-andrew@YALE.EDU (Andrew P. Berman) Subject: Re: Self-checking programs (PC anti-virus protection) In article <0006.8911011255.AA25780@ge.sei.cmu.edu> leif@ambra.dk (Leif Andrew Rump) writes: >If a virus killer can patch a program so can a virus! Exactly as virus >detectors is able to find a virus by looking at the code so is the >virus able to detect the virus killer and disable it! That's life!! I wonder if that's actually the case. Consider that most of the virus' created so far have been under 3 kilobytes. A virus must be somewhat small to avoid detection- a 40k patch to every program could be detected visually by the user with a 1 meg floppy disk. Perhaps a very complex virus killer could patch a program in such a way that only a very complex virus could unpatch it- a patching algorithm X with a proof on the order of "patch algorithm X cannot be unpatched by a program with less than 100k" or something like that might do some good. Or, perhaps we could design patches that might be unpatchable by a short virus, but would take a great deal of time. We're not really too concerned about length of time it takes to patch, since that only would occur once for each program. Thus, a patching algorithm X which can be proven to be computationally-hard to unpatch would be effective because the virus might be required to take up a great deal of computer time, again providing a means to alert the user. Frankly, I find the stuff fascinating... I think there's some theoretical computing issues involved here, but hey, what do I know, I'm only a grad student. Andrew P. Berman berman@yale.edu ------------------------------ Date: Thu, 02 Nov 89 18:47:07 +0100 From: fbihh!swimmer@uunet.UU.NET (Morton Swimmer) Subject: Re:Virus source available in Toronto kelly@uts.amdahl.com (Kelly Goen) writes: >Yes it is indeed true that viral sources are published in several >areas... however "Viruses , A high Tech disease" published only >overwriting viruses!! more similar to a logic bomb as when they infect >the target executable the file is immediately destroyed(VERY EASY to >detect) by the overwriting process. However any COMPETANT Assembly >coder can manufacture far more unobtrusive viruses if he just thinks >about it!! the published sources working or non working are really not >that much of a threat... Oh yes they are! It is very much easier to start from a working source than to start from scratch. Irrespective if you are "competant" or not. Just take the source, think of something and implement it. It will take you far less time, and the inhibition is far less. This is exactly what happened to one of the viruses published in R**** B*****'s book. Not long afterwards, presto! we had the Vienna (648) virus! Granted, its just a small chip off the block, but you must try everything to win this war. Cheers, Morton ------------------------------ Date: Thu, 02 Nov 89 15:09:50 -0800 From: portal!cup.portal.com!Alan_J_Roberts@Sun.COM Subject: DBASE Virus and SCANV47 (PC) A number of folks have looked at the DBASE virus (Ross Greenberg's discovery), including Joe Hirst, Steffan Campbell and T.B. Allen, and the general consensus is that the virus is very similar in style to the TYPO virus (The COM version). If the author of these two viruses is one and the same person, then perhaps the DBASE author has not completely been "re-habilitated" as Ross Greenberg has suggested. If this is the case, then the DBASE virus may have been placed into the public domain (and would indeed account for the inexplicable DBASE problem reports that have been received over many months by the CVIA). Accordingly, SCAN V47 has been updated to include a check for this virus. Better safe than sorry. Alan ------------------------------ Date: Thu, 02 Nov 89 22:30:19 -0800 From: ames!dhw68k.cts.com!stein@apple.com (Rick 'Transputer' Stein) Subject: decompiling a virus I just finished reading "With Microscope and Tweezers: An Analysis of the Internet Virus of Nov. 1988" by Eichin and Rochlis in the Proceedings of the 1989 IEEE Symposium on Security and Privacy. They discuss the decompilation process but only in a vague sense. What is decompilation? Do you actually have to take apart a core dump, find the opcodes, operands, and build a hi-level pseudocode from this? Is there an automated tool, or hunk of software which decompiles images for you? How do you detect a virus in core with a "process interagator" if something like this exists. - --rick ------------------------------ End of VIRUS-L Digest ********************* Downloaded From P-80 International Information Systems 304-744-2253