From: Kenneth R. van Wyk (The Moderator) Errors-To: krvw@CERT.SEI.CMU.EDU To: VIRUS-L@IBM1.CC.LEHIGH.EDU Path: cert.sei.cmu.edu!krvw Subject: VIRUS-L Digest V5 #24 Reply-To: VIRUS-L@IBM1.CC.LEHIGH.EDU -------- VIRUS-L Digest Thursday, 6 Feb 1992 Volume 5 : Issue 24 Today's Topics: CERT Advisory - Michelangelo PC Virus Warning (PC) DAV/Sourcer/Rape (PC) What virus creates SD.INI? (PC) Memory Discrepancies (PC) Windows Scanner? (PC) Michaelangelo (PC) LZ virus found by McAffee NETSCAN and CLEANUP but not SCAN? (PC) WARNING: Data-diddler Empire variant found in USA (PC) More Michelangelo infected Disks (PC) Amiga Virus History wanted. (Amiga) Virus-Paper (It will be in german !) Re: "Polymorphic" viruses Re: Iraqi Virus Question? Re: Cohen's error 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. Administrative mail (comments, suggestions, and so forth) should be sent to me at: krvw@CERT.SEI.CMU.EDU. Ken van Wyk ---------------------------------------------------------------------- Date: Thu, 06 Feb 92 16:32:35 -0500 From: Kenneth R. van Wyk Subject: CERT Advisory - Michelangelo PC Virus Warning (PC) =========================================================================== CA-92:02 CERT Advisory February 6, 1992 Michelangelo PC Virus Warning - --------------------------------------------------------------------------- The Computer Emergency Response Team/Coordination Center (CERT/CC) has received information concerning a personal computer virus known as Michelangelo. The virus affects IBM PCs and compatibles. A description of the virus, along with suggested countermeasures, is presented below. - --------------------------------------------------------------------------- I. Description The Michelangelo virus is a computer virus that affects PCs running MS-DOS (and PC-DOS, DR-DOS, etc.) versions 2.xx and higher. Note, however, that although the virus can only execute on PCs running these versions of DOS, it can infect and damage PC hard disks containing other PC operating systems including UNIX, OS/2, and Novell. Thus, booting an infected DOS floppy disk on a PC that has, for example, UNIX on the hard disk would infect the hard disk and would probably prevent the UNIX disk from booting. The virus infects floppy disk boot sectors and hard disk master boot records (MBRs). When the user boots from an infected floppy disk, the virus installs itself in memory and infects the partition table of the first hard disk (if found). Once the virus is installed, it will infect any floppy disk that the user accesses. Some possible, though not conclusive, symptoms of the Michelangelo virus include a reduction in free/total memory by 2048 bytes, and some floppy disks that become unusable or display "odd" graphic characters during "DIR" commands. Additionally, integrity management products should report that the MBR has been altered. Note that the Michelangelo virus does not display any messages on the PC screen at any time. II. Impact The Michelangelo virus triggers on any March 6. On that date, the virus overwrites critical system data, including boot and file allocation table (FAT) records, on the boot disk (floppy or hard), rendering the disk unusable. Recovering user data from a disk damaged by the Michelangelo virus will be very difficult. III. Solution Many versions of anti-virus software released after approximately October 1991 will detect and/or remove the Michelangelo virus. This includes numerous commercial, shareware, and freeware software packages. Since this virus was first detected around the middle of 1991 (after March 6, 1991), it is crucial to use current versions of these products, particularly those products that search systems for known viruses. The CERT/CC has not formally reviewed, evaluated, or endorsed any of the anti-virus products. While some older anti-virus products may detect this virus, the CERT/CC strongly suggests that sites verify with their anti-virus product vendors that their product will detect and eradicate the Michelangelo virus. The CERT/CC advises that all sites test for the presence of this virus before March 6, which is the trigger date. If an infection is discovered, it is essential that the user examine all floppy disks that may have come in contact with an infected machine. As always, the CERT/CC strongly urges all sites to maintain good backup procedures. - --------------------------------------------------------------------------- The CERT/CC wishes to thank for their assistance: Mr. Christoph Fischer of the Micro-BIT Virus Center (Germany), Dr. Klaus Brunnstein of the Virus Test Center (Germany), Mr. A. Padgett Peterson, P.E., of the Technical Computing Center at Martin-Marietta Corp., and Mr. Steve R. White of IBM's Thomas J. Watson Research Center. - --------------------------------------------------------------------------- If you believe that your system has been compromised, contact CERT/CC or your representative in FIRST (Forum of Incident Response and Security Teams). Internet E-mail: cert@cert.sei.cmu.edu Telephone: 412-268-7090 (24-hour hotline) CERT/CC personnel answer 7:30 a.m.-6:00 p.m. EST(GMT-5)/EDT(GMT-4), on call for emergencies during other hours. Computer Emergency Response Team/Coordination Center (CERT/CC) Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 Past advisories, information about FIRST representatives, and other information related to computer security are available for anonymous ftp from cert.sei.cmu.edu (192.88.209.5). ------------------------------ Date: Tue, 04 Feb 92 21:36:00 -0500 From: Subject: DAV/Sourcer/Rape (PC) Got a few questions for everyone... First, has anyone heard about Dark Avenger's latest? I got a report secondhand last week that he'd come up with a new gem...I believe the report came from a researcher in the UK. Fridrik/Vesselin/others, can you confirm/deny this report? Next, for those using the Sourcer disassembler...why does it sometimes produce machine code output, while other times it produces assembly output? Is there something I'm missing in the manual (probable something obvious :) )? Finally, have others had reports of increasing numbers of RAPE infections? I've noted quite a few in the last month or so...has anyone else had similar experience? Charles *************************************************************************** RUTSTEIN@HWS.BITNET (Charles Rutstein) "Hackers Do It All Night" *************************************************************************** ------------------------------ Date: 05 Feb 92 17:15:43 +0000 From: riddle@mathcs.emory.edu (Larry Riddle) Subject: What virus creates SD.INI? (PC) Is there a PC virus that creates a hidden file called SD.INI in the root directory? If so, which of the detection programs will find it? Any help or information would be appreciated. - -- Larry Riddle | riddle@mathcs.emory.edu PREFERREDD Agnes Scott College | {rutgers,gatech}!emory!riddle UUCP Dept of Math | riddle@emory.bitnet NON-DOMAIN BITNET Decatur, GA 30030 | (404) 371-6222 AT&T ------------------------------ Date: Wed, 05 Feb 92 16:32:36 -0500 From: padgett%tccslr.dnet@mmc.com (A. Padgett Peterson) Subject: Memory Discrepancies (PC) >From: cowan@aqua.pc.ocunix.on.ca (Darin Cowan) >I don't know what the discrepancy is, but I went looking around with >Quarterdeck's Manifest, and QEMM because I found the same thing. In >my system, the addresses 9FFE and 9FFF are taken up by something. >QEMM reports they are unused, but the whole 1K block cannot be mapped >because something wants them. This has always been this way and I am >certain there are no viruses on my machine. Well, I always like to know what is using memory though there is a mechanism for a program to use upper memory (just below segment A000). What is being reported here sounds like 20h (32d) bytes right up at the top. Now since DOS 5.0 came out I have noticed some small discrepancies in the way memory is reported (usually 10h-16d bytes) & had to "fix" my CHKMEM so that it would not trigger (I use memory mismatches to find a number of viruses such as the 4096 and Whale). Usually it existes when DOS HIMEM.SYS and EMM386.EXE are in use though I have noticed the same mismatch with QEMM386 6.02. For this reason I say that it is important to know what the "clean" memory looks like since the "infected" state will be less for most memory-resident infections. If you have to ask, 640k = 655360 bytes though any number of legitemate systems will return less (and a very few, more). Damply (rain today), Padgett padgett%tccslr.dnet@mmc.com BTW - interesting bulletin on CNN last night, was amazed to discover that the Michelangelo displays the message "The world will see me again" (thought that was the Fu Manchu) and that "millions" of PCs are infected. Must be right since when I called to comment, I was told that "their expert said so" 8*). ------------------------------ Date: Mon, 03 Feb 92 11:33:26 -0600 From: THE GAR Subject: Windows Scanner? (PC) Can anyone tell me how memory resident Virus scanners (like McAfee's VSHIELD) behave in a Windows environment? If I am in Windows and invoke an infected program will VSHIELD stop it? What about booting a boot sector infected disk? Thanks for any information. Gary Warner Samford Universtiy Computer Services ------------------------------ Date: Mon, 03 Feb 92 13:38:03 -0600 From: THE GAR Subject: Michaelangelo (PC) I have never tried to do something like this before, but I am interested in learning more about the spread pattern of the Michaelangelo virus. If you have been infected, or know someone who has, or if you have access to reports regarding same, please send me private e-mail. If you request confidentiality, it will go no further. Please include: Date of Infection (if known) Source of Infection (if known) Date of Discovery Method of Discovery Also, I would be interested in hearing of any media reports regarding this virus. I know that National Public Radio has mentioned it, and it seems like I heard about a story in one of the major Business dailies. (Wall Street????) Thanks. I will summarize to the list (keeping confidences where requested). Gary Warner Samford University Computer Services ------------------------------ Date: Wed, 05 Feb 92 21:31:24 -0600 From: "lucius chiaraviglio" Subject: LZ virus found by McAffee NETSCAN and CLEANUP but not SCAN? (PC) We are testing the McAffee package in our lab and found what NETSCAN and CLEANUP say is a virus named LZ but which SCAN does not detect; no such virus is listed in VIRLIST. The file is a version of the mouse sensitivity control panel from Microsoft (via a disk copy -- NOT Microsoft's fault) dating from 1987 or 1988. It was installed on one of our hard disks a few months ago and used a few times, and the virus does not seem to have spread to anything else. Does anyone know whether this is a real virus, and if so, should I send a sample to McAffee Associates, or is this one familiar and just didn't make it into VIRLIST? | Lucius Chiaraviglio | Internet: chi9@midway.uchicago.edu ------------------------------ Date: Wed, 05 Feb 92 11:14:05 -0700 From: martin@cs.ualberta.ca (Tim Martin; FSO; Soil Sciences) Subject: WARNING: Data-diddler Empire variant found in USA (PC) A malicious variant of the Empire virus was found at a government office in Washington DC. The unconfirmed suspicion is that it came from a data management center in Amhurst NY, that services hospitals, in particular. This is the first confirmed identification of the Empire virus outside of Canada. If it was distributed by the Amhurst center, then we can assume the virus has a broad, probably world-wide distribution by now, at medical centers in particular. This variant, called Empire B.2, or "UofA", is one of three known variants that contain a "data diddler" routine. On any write to a floppy disk, the virus may (randomly) decide to alter one or more bytes being written, to a new (random) value. This is especially a concern in the hospital context, where randomly introduced database errors or software bugs might be life threatening. The Empire virus is a MBR and floppy boot sector infector, derived from Stoned. This variant of the Empire virus does not announce its existence in any way. The only observable symptoms are that it uses 1k of memory from "top of memory", and that it tends to not work with 720k diskettes: they appear "unreadable" because DOS thinks they are 1.2Mb diskettes. (Of course such diskettes can be recovered, by repairing the boot sector: Padgett Peterson's FIXFBR is recommended for this.) This variant does not use stealth. It can be detected using several virus scanners, including the recent versions of McAfee's SCAN and Fridrik Skulason's F-PROT. Padgett's FIXUTILS should work well for detection and recovery as well. Tim. ------------------------------------------------------------- Tim Martin * Soil Science * These opinions are my own: University of Alberta * My employer has none! martin@cs.ualberta.ca * ------------------------------------------------------------- ------------------------------ Date: Thu, 06 Feb 92 13:03:14 -0500 From: TMIS1862%Vega@SLU.BITNET Subject: More Michelangelo infected Disks (PC) Just got this in. It would appear that Michelangelo might very well be Virus-of-the-Year. Or at least a strong contender. Andrew. - ----------------------------Original message---------------------------- Hello netters, Our university just purchased some (noname brand) modems that came with some software called BitCom. They've installed this software all over campus; before my department put out the "virus alert". All of their computers have been infected and the culprit has been found to be the BitCom disks. We unpackaged an unopened copy and scanned it to be sure. These disks are coming direct from the manufacturer with the Michelangelo virus on-board. I have also heard of disks from Zylel being infected. If you know of anyone who is using BitCom (I've never heard of it until now), let them know before March 6 or their hard drives will be trashed. Don't trust ANY disks - scan them first!! If you need the ftp site for some virus protection software, let me know and I'll look it up for you. - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Daryl Spillman | Bitnet: TMIS1862@SLU.BITNET MIS Programmer | Snail Mail: Box 409 - SLU Station Southeastern Louisiana Univ. | Hammond, LA 70402 (504) 549-3645 | - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ------------------------------ Date: 05 Feb 92 17:51:33 +0000 From: twells@rigel.cs.pdx.edu (Tabor J. Wells) Subject: Amiga Virus History wanted. (Amiga) I'm looking for something of a history of virii on the Amiga. I would prefer some kind of technical info on what each virus does, specific means of infection. Which system pointers it appropriates, etc. I also understand that there is a anonymous ftp site in europe somewhere that has alot of this technical info on it. Could someone email me this addr and possibly tell me how to find a somewhat chronological history of these virii? Thanks much. Tabor Wells twells@rigel.cs.pdx.edu - ------------------------------------------------------------------------------- |Tabor Wells twells@rigel.cs.pdx.edu| "All those memories are lost now. | | #include | Like tears in the rain. Time to die."| - ------------------------------------------------------------------------------- ------------------------------ Date: Wed, 05 Feb 92 19:27:03 -0500 From: Uwe Hauck Subject: Virus-Paper (It will be in german !) Sorry, but I forgot to mention, that this paper will be written for a audience of german people... So, the first release will be in german in fact. But anyway, if it is possible for me, i will try to do a translation of the whole thing in english. Another point: The paper will be available via anonymous ftp when it is finished (I am hoping to do it in the next two or three month (I know, that this sounds quit optimistic (-: ), so the first preprint will be available around May or June.... Uwe Hauck UWEHAUCK AT DOSUNI1.BITNET UWEHAUCK AT DOSUNI1.RZ.UNI-OSNABRUECK.DE ------------------------------ Date: 05 Feb 92 23:32:10 +0000 From: vail@tegra.com (Johnathan Vail) Subject: Re: "Polymorphic" viruses AMN@vms.brighton.ac.uk (Anthony Naggs) writes: POLYMORPHIC is a term that I have been using about viruses for about a year, however I use it in a different way. Polymorphic means havingg mulitple forms, so I have used the word to describe viruses which infect different types of host or change their mode of operation. Specifically I have applied the word to viruses which infect BOOT sectors and program files (COM or EXE), or system files (eg .SYS). These are clearly different forms and this behaviour requires a simple concise description. Regarding MS-DOS type systems I would even apply the word to viruses which infect .COM & .EXE files in a different manner, as COM and EXE files are so different in internal format. For "Viruses using variable encryption with a variable decryption routine" I would suggest the word "variable". Polymorphic seems inappropriate as the form is still the same: the same functions are executed and there is no difference in observable behaviour - it is not important to someone who is infected. It is only the superficial appearance that has changed, and even that is relatively minor; loading the decryption key and executing the processing loop are clearly visible with DEBUG and with some simple programming techniques automatic recognition is straightforward. The difference in the virus is only important for those of us involved in the development of virus search and identification software. I added your definition to the first one in my glossary, thus: ________________ polymorphic virus - 1. A virus using variable encryption with a variable decryption routine to avoid detection by its "signature". V2P6, Whale, Maltese, Amoeba, Russian Mutant and PC-Flu 2 are examples. 2. Any virus that changes it's behaviour such as infect different types of host or change their mode of operation. A virus that infects both .COM and .EXE programs as well as boot sectors can be considered polymorphic. ________________ I don't intend to dictate nomenclature to anyone nor is this intended as a flame. However I feel quite strongly that nomenclature should be carefully considered, not least because if the sand changes under my feet I shall have to change a lot of text sitting on my harddisk! I agree with you and your reasoning makes sense. What do other people think? (email and I will summarize) jv "Like a clock, they sent, through, a washing machine: come around, make it soon, so alone." -- Syd Barrett _____ | | Johnathan Vail vail@tegra.com (508) 663-7435 |Tegra| jv@n1dxg.ampr.org N1DXG@448.625-(WorldNet) ----- MEMBER: League for Programming Freedom (league@prep.ai.mit.edu) ------------------------------ Date: Wed, 05 Feb 92 18:41:00 +0000 From: Bald Oldie Subject: Re: Iraqi Virus Question? DAVID@SIMSC.BITNET (David Bridge) writes: > from "The Washington Post" Washington, DC USA > Tuesday, January 14, 1992. Page A7. > > COMPUTER VIRUS REPORT IS SIMILAR TO SPOOF > Magazine Rechecking Story That U.S. Disabled Iraqi Network > Associated Press > [body text deleted] > > ===================================================================== > from "The Washington Post" Washington, DC USA > Saturday, January 18, 1992. Page A4. > > COMPUTER VIRUS STORY DEFENDED > Associated Press > [body text deleted] I had a chat with an engineer friend who seems knowledgeable about these things, and he suggested that IF the printer connection was RS232 rather than Centronics and IF the cable was configured appropriately and IF the printer had been engineered to behave briefly as an RS232 terminal (rather than simply having a PROM replaced) THEN it was just conceivable that control of the host processor could be siezed long enough to transfer one or more viruses without the change in behaviour being noticed. This suggestion was also predicated upon the identification beforehand of the processor type (in order that an appropriately-coded virus would stand a chance of operating). I'm no expert, so all I can do is throw this in for discussion/demolition. +--------------------------------------+---------------------------------------+ | Peter G. Q. Brooks HSR4@OX.VAX.AC.UK | Kokoo koko kokko kokoon! | | Health Services Research Unit | Koko kokkoko ? | | Dept of Public Health & Primary Care | Koko kokko. | | University of Oxford | Marjukka Grover, The Guardian | +--------------------------------------+---------------------------------------+ ------------------------------ Date: Wed, 05 Feb 92 16:25:00 +0200 From: Y. Radai Subject: Re: Cohen's error Vesselin Bontchev has demonstrated an error in Cohen's original proof of undecidability of whether a given program is a virus, based on a two-sentence remark in a paper by Steinparz. Since Vesselin has not quoted that remark, I have no idea what Steinparz's paper itself says. In any case, Vesselin's explanation is based on analogy between Cohen's proof and the well-known proof of the undecidability of the halting problem. While there is very little in Vesselin's posting with which I would disagree, I would like to point out that if all we are concerned with is demonstrating Cohen's error, this can be done without any reference whatsoever to the halting problem, as I shall now demonstrate: Definition (Cohen): A virus is a program which infects other pro- grams by modifying them to include a (possibly evolved) copy of itself. (The following definition, theorem and proof are my *paraphrase* of what Cohen has written in [1, p. 28].) Definition: An IVD (Infallible Virus Detector) is a function which inputs a (program) file p and which always terminates (in finite time), outputting a boolean value, 'true' whenever p is a virus, 'false' whenever it is not, without any errors. Theorem: There cannot exist an IVD which works by merely examining the appearance of the file p. (Cohen later extended this to detection based on the *behavior* of the program contained in p, but this is irrelevant to the present discussion.) Cohen's informal proof: Suppose there were an IVD, say D. Then let P be a program consisting of only the following code: If not D(P) then infect (It is assumed that "infect" is either the name of a subroutine or is an abbreviation of in-line code which copies P to some other file, and that D is callable by P.) Now (1) if D(P) = true, then P does nothing, so P is not a virus, so D has erred. (2) If D(P) = false, then P infects, i.e. P is a virus, so again D has erred. In either case, D is fallible, contradicting the supposition. Claim: The above proof is erroneous. Justification: There is nothing in the theorem as stated above which excludes the possibility that D might, in certain circumstances, copy the file given to it as parameter, and then return 'true'. In this case, Part (1) of Cohen's proof is invalid: the fact that P does nothing other than call D does not guarantee that P is not a virus; it may be a virus by virtue of calling D, which may have copied P. And in this case D will not have erred. We have thus come to the same conclusion as Vesselin's posting with- out mentioning the halting problem at all. Remark: As Vesselin mentioned, Cohen *does* take this into account in his *formal* proof in [3]. (In fact, Cohen also mentions there the possibility of D overwriting code in P.) So whether the above was really an *error* on Cohen's part depends on when he became aware of these things; was it only in 1989? Or perhaps it was much earlier but he omitted mentioning them in his informal proof merely for purposes of simplicity. Also, it's not clear to me what originality (if any) there is in Steinparz's paper, given the fact that Cohen was aware of the "error" no later than 1989. Can Cohen's proof be salvaged? I know of no way of doing this as long as no restrictions are placed on D. But again paraphrasing Cohen (this time from his formal proof [3, p. 341]), if D is restricted to be a "passive" procedure, i.e. one which does not write onto a file (or anywhere else outside of its own data area in memory), then the demonstration that Cohen's informal proof is invalid would fail. And this restriction on D is a perfectly natural one. If someone claims that he has written an infallible virus detector, we would hardly consider it fair if it worked by self-fulfilling prophecy! Speaking of naturalness, it seems to me that the most natural way for a virus detector to be implemented would be as an independent main program executed from the command line. Yet, at least in Vesse- lin's schema, D is an *internal* procedure *embedded within* P. This seems rather unnatural to me, but, as David Chess has pointed out in personal correspondence, this is necessary for Cohen's proof to work; otherwise, if S1 is the operating system in which programs which are to be checked for viruses are run, then D might be written so as to run in some other system S2. The programs would be transferred to S2 for checking, where they would be unable to call D. David also points out that even in the same system, such a D could be stored encrypted so that it could be run only if a certain password is entered. Not knowing the password, no virus or program such as P could execute D, so Cohen's proof wouldn't go through. I will now show how Cohen's conclusion can be obtained without going through his contradiction-based proof at all. Note first that Part (1) of his proof makes sense only if a virus is assumed to be a pro- gram which *actually* infects in *some (or all) cases*, as opposed to one which merely *contains* viral code. The difference is important if the infection mechanism appears only within a statement of the form if (condition) then infect The 'infect' routine might never get executed because it depends on satisfaction of some run-time condition which might never be actually satisfied, in which case p would not be a virus, according to Cohen. Note also that Cohen explicitly states that D is to detect virality of its input file p by the latter's *appearance* alone. But if execution of the viral code in a program depends on a condition which can be tested only at *run time*, then it is *trivially obvious without need for Cohen's proof* that such detection cannot be made by *appearance* of p alone, i.e., such an IVD is impossible (assuming D is "passive"). Aside from its much greater conceptual simplicity, this proof has at least two advantages over Cohen's: (1) It applies just as much when D is an independent main program as when it is an embedded function (without failing because D is run on a different system or requires a password); (2) it applies just as much to real computers as to Turing machines. >I thought that the finite number of memory cells in the real computers >implies that they are in fact finite automata. However, as Yisrael Radai >has pointed to me in our private correspondence, if we have a >civilization, which generates programs and supplies it to a computer >with a finite number of memory cells, you still can get a computer with >infinite number of programs... The question turned out to be of >philosophycal matter. More precisely, if intelligent beings exist arbitrarily long, they can supply programs of arbitrary length, and even though memory in a real computer is finite, any such program can be continually read into memory as a series of overlays. >I consulted a specialist in computational theory and here is what I was >told. It seems that there are three kinds of infinity. ..... >The second kind of infinity is e.g. a class, which has an infinite >number of elements, but for which you have a determined rule or set of >rules how to obtain the next element. A typical example is the class of >natural numbers. There is infinite number of natural numbers, but you >can always obtain the next element. It seems that the computer with >finite munber of memory cells, combined with a civilization, which >produces programs is an infinite computer of this class. > >And, at last, there is the infinity in the mathematical sense. I don't understand the distinction you are making between these two kinds. Are you saying that the second kind *isn't* infinity in the mathematical sense? Perhaps the difference between your second and third kinds consists in distinguishing between denumerable and non-denumerable infinities, or between cardinal and ordinal numbers, but the second kind is certainly a mathematical one. >References: > >1. F. Cohen, "Computer Viruses - Theory and Experiments", Computers & >Security, 6 (1987), pp. 22-35. ..... >3. F. Cohen, "Computational Aspects of Computer Viruses", Computers & >Security, 8 (1989), pp. 325-344. Y. Radai Hebrew Univ. of Jerusalem, Israel RADAI@HUJIVMS.BITNET RADAI@VMS.HUJI.AC.IL ------------------------------ End of VIRUS-L Digest [Volume 5 Issue 24] *****************************************