From: Kenneth R. van Wyk (The Moderator) Errors-To: krvw@CERT.ORG To: VIRUS-L@IBM1.CC.LEHIGH.EDU Path: cert.sei.cmu.edu!krvw Subject: VIRUS-L Digest V5 #118 Reply-To: VIRUS-L@IBM1.CC.LEHIGH.EDU -------- VIRUS-L Digest Monday, 22 Jun 1992 Volume 5 : Issue 118 Today's Topics: Viruses, Anti-virals, & change (PC) "Wonder-2" False Alarms in NAV 2.0 update 4 (PC) Untouchable Network. (PC) No Frills 2/3 Scanner needed! (PC) scan 91 et al - reported as trojan?? (PC) Request for Info on PC-Cillin (PC) Re: Zipped Viruses (PC) Re: VIRx version 2.3 released (PC) Virus Warning (PC) Is there a virus in Identity Scanner software? (PC) Re: ISPNews & Virx (PC) Re: Zipped Viruses (PC) Help! Does anyone know about any known UNIX viruses (UNIX) Re: MVS Virii (IBM MVS) Scanning for encrypted viruses Re: Taxonomy of viruses Re: Theoretical questions Re: Teoretical questions New files on eugene (PC) Eugene has a new name!! (PC,Mac,etc.) 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. (The complete set of posting guidelines is available by FTP on cert.sei.cmu.edu or upon request.) Please sign submissions with your real name. Send contributions to VIRUS-L@IBM1.CC.LEHIGH.EDU (that's equivalent to VIRUS-L at LEHIIBM1 for you BITNET folks). Information on accessing anti-virus, documentation, and back-issue archives is distributed periodically on the list. A FAQ (Frequently Asked Questions) document and all of the back-issues are available by anonymous FTP on cert.org (192.88.209.5). Administrative mail (comments, suggestions, and so forth) should be sent to me at: . Ken van Wyk ---------------------------------------------------------------------- Date: Fri, 12 Jun 92 09:56:15 -0400 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: Viruses, Anti-virals, & change (PC) >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) >Subject: Detecting the MtE (PC) >3) I(n) my message on Virus-L/comp.virus I clearly stated that ALL the >three scanners tested FAILED the test. >...Both me and Dr. Fred Cohen >clearly explained in our messages why anything less than 100 % >detection of a particular virus cannot be acceptable. It is evident that two things are happening, one: commercial vendors are starting to dominate the industry and two) Single point answers are clearly no longer sufficient. The first is something that I have seen several times before, in fact any time a "new" industry appears. At first, the only people interested are the talented amateurs who freely exchange information in much the same way as information on atomic theory was exchanged in the '20s & '30s. Generally the next interest is by educational and governmental institutions which begin to formalize study and which have the assets required for study. Concurrently the first restrictions on information flow appears. Meanwhile small commercial organizations spring up to take advantage of a new market. Thirdly, the niche commercial interests begin to dominate and public discussion centers on the virtues/limitations of various products rather than underlying theory. Entry into the market at begins to becone more difficult. Finally, once workable standards and mechanisms appear that do not need constand tweaking, the broad-base commercial interests fold the new technology into their products while most of the original companies either are absorbed, become broad-based, resign themselves to ever smaller nitches, or disappear entirely. At present, it would appear that the anti-virus industry is reaching the middle of the third stage with elements of the fourth stage beginning to manifest. With the introduction of the mTe toolkit, the limitations of pure scanning are beginning to manifest. With one jump we have gone from over 1,000 viruses (I know) to over 10,000. "100%" detection is now expected. The only way (on soapbox) to achieve this is through integrity management. 100% is achievable through change detection with some of the most effective products (PC-DACS, Enigma-Logic) remaining effective year after year with little or no change. Meanwhile, the scanners are recognizing this. Frisk's heuristic analysis and McAfee's /AF and /CERTIFY switches are good examples. More and more good systems first determine that *something* has happened before trying to determine *what*. Since most programs resident on a machine do not change or change only at specific quantum points, exception conditions are necessary but not necessarily onerous. (Enigma-Logic's PC-VirusSafe is a good exemple that I have been using for some time (plug). If I change a program, on the next invocation a screen appears letting me know that it has changed and asking for instructions - - update audit-trail/checklist, allow to run once, abort. If I perform a major change such as installing a new version of a package, I can tell it to update an entire directory, subdirectories, or drive. It is also one of the few products that can go resident from CONFIG.SYS). The power of such a product is that when an attack occurs, it can notify the user. A scanner is then brought out to find out *what* has happened. Once the problem is identified and removed from memory, the integrity management program may then be used to determine which programs have been altered. Since the affectede programs are now known, they may be disinfected or deleted. Further, an execution audit trail may be examined to determine which program caused the problem. Unless a specifically directed attack is made, (and there are ways to guard against this as well) the above method works. 100%. Of course there is a cost. At the moment this is in the range of 7-11k of RAM. On an XT a minor performance hit is noticable. With a 286/386/486/etc machine it is effectively nil unless an exception occurs. As far as anti-virus products are concerned, they are out there. At present, I do not know of any case of "one size fits all", it takes layers. At home I use four different ones (five if you count frequent BACKUPs) but this is probably overkill. Getting back to the original subject, scanners have been called "flawed" for a 95+% detection rate. To me this is acceptable because there is another means for achieving 100% every time. Once you know that "something" has happened, all else falls out. The hard part is being able to say "This is enough". Warmly, Padgett Who is John Galt ? ------------------------------ Date: Fri, 12 Jun 92 16:36:18 +0000 From: doc@magna.com (Matthew J. D'Errico) Subject: "Wonder-2" False Alarms in NAV 2.0 update 4 (PC) Hi, all... Updated and "Final" Info ! I thought I'd pass along the essence of a thread from compuserve in which some false alarms have been caused by Norton Anti-Virus' update (04) for version 2.0 which was released on June 1st... Several instances have been reported where this update reported infections of the "Wonder-2" strain of the "Wonder" virus in commercially distributed software... These infections include files from : Borland C++ 3.0 (TOUCH.COM) Mavis Beacon Teaches Typing 2.0 Stacker 2.0 VCD.COM (from VCD.ZIP - shareware ?) Intermission 3.0 (IMSETUP.COM) SHEZ v7.1 (3 different files : SHEZCFG.COM, SGREG.COM and DUMPMAC.COM) among others... IN most of these cases, the infection was reported to the authors or companies involved who have in turn verified the files as correct, and thus not infected... SYMANTEC subsequently backed out the Wonder-2 definition from it's release calling it "over-agressive" and promising a corrected detection in its 06 update due out soon... The back-out is available in an update 05 which is the same as update 04 but without the Wonder & Wonder-2 definitions... - -- Matt +-------------------------------+---------------------------------------+ | Matthew J. D'Errico | DOMAIN: mderrico@magna.com | | Magna Software Corporation | uucp: uunet!magna!mderrico | | 275 Seventh Avenue | CompuServe: 70744,3405 | | 20th Floor +---------------------------------------+ | New York, NY 10001 | Voice : 212 / 727 - 6737 | | USA | Fax : 212 / 691 - 1968 | +-------------------------------+---------------------------------------+ ------------------------------ Date: Sun, 14 Jun 92 19:59:54 +0000 From: basil@aelle.cs.odu.edu (Keith Basil) Subject: Untouchable Network. (PC) I read an ad placed by Fifth Generation for thier "Untoucable Network" security package. I'd like some additional information on this product from a user's standpoint. (installation, etc..) Thanks. Keith ------------------------------ Date: 15 Jun 92 11:18:35 +0000 From: chore@neumann.une.oz.au (Prince Of Darkness) Subject: No Frills 2/3 Scanner needed! (PC) I have a suspicion that i have the No Frills virus on my pc, i've been looking for a scanner to find out for sure, but have been unable to find one, can anybody help.....It's no frills vers 2 or 3, and i've heard it can do screwy things to your FAT, i've had nothing really bad happen yet, but a friends computer has, and so have others he's had contact with, so i think he may have given it to me, are there any non-comercial scanners out there that can detect No frill sna d kill it? If not what's the best (qand cheapest) commercial scanner that will get rid of it? Thanks - -Chris ------------------------------ Date: Tue, 16 Jun 92 00:56:54 +0000 From: tyers@rhea.trl.OZ.AU (P Tyers) Subject: scan 91 et al - reported as trojan?? (PC) A recent PC Update (published by the Melbourne PC User Group in Melbourne, Australia) made comment that versions 90 and 91 of scan have been found as trojans. Since I have distributed scan91 to a number of machines on this site I would appreciate comment. The versions I distributed were sourced from the mirror site archie.au and the validate results matched the message on comp.virus (Message-ID: <0019.9205301711.AA42463@CS1.CC.Lehigh.EDU> Date: 28 May 92 23:21:22 GMT) from mcafee Associates. All executables passed a scan by scan89b as well. Do I have a potential problem? Has scan91 and/or the associated clean/vshield etc been identified as trojans anywhere? If so from what sites? thanx in advance P Tyers, Tel. +61-(0)3-2536794 JANET: p.tyers%trl.oz.au@uk.ac.ucl.cs ACSnet: p.tyers@trl.oz UUCP:{uunet,hplabs,ukc}!munnari!trl.oz.au!p.tyers CSnet: p.tyers@trl.oz.au ARPAnet: p.tyers%trl.oz.au@uunet.uu.net HAM: VK3KTS MAIL: Telecom Research Laboratories,P.O. Box 249,Clayton,VICTORIA 3168,AUSTRALIA ------------------------------ Date: Tue, 16 Jun 92 08:28:08 +0700 From: Vincent Tracey Subject: Request for Info on PC-Cillin (PC) Hello Netters, Has anyone any information concerning a virus protection system called ** PC-cillin **. The only information I have is a claim that it can - stop - all known virus'- ?:^( The package includes an RS 232 device for *trapping* virus'. Any assistance in this matter is appreciated. Replies can be sent to the e-mail addresses shown below or via the Digest (if Ken doesn't mind -?;^). Thanx, Vincent Tracey E-mail: traceyv@heidelberg-emh2.army.mil Security Investigator aeusg-hd-po-s@heidelberg-emh2.army.mil 411th BSB Security Office Phone: 049-6221-57-8054/6456 APO AE 09102 DDN 370-8054/6456 ------------------------------ Date: Tue, 16 Jun 92 09:30:21 +0200 From: Magnus Olsson Subject: Re: Zipped Viruses (PC) David_Conrad@MTS.cc.Wayne.edu writes: >In VIRUS-L v005i111 Magnus Olsson writes: >>David_Conrad@MTS.cc.Wayne.edu writes: >> >>[excellent description of stealth viruses deleted] >> >>Thanks for a very informative article! There's one point I think >>you're missing, though, when describing the dangers of using scanners >>on an infected system: >> >>>Here's what happens: Your virus scanner is infected with a stealth, >>>fast infecting virus. It isn't currently active. You run the scanner, >>>telling it to scan your entire hard drive. First the virus gets control: >>>It goes resident, takes over, then runs the scanner. Now the scanner >>>attempts to perform a self-check on its file. This detects nothing, >>>because the virus disinfects the file as it reads it. Now your scanner >>>goes through your entire hard drive, reading all programs. Not only >>>does it have no chance of catching the virus in any program, but every >>>program (even ones which weren't infected before) will get infected!!! >> >>At least McAfee's scanner doesn't only check files on the disk and >>make a self-check, but also scans memory for viruses before doing >>anything else. Doesn't this cure the above problem, as the >>memory-resident stealth virus would be detected in memory? > >Not if the afore mentioned virus is a new one which the scanner does not >yet detect. In that case, you're in big trouble. Thanks for your comments (and thanks to the other people who've written similar replies). I'm well aware that a scanner can't protect against an unknown virus. What I'd like to point out, however, is the following (I'm sorry if it wasn't clear from my post): The original post stated a number of reasons why stealth viruses are especially dangerous, ending with the point quoted above about scanners. Now, with a scanner that first scans memory, there are two cases: a) The scanner recognizes the virus. In this case, it will be caught already in RAM, *before* the scanner starts reading files (where the virus won't be recognized). Therefore, no files are infected by the scanner. b) The scanner doesn't recognize the virus. In this case, all the files scanned will of course be infected. But this is not specific for stealth viruses; *any* unrecognized virus of the file-infecting variety does this. In short, my point is that *if* the scanner checks RAM before it starts checking files, stealth viruses are *not* any worse than "ordinary" viruses _in the context of what happens when you're running the scanner_ (though they are from other aspects). The reason I'm writing this is *not* that I think the advice presented here (when suspecting a virus infection, always boot from a clean disk before scanning) is wrong - on the contrary! But I feel that in the field of computer virology, everybody should have as precise information as possible, even on minor issues like this one. IMHO, exaggerating the dangers of, say, stealth viruses is potentially dangerous, as it may lead to exaggerated actions by people who believe they're infected - such as people throwing away SCANV because hey've heard somewhere that "scanners are dangerous". - -- Magnus Olsson | \e+ /_ Dept. of Theoretical Physics | \ Z / q University of Lund, Sweden | >----< Internet: magnus@thep.lu.se | / \===== g Bitnet: THEPMO@SELDC52 | /e- \q ------------------------------ Date: 16 Jun 92 08:29:44 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: VIRx version 2.3 released (PC) AMN@VMS.BRIGHTON.AC.UK (Anthony Naggs) writes: > Vesselin you are over looking the fact that there are already 2 > versions of MtE in circulation, one ('0.92' I think) is found on > "Dedicated" & "Fear" and the other ('0.90') is on "Pogue". I have > only looked at the one on "Pogue" so far, and around 20% of the files > I infected were corrupt. No, all the three viruses - Dedicated, Fear, and Pogue use one and the same version of MtE - 0.90-beta. Look at the code and you'll see that I am right. If Pogue destroys some files, the reason is that the virus is buggy, not the MtE. MtE has another bug - that in about 10% of the cases it produces non-encrypted mutations. > If the MtE detection tests that you are performing are going to be of > relevance you will need to test for the variations produced by "Pogue" > as well. I am testing the scanners for detection of MtE-based viruses. Therefore, it doesn't matter what virus I am using for the tests (except in the case of the non-encrypted mutations). If Pogue is buggy and damages some of the infected files, then this is yet another reason not to use it for the tests - I'll have to determine which files are damaged and to remove them. This will be quite time-consuming. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN ** PGP public key available by finger. ** Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: 16 Jun 92 09:38:31 -0400 From: Charles Rutstein <75300.3104@CompuServe.COM> Subject: Virus Warning (PC) Just a heads-up, folks. Here at the ICSA Virus Research Center in DC, we've received several calls for help in the last few days concerning the fish boot infector. Calls have come from all parts of the continental United States. This morning, one of the infected users called back to tell us that he had traced the infection to the original disk from a hand scanner he'd recently purchased. The disk was infected and still factory write-protected. He then claims to have gone to the store where he purchased the product and convinced them to open another package. Guess what? You got it...fish (boot). The disks allegedly infected are from a company called IDENTITY. No product name was given. Note that we do not yet have a copy here...there are several on their way to us. There should be no need for general panic (please!), as nearly all recent scanners will detect the virus. We'll provide more info as it becomes available and after we've had a chance to contact the company. While we can't confirm the infection just yet, it *looks* initially like a solid bet. Phone number here is 202-364-8252 for questions, etc. Charles Rutstein ICSA Virus Research Center ------------------------------ Date: Tue, 16 Jun 92 15:46:36 +0000 From: ajchuah@mtu.edu ([*BARK*]) Subject: Is there a virus in Identity Scanner software? (PC) I am buying a Identity Scanner over the net and recently, someone told me that the software that comes with the scanner contains virus. Could someone tell me if this is true? Another thing is could someone tell me the best way to cure the software if the disk is really infected. Please include info on the best method to scan and clean the disk. Thank you all. Prompt reply please. - -- ******************************************************************************* * Alex J Chuah * *BARK* *BARK* *BARK* * * ajchuah@mtu.edu * In Love with OS/2??? * * ajchuah@mtus5.cts.mtu.edu * * ******************************************************************************* ------------------------------ Date: 16 Jun 92 13:41:05 -0400 From: "Ross M. Greenberg" <72461.3212@CompuServe.COM> Subject: Re: ISPNews & Virx (PC) >Date: 12 Jun 92 10:38:19 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) >...Wait a minute. What do you mean by "some of the above mentioned > 10,000 viruses"? Do you have them? Sorry: I was referring to the 10K viruses I've generated here, mostly from Dedicated/Fear and Pogue. Had a problem in generating that many due to a small disk, but there's always .ZIPing subsets.... >...Or are you speaking about a different (not ours) test set? > Because I had a look at some of the non-detected files and they seem > to be perfectly in order... The problem with the non-detected ones was due to an optimization we did on the algorithm immediately before release without adequately testing the change(s)....it looked like such a simple change, too....Sigh. Fixed, of course, and due out as soon as it goes through a more extensive beta. Ross ------------------------------ Date: 17 Jun 92 08:51:42 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Zipped Viruses (PC) sbonds@jarthur.Claremont.EDU (007) writes: > Would it be feasible to write a virus defense package that would ONLY > run after booting from a clean, write-protected floppy? The Feasible - yes. Practical - probably no. Suppose that you have a computer with only one floppy disk drive and want to scan a huge number of possibly infected diskettes. This means that the product must load entirely in memory (all the fancy menus, virus signatures, etc.), or constantly ask you to swap diskettes. The former is achievable, but requires a lot of memory, and the latter is so inconvenient that nobody will use such a product. > programming aspect is fairly straightforward, It is not that straightforward. How do you detect that the user has booted from a floppy? I mean - reliably? You can check COMSPEC, but it means nothing since the user could change it. Under DOS 4.0 and above you can ask about the drive the system has been booted from, but what about the other DOS versions? You can check whether the product is run from a floppy, but this does not mean that the user has booted from there. I don't say that it is impossible - just not so easy as you probably think... > but would people accept a product like this? Probably not. A simple and stupid integrity checker is able to detect all of the currently existing viruses, if you always boot from a floppy before using it. (If you want to make it resistant to some advanced attacks, you need to make it more intelligent.) Yet people either prefer to use scanners (none of which is able to detect -all- of the currently existing viruses), or if they use an integrity checker, they almost never boot from a floppy... > Ideally it would include a known clean copy of > DOS with it, but this could cause problems with copyright laws, etc. Indeed. It is possible to use only the two DOS hidden files (i.e., no command interpreter), but the license fee will be still to high... A better way is to make the program run when you boot the diskette and use no DOS or file system at all - like some games do, but this requires some programming efforts, makes updating the scanner not so easy, and the whole program inconvenient to the user. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN ** PGP public key available by finger. ** Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: Tue, 16 Jun 92 12:42:47 -0500 From: pc@jido.b11.ingr.com (Speaker to Bittyboxen) Subject: Help! Does anyone know about any known UNIX viruses? (UNIX) John Guh writes: |> A customer of mine is worried about computer virus on tapes which |> contained Timeplex`s application software to be loaded on a SUN |> SPARCstation. |> |> Has anyone ever heard of computer virus on UNIX systems? Are there |> any virus detection program for UNIX? Short answer: in the wild, no. Unix has so far been protected by the variety of OS variants, I/O media, and machine architectures. Unix viruses are far from impossible, and have been created for research purposes; but they are not a significant factor in the Real World(tm) yet. Lest you be too sanguine, though, I'd predict that the first real Unix virus will infect Sun systems just because there are so many out there (recall that the famous Internet Worm of 1988 affected only VAXen and Sun3's, but still reached about 6000 hosts). Quoting with permission (mine :-) from an internal Intergraph paper on this question: The potential threat, even in the current mixed-up mess of different Unix flavors, instruction set architectures, and directory layouts, is greater than what has actually been observed. Theoretical results \footnote{Fred Cohen: Computer Viruses: Theory and Experiments, in {\it Computers and Security} 6 (1987) pp. 22-35, Elsevier (North-Holland)} indicate that viruses can spread anywhere that programs are shared, and that the general problem of detection is not tractable. These results hold even in compartmented systems. Duff \footnote{Tom Duff: Experience with Viruses on Unix Systems, in {\it Computing Systems}, Vol. 2 No. 2 (Spring 1989)} gives the text of a virus that can infect all the writeable shell scripts on a System V machine. Such a virus is trivial to detect and disinfect, but since every system has a {\sf /bin/sh} and anywhere from hundreds to thousands of scripts, the possibility of a virulent shell script virus getting out of hand cannot be blithely discounted. It follows from Cohen's model that any enhancement in the ability to share programs between PCs is an enhancement in the virulence of any infection that does arise. A very good culture medium, therefore, is a LAN with many PCs and one or a few file servers. In this environment, a non-PC file server could be carrying programmed threats to which it is itself immune, and passing them on to PCs which execute programs from the file server (the Typhoid Mary syndrome). - -- end quote -- Therefore a good crypto-checksum program would be a nice addition to any network. It is possible to roll your own such facility on any Unix system that has a decent crypt command (see Garfinkel and Spafford for a simple recipe). - -- *************************-><-************************* ** Craig "Interferon" Presson pc@jido.b11.ingr.com ** *************************-><-************************* ------------------------------ Date: 16 Jun 92 08:16:30 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: MVS Virii (IBM MVS) rslade@sfu.ca (Robert Slade) writes: > While not, in the very strictest sense, a virus, the CHRISTMA EXEC of > 1987 nevertheless was a self-reproducing object which operated with > IBM mainframe systems and over mainframe network links. More exactly, the CHRISTMA EXEC was a chain letter, not a virus or a worm. It depended on the user action to spread. Anyway, for more information about virus-related problems on MVS, I suggest the paper King M., "Viruses and Related Mechanisms in MVS", Software World, Vol. 20, No. 1, pp. 2-4. > While no data was at risk, CHRISTMA resulted in denial of service and > extra time expended in its removal. I think that a destructive variant has been detected in the USA. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN ** PGP public key available by finger. ** Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: Fri, 12 Jun 92 13:34:25 +0000 From: raphael@ms.uky.edu (Raphael Finkel) Subject: Scanning for encrypted viruses If a virus encrypts itself by a variable key that is a single byte, and uses that byte to xor its code, then the xor of adjacent bytes of its code is unaffected. So a 'first-derivative' scan string could contain not the bytes of the virus, but the xor of adjacent bytes of the virus. This scan string would still be very virus-specific, but would be encryption-invariant. If the key is longer than a byte, the same idea works, with appropriate adjustments. It will not work if the virus is variable in other ways, or if it uses a different encryption method, or if it chooses among several encryption methods. I have not seen this idea suggested here, but perhaps it has been. Is it viable? ------------------------------ Date: 16 Jun 92 08:25:21 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Taxonomy of viruses mkkuhner@phylo.genetics.washington.edu (Mary K. Kuhner) writes: > Taxonomy was originally based on the biologists' intuitive ideas about > organism relationships too, but algorithms for describing and > systematizing these intuitions still proved useful. > I agree, however, that it will be very hard to do anything mechanical > about classifying viruses. It was hard for biologists, and a > biological organism is easier to get a grip on than a computer virus. More important, the classification of the live organisms is based on our knowledge about the natural laws (e.g., evolution, natural selection, etc.). The computer viruses do not evolve naturally - they are created and modified by humans. That's why, the same classification approach cannot be applied to them. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN ** PGP public key available by finger. ** Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: 16 Jun 92 14:16:25 -0400 From: "David.M.Chess" Subject: Re: Theoretical questions > From: Homo homini lupus! > What is a POset? A partially ordered set. Which means (as I recall) for at least some elements x and y in the set, x>=y, and the >= relation obeys the usual rules. The "partial" means that perhaps for some x and y, neither x>=y nor y>=x. Something like that... *8) > ... if for all i in N, v(i)>=i then v is absolutely isolable. This means that if a virus v makes programs larger, it's possible to tell whether a given program P is the result of v infecting some other program. This works for any notion of "larger" for which it's true that there are a finite number of programs not larger than any given one (so it works for bytes, but probably not for runtime.) Adelman says that the proof is trivial, and it is in a sense. If you have a program P of length L, and you want to see if it is the result of infecting some other program with v, "all" you have to do is apply v to every program of length less than L, and see if the result is ever P. This is of course utterly and completely impractical for any real example ("Is this 25,000 byte file infected with the 1701 virus? Well, let's try infecting every possible file of 24,999 bytes or less with the 1701, and see if any of the results match!"). Now in practice, of course, all the viruses that we know of are absolutely isolable, in that it's easy to write a program to answer "is this given file infected with this given virus?". I admit that I *don't* understand Adelman's proof that some viruses aren't absolutely isolable. Is there anyone out there who does understand it? I don't understand what his example of a non-abs-isol virus would be like. (Of course, if the answer would help a virus-writer do something nasty, I'd appreciate an answer offline instead of here!). >that checksum( pi ) = checksum( pj ) for some >programs pi and pj of a length greater than the checksum >isn't this a fundamental weakness in the checksumming concept. Whenever a checksum is shorter than the objects being checked, the pigeonhole principle ensures us that there will be at least two objects with the same checksum. In practice that's OK, though, as long as the checksum is calculated in such a way that it's vanishingly unlikely (even given an intelligent attacker) that an infected object will have the same checksum as the original. That's not hard to do; Radai has a good paper or two on the subject. - - -- - David M. Chess | "I been ionized, High Integrity Computing Lab | but I'm OK now." IBM Watson Research | - Buckaroo Bonzai ------------------------------ Date: 17 Jun 92 07:58:39 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Teoretical questions BAN@hdc.hha.dk (Homo homini lupus!) writes: > 1) Having read some of F. Cohens work, I've seen many references to > a POset. What is a POset? I guess Dr. Cohen can answer this better, but nevertheless here it goes. "POset" means "partially ordered set". It is first defined in Cohen F., Protection and Administration of Information Networks under Partial Orderings, Computers & Security, 6 (1987), pp. 118-128. A good explanation of the POsets can be found also in Cohen F., A Short Course on Computer Viruses, ASP Press, 1990, ISBN 1-878109-01-4. and in Cohen F., A DOS-Based POset Implementation, Computers & Security, 10 (1991), pp. 541-551. The basic idea is to limit sharing of information in a computer system (between users/nodes/accounts/etc.). As Cohen has proven in his Ph.D. thesis, the only way you can stop computer viruses is to limit either sharing, or transitivity, or functionality. The POset idea consists of "ordering" the different domains in a computer system in such a way that only some subsets of them can share information and the information flow follows a limited number of predictable paths. This way a virus can spread only to a limited part of your computer system (because the different POsets are isolated) and you can determine where it came from (because you know the paths of the information flow). > 2) L. Adleman present a theorem (Theorem 3, p.366; Leonard Adleman: "An > abstract theory of computer viruses", Lecture notes in Computer > Science, vol.403, Springer 1990, pp. 354-374) stating: > ... if for all i in N, v(i)>=i then v is absolutely isolable. > Can those of you, who have read Adlemans note explain to me, what is > meant by ">=". Does it mean that one can detect every virus which does I have read Adleman's paper. Several times. Carefully. Shame on me, I still fail to understand it... :-( I probably lack the appropriate mathematical background - all those Goedel numberings, partially recursive functions, etc. BTW, Theorem 3 does not speak about detection, it speaks about isolation. > not shrink the infected program? And in what dimension is it to be > measured? Cohens compressionvirus example make a program smaller in > space, but as Cohen notes himself, it is a trade off between time and > space, meaning that it will be larger on the runtime dimension. Can one Not necessarily. On a computer with a slow disk and a fast CPU, a compressed file will load faster than a non-compressed one - due to the reduced amount of (slow) disk access. > 3) Cohen notes a weakness in his defense model S3 (p. 155; Fred Cohen: > "Models of Practical Defences Against Computer Viruses", Computers & > Security, vol.8, no.2, s.149-160, 1989 ) - S3 is based on a checksum > approch, which means that checksum( pi ) = checksum( pj ) for some > programs pi and pj of a length greater than the checksum [my inter- > pretation]. Relating that to the fact that most intregity checkers > today is checksum based, and to the discussion considering MtE and > 100% detection, isn't this a fundamental weakness in the checksumming > concept. Theoretically - yes. Since any checksum maps a (large) file into a limited (and small) number of bits, this means that it is possible to have two different files with the same checksums. The probability that this can occur is quite low - if you use a 32-byte checksum, then only two of 2^32 (=4,294,967,295) files are likely to have the same checksum. Most computer systems have much fewer files... :-) However, we are speaking about malicious modification, not about random noise, so using a probabilistic model is not very appropriate. If the checksum used is simple (add-bytes-together, or CRC) and can be easily reversed, a virus which knows it could reverse it and after infecting the file add a few more bytes in order to make the checksum of the new file be the same as of the old one. By "reversing the checksum" I mean "compute the contents of these few bytes". With CRC it is quite easy. There are two solutions to this problem. The first is to use a cryptographically strong algorithm to compute checksums - something like DES, MD4, MD5, Snerfu, etc. (DES is generally an encryption algorithm, but you can use it to compute checksums - just encrypt the file in CBC mode and use the last few bytes as a checksum.) MD4 and MD5 generate a 128-byte checksum. It is algorithmically difficult (meaning unfeasable in practical time) to reverse those algorithms. At least nobody knows how to reverse them. (If you discover how to reverse them, don't tell me. Tell CIA. How to contact CIA? Just pick up the phone and talk. ) Unfortunately, the cryptographically strong algorithms tend to be too slow to be used in practice. (I have heard the Fred Cohen has some ideas of a relatively fast cryptographically strong algorithm, but have no more information. Maybe he can comment?) The second solution is to use a weak algorithm to compute the checksums (e.g., CRC), but to implement it in a different way on the different machines, so that the exact implementation is not stable and the virus has no way to find out how exactly the checksum is computed. In the case of CRC this means to use a different polynomial with each new installation of the checksumming software. As has been shown by Yisrael Radai, this is secure enough for practical applications. One last remark - the MtE and all its mutations have nothing to do with checksumming. Any good integrity checker is able to find any MtE-based virus without any problems. The MtE is an attack against the scanners, not against the integrity checkers. > 4) When using MtE to exploid the "not 100% detection weakness" of > scan- ners, it would seem worthwhile to give one own mutation a higher > proba- bility. This means, that if five programs survive the scanning > in the first round, and each make say three times more copies of it > self than of other permutation, it will mean approx. 20 will survive > round two. This is exponential growth rather than as before linear > growth (of course this will not increase the chance of survival in a > checksumbased check). Exactly. That's why anything but 100 % detection of a polymorphic virus means no detection at all. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN ** PGP public key available by finger. ** Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: Tue, 16 Jun 92 08:09:05 -0500 From: perry@eugene.gal.utexas.edu (John Perry) Subject: New files on eugene (PC) Hello Everyone! FP-204.ZIP has been posted for anonymous ftp on eugene.gal.utexas.edu (129.109.9.21). If you have any probems or questions, please send email to perry@eugene.gal.utexas.edu. - -- John Perry - perry@eugene.gal.utexas.edu ------------------------------ Date: Mon, 22 Jun 92 13:54:10 -0500 From: perry@eugene.utmb.edu (John Perry) Subject: Eugene has a new name!! (PC,Mac,etc.) Hello Everyone! For those of you that have been using eugene.gal.utexas.edu for anti-virus support, there has been a slight change in procedure. Eugene has a new domain name. In the future, please use the address eugene.utmb.edu for anonymous FTP access rather than eugene.gal.utexas.edu. The old name will be supported for a period of one year but will cause extra network overhead due to additional lookups. If you have any problems or questions, contact perry@eugene.utmb.edu. Thanks! - -- John Perry - perry@eugene.utmb.edu ------------------------------ End of VIRUS-L Digest [Volume 5 Issue 118] ****************************************** rst5-YKCsng t5-YKCsng t5-YKCsng t5-YKCsng t5-YKCsng t5-YKCsng t5-YKCsng t5-YKCsng t5-YKCsng t5-YKCsng t5-YKCsng t5-YKCsng t Downloaded From P-80 International Information Systems 304-744-2253