Return-Path: XPUM04@prime-a.central-services.umist.ac.uk Received: from G.SEI.CMU.EDU by ubu.cert.sei.cmu.edu (5.61/2.3) id AA03596; Tue, 19 Jun 90 08:07:15 -0400 Received: from SEI.CMU.EDU by g.sei.cmu.edu (5.61/2.5) id AA28892; Tue, 19 Jun 90 08:07:11 -0400 Received: from nsfnet-relay.ac.uk by sei.cmu.edu (5.61/2.3) id AA02387; Tue, 19 Jun 90 08:07:00 -0400 Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa12822; 19 Jun 90 12:38 BST From: Anthony Appleyard To: DAVIDF@cs.heriot-watt.ac.uk Date: Tue, 19 Jun 90 09:41:44 BST Message-Id: <$TGWFCWKBBCVC at UMPA> Subject: Here is Virus-L vol 0 #0915 Virus-L Digest Thu, 15 Sep 88, Volume 0 : Issue #0915 Today's Topics Re: crc twiddling Re: Dual CRCs Re: CRCs Re: Student paper Re: Dual CRCs RE: Re: crc twiddling Len Adleman? THE INFECTION OF PC COMPATIBLE COMPUTERS "Dukakis" Vaccine (Mac) more twiddling... ------------------------------ Date: Thu, 15 Sep 88 00:02:22 EDT From: me! Jefferson Ogata Subject: Re: crc twiddling I apologize for my previous confusing remarks where I used CRC in place of checksum. The example I gave required adding 257 bytes, not 65535. The reason I discussed only adding bytes to the original file, rather than modifying bytes in the file, is that as far as I know, virus attacks are not effective if they crash the program they infect, which is likely to happen if they twiddle bits in the original program. Any virus attack that crashes your program will be obvious and not very pervasive. In addition, bank data files are well out of the arena of likely virus infection. As far as rearranging bytes in the original program to make the virus, this also is likely to crash the program. - Jeff Ogata -------------------- Date: Thu, 15 Sep 88 10:35:38 EST From: Neil Goldman Subject: Re: Dual CRCs In-Reply-To: Message of Tue, 13 Sep 88 09:51:00 EDT from > >< It IS possible for two different programs to have the same CRC for >< two different polynmials. >True, for any reasonable polynomials, but it gets harder very >quickly as you add more polynomials. Esp. to do it on purpose. >Has anybody seen or heard of any virus designed to pass a CRC >check? Or is this more work than the casual psychopath >is willing to incur? > EAE114@URIMVS (ERISTIC) Although I have not actually seen a virus which has been designed to pass a CRC check, I am of the school of thought that no virus prevention/detection method is foolproof. If the virus author is able to determine the polynomial used to detect file changes by the detection scheme of a particular detection product (such as disassembling an old version of FluShot which may still be in use), the virus author could calculate the number of NOP (no-operation) instructions which would need to be included the the virus to ensure that the CRC would pass ok. Neil A. Goldman NG44SPEL@MIAMIU.BITNET Replies, Concerns, Disagreements, and Flames expected. Mastercard, Visa, and American Express not accepted. -------------------- Date: Thu, 15 Sep 88 10:19:16 CDT From: Len Levine Subject: Re: CRCs In-Reply-To: Message from "Jerry Leichter" of Sep 14, 88 at 2:46 pm >The mathematics of CRC's is very simple. The basic idea can be seen more >easily by using a much simpler algorithm: Consider an input file as a very >long binary number B. Choose a some fixed number N, and compute the remainder >of B divided by N. The result is between 0 and N-1, and is your checksum. >[...] >you can produce any CRC you want by modifying just the trailing deg(Q)+1 bits >of the input. What Rabin pointed out, however, is that if you DON'T know the >polynomial, then your chance of making just the right modification is essen- >tially the same as that of guessing the polynomial, which can be made small >by chosing the polynomial from a suitably large set of candidates. > -- Jerry Thank you jerry, just right. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Leonard P. Levine e-mail len@evax.milw.wisc.edu | | Professor, Computer Science Office (414) 229-5170 | | University of Wisconsin-Milwaukee Home (414) 962-4719 | | Milwaukee, WI 53201 U.S.A. Modem (414) 962-6228 | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + -------------------- Date: Thu, 15 Sep 88 10:23:57 CDT From: Len Levine Subject: Re: Student paper In-Reply-To: Message from "VIRUS-L@LEHIIBM1.BitNet" of Sep 14, 88 at 3:42 pm > The paper has one flaw in it that I can see. It claims that Trojan horses >carry viruses in terms that imply that that's *all* Trojans do. This can >clearly not be the case, as I personally know of many Trojans that do not >carry self-replicating programs. Additionally, the term Trojan Horse as it >is used in the computer world was coined long before the term virus. There are several errors in the paper of that kind. This does not diminish its value however in that is gives one excellent example of the spread of a virus in a "protected" environment, and in that it gives a good list of commercial virus products and their prices. It is a very useful document. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Leonard P. Levine e-mail len@evax.milw.wisc.edu | | Professor, Computer Science Office (414) 229-5170 | | University of Wisconsin-Milwaukee Home (414) 962-4719 | | Milwaukee, WI 53201 U.S.A. Modem (414) 962-6228 | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + -------------------- Date: Thu, 15 Sep 88 10:35:53 CDT From: Len Levine Subject: Re: Dual CRCs In-Reply-To: Message from "Neil Goldman" of Sep 15, 88 at 10:35 am >Although I have not actually seen a virus which has been designed to pass a >CRC check, I am of the school of thought that no virus prevention/detection >method is foolproof. >If the virus author is able to determine the polynomial used to detect file >changes by the detection scheme of a particular detection product (such as >disassembling an old version of FluShot which may still be in use), the >virus author could calculate the number of NOP (no-operation) instructions >which would need to be included the the virus to ensure that the CRC would >pass ok. >Neil A. Goldman NG44SPEL@MIAMIU.BITNET It does not require a string of NOPs to do this, just a jump around two bytes and the inclusion of the suitable number in those two bytes. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Leonard P. Levine e-mail len@evax.milw.wisc.edu | | Professor, Computer Science Office (414) 229-5170 | | University of Wisconsin-Milwaukee Home (414) 962-4719 | | Milwaukee, WI 53201 U.S.A. Modem (414) 962-6228 | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + -------------------- Date: Thu, 15 Sep 88 11:54:00 EST From: "Jerry Leichter (LEICHTER-JERRY@CS.YALE.EDU)" Subject: RE: Re: crc twiddling The example I gave required adding 257 bytes, not 65535. Yes; I came to the same realization shortly after posting my note. The reason I discussed only adding bytes to the original file, rather than modifying bytes in the file, is that as far as I know, virus attacks are not effective if they crash the program they infect, which is likely to happen if they twiddle bits in the original program. Any virus attack that crashes your program will be obvious and not very pervasive. A virus can be a rather small program - a couple of hundred bytes is sufficient. Do you really believe I can't find 500 bytes to change in a 300K program that will not result in a crash until you've run the program for weeks? The usual rule is that 10% of the code accounts for 90% of the cycles. This doesn't, of course, mean that the other 90% of the code is never executed, but in practice any large program will contain TONS of code that, for all practical purposes, is never needed. Large operating systems, BTW, often contain more code to deal with error recovery of various sorts than with normal operation. Years might go by before you noticed that that code wasn't working as specified. Finally, any large program is certain to have code in it that can be made smaller, often substantially smaller, especially if you are willing to make it a bit slower and less accurate - properties you'd hardly ever notice in typical operation. Just how much it is possible to crunch code would probably astound anyone who never had to work on the systems of 15 and 20 years ago, when 128K bytes of main memory was almost incomprehensibly huge. These days, few people have to work under memory constraints - it's hard and gains you nothing on systems they use. But people skilled in this art do exist - embedded systems of various sorts are still built with small (cheap) memories, for example - and any serious virus writer could pick up the skills if he so chose. In addition, bank data files are well out of the arena of likely virus infection. Again, be careful that you don't limit the problem you are willing to examine so much that you miss things. A Trojan horse program that scrambled some of your data files by exchanging bytes here and there could do more damage to you than many viruses. If you had a checksum program, you might consider using it to checksum your data files, just to protect against this kind of thing. It had better be harder to fool than the checksums you've proposed, or you'll likely find yourself in worse shape for having trusted in it than if you had never started using it at all! As far as rearranging bytes in the original program to make the virus, this also is likely to crash the program. See above. Again, remember that "I can't think of any way to do X" is not a reasonable measure of how hard X is, unless you are VERY familiar with problems like X - and even then, it's suspect. -- Jerry -------------------- Date: Thu, 15 Sep 88 15:30:04 EDT From: "David M. Chess 862-2245" Subject: Len Adleman? I notice that Len Adleman is credited with coining the term "virus" in "THE INFECTION OF PC COMPATIBLE COMPUTERS", and in a VIRUS-L posting from Loren. Does anyone have any more details? When and where was the term coined? The earliest use of the term that I have is in 1974, a paper by Gunn referenced in Cohen's "Computer Viruses: Theory and Experiments". DC -------------------- Date: Thu, 15 Sep 88 15:52:53 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "David M. Chess" Subject: THE INFECTION OF PC COMPATIBLE COMPUTERS Nice paper! A couple of nits/questions: - Talking about COMMAND.COM, the paper says "a number of viruses have been discovered which infect this file." I believe that that number is in fact "one" (the Lehigh virus). Can anyone cite another COMMAND.COM-targetted virus that probably exists? (Vague rumors need not apply!) - In a similar vein, I would advise being a little less confident when stating things like "four versions of the Israeli virus and seven versions of the Brain virus have been found." It may be true in the most literal sense of "version" (anyone could create a "new version" of one of these by changing a text or no-op byte), but there doesn't seem to be any good evidence that it's *really* true, in the sense of there being that many versions that actually have some difference in their behavior. (Authors, especially in the popular press, always seem to be tempted to exaggerate, if only by implication, the number of different viruses they know of; makes them sound wiser...) - The advice to write-protect COMMAND.COM should probably include a note that this will not in fact do any good against a virus whose author has thought of the possibility (and most probably will). It's still not bad advice, but the user should be aware that it's not a Real Solution to anything. I don't mean to imply in my first two points that I'm one of these folks who doesn't believe viruses exist! I know they do. I just don't think that there are as many different ones loose in the world as some column-writers would like to imply. DC -------------------- Date: Thu, 15 Sep 88 17:13:32 EDT From: Joe McMahon Subject: "Dukakis" Vaccine (Mac) Well, let's fight fire with fire. If somebody's going to publish a virus, I'm going to publish the matching vaccine. To use this vaccine, cut on the dotted lines, download it to your Mac, paste it into the scrapbook, and then paste it into your Home stack in HyperCard. If that's beyond what you're willing to try with HyperCard, get the newest version of my virus documentation stack from LISTSERV at SCFVM -- it has a button that will do it for you. (Note: that may not be available until tomorrow (9/16)) - -------- CUT LOOSE --------- -- Note: "Duk-akis" contains a dash here to prevent the vaccine from -- detecting itself as a virus. -- Script to detect the spread of the "Duk-akis" virus. It works by -- trapping the "set" command. I haven't seen "Duk-akis", but I should -- think that it works by setting the scripts of various objects to -- whatever they were plus an "on openStack" handler. Well, by trapping -- the "set" command, we can then find out if we are setting a script. -- If we are, then we can sort of work like "Vaccine" does; i.e., we -- prompt the user to see if he or she wants to allow the command to -- continue. If it is stopped, then all scripts are halted. -- Additionally, if the script contains the word "Duk-akis", then no -- option is given Q the script is halted straight away. -- THIS SCRIPT SHOULD BE INSTALLED IN THE "HOME" STACK, -- IN THE STACK SCRIPT. -- You can test this script by making a new stack, then keying the -- following examples into the message box: -- % "Set the script of this stack to empty" -- % "Set the script of this stack to field 1" -- % "set the script of this stack to Duk-akis" (don't type the dash) -- Try it, I think you'll like it! -- This script is free to everyone apart from the person who wrote the -- "Duk-akis" virus. I just hope it affects every single stack he or -- she has or gets in the future! -- Regards to all from a truely devoted HyperCard fan, -- Ian Summerfield -- Technical Support Supervisor -- Apple Computer UK Ltd. -- CIS: 76657, 742 -- "Sysop" - AppleFone HyperCard BBS: Luton, England: 0582 584134 -- Modified slightly 8/22/88 by Joe McMahon to make sure that --"set the scriptI" (vs. "set script") doesn't slip through. -- Modified a bit more 8/29/88 by Joe McMahon to add Ian's fixes -- to prevent the vaccine from detecting itself as a virus. on set put "Duk"&"akis" into duk if the param of 1 is "script" or the param of 2 is "script" then get the params if last word of it is "to" then put it && "empty" into it put it into s if s contains duk then repeat 10 play harpsichord tempo 300 "a b c b a b c b" end repeat answer duk&&"virus detected!" with "Halt scripts" answer "Okay, you're safe now! It didn't spread." exit to HyperCard end if play harpsichord tempo 200 "e c e c e c e" answer "Warning: Script change requested" with "Show me" repeat answer s with "Allow" or "Stop!" or "Show more" if it is "Allow" then pass set else if it is "Stop!" then answer "All scripts halted!" exit to HyperCard else put the userLevel into userSafe set userLevel to 5 doMenu "New Field" get the number of card fields set rect of card field it to 0,19,512,342 set style of card field it to scrolling put the params into card field it choose browse tool wait until not the mouseClick wait until the mouseClick choose field tool click at loc of card field it doMenu "Clear Field" choose browse tool set userLevel to userSafe end if end if end repeat else pass set end set - ------- All right, you can stop here --------- - - Joe M. -------------------- Date: Thu, 15 Sep 88 19:56:03 EDT From: me! Jefferson Ogata Subject: more twiddling... >A virus can be a rather small program - a couple of hundred bytes is >sufficient. Do you really believe I can't find 500 bytes to change >in a 300K program that will not result in a crash until you've run the >program for weeks? >... >Finally, any large program is certain to have code in it that can be >made smaller, often substantially smaller, especially if you are willing >to make it a bit slower and less accurate - properties you'd hardly ever >notice in typical operation. Sure you can find 500 bytes you can change in many programs. But I'll bet you a Snickers bar you can't write a 500 byte program that can find them. I'll bet you a Mars bar that you can't write a 500 byte code optimizer. To be fair, though, one possibility that might not have occurred to you is this: write a virus that compresses the original code before installing itself; then fills in bytes appropriately to match a checksum. On execution it decompresses the original code and runs it. This allows you to beat checksums, file size checks, and CRCs simultaneously. And the original program won't crash. Such viruses have been discussed, though not with the intention of beating virus detection methods. >A Trojan horse program that scrambled some of your data files by >exchanging bytes here and there could do more damage to you than many >viruses. Perhaps, but this is VIRUS-L. I was discussing methods of protecting against viruses. In addition, I made no claims about the desirability of the checksums I mentioned; I merely discussed some of the associated math. The fact that it's possible to circumvent the checksums is not under investigation. No method is perfectly foolproof. - Jeff Ogata -------------------- *** end of Virus-L issue ***