Return-Path: Received: from IBM1.CC.Lehigh.EDU by abacus.HGS.SE (SunOS 4.1/SMI-4.1-01) with sendmail 4.1/SMI-4.1-01 id AA14109; Sat, 30 May 92 18:56:59 +0200 Message-Id: <9205301656.AA14109@abacus.HGS.SE> Received: from LEHIIBM1.BITNET by IBM1.CC.Lehigh.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 8824; Sat, 30 May 92 12:44:53 EDT Received: from LEHIIBM1.BITNET by LEHIIBM1.BITNET (Mailer R2.08) with BSMTP id 1461; Sat, 30 May 92 12:44:27 EDT Date: Sat, 30 May 1992 12:42:41 EDT Reply-To: VIRUS-L@IBM1.CC.LEHIGH.EDU Sender: Virus Discussion List Comments: Warning -- original Sender: tag was krvw@CERT.ORG From: "The Moderator Kenneth R. van Wyk" Subject: VIRUS-L Digest V5 #110 Comments: To: VIRUS-L@ibm1.cc.lehigh.edu To: Multiple recipients of list VIRUS-L Status: RO VIRUS-L Digest Saturday, 30 May 1992 Volume 5 : Issue 110 Today's Topics: Stoned Variant (PC) help me .. is this a virus? (PC) Re: Question about Dark Avenger (PC) New strain of Jerusalem (fwd) (PC) Re: Virus? Vlad The Inhaler (PC) Re: Clarifications... part 3 (PC) re: PC\MS DOS based Viruses & OS\2 2.0 (PC) (OS/2) Virus Program for a Macintosh? (Mac) Re: Can a virus survive being pkzipped or otherwise compressed? Re: Taxonomy of viruses what's this .signature stuff? Re: Taxonomy of viruses Re: BAD IDEA (was: Where can I find Virus signatures) Virus hides in printer (again) & Virus In Printers Flopticals Article about "Starship" virus available (PC) New Files on Eugene (PC) Earliest computer viral history (CVP) 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: Fri, 22 May 92 09:17:00 -0400 From: Ron Whittle Subject: Stoned Variant (PC) I received the virus that Genaldo (mtm1gln@brufsc.bitnet) claimed to infect upon a DIR command (He has since retracted this claim, and several people pointed out where he was wrong). It is the same as a Stoned variant that I currently have (VSUM says it is either B or E, has characteristics of both, but is most likely the E). The only difference between the two Stoned variants is the byte at offset 3E which was 56 and now is 57. The message has been changed to "^Hidden Virus, FuckYou!^" where ^ is the bell character. Ron Whittle Computer | cscrdw%curie@epavax.rtpnc.epa.gov | My employer disavows all Sciences | PGP 1.0 public key available | knowledge. All opinions Corporation | VOICE : 205-270-3482 | are mine. Some should be working for | FAX : 205-270-3454 | yours. National Air and Radiation Environmental Laboratory (EPA/NAREL) ------------------------------ Date: Fri, 22 May 92 15:53:21 +0000 From: jjz34245@uxa.cso.uiuc.edu (Wendell Gee) Subject: help me .. is this a virus? (PC) I boot up the machine and it appears to run fine through the boot up until I type in a command and hit return. It doesnt matter what the command is. Every time it does this: B: A: A:cd\ A:win and then it runs windows. While windows is booting up, a long bell that never used to be there is sounding. Windows is pretty useless after that. The buttons do not work right, and nothing If windows is not in the boot up drive, it does this A> A> A>cd\ A>win bad command or file name A>B: B:nw the "nw" appears very slowly. I have never seen a virus before, but Im sure this looks like one. Please let me know how to get rid of it... which programs will find it, etc... Thanks, - -Zim ------------------------------ Date: Fri, 22 May 92 18:01:33 +0000 From: BONDIR@vaxb.gbus.virginia.edu Subject: Re: Question about Dark Avenger (PC) >> don't understand is this: surely the executable, self-extracting part >> of the program must be invariable - it can't be encrypted, because >> obviously it couldn't execute while encrypted. So why aren't such >It's true that this part cannot be encrypted, but it is not true that >it must be invariable. In fact, it varies very heavily - it is very >different with each new infected file. This is what I don't understand. How can it vary? It does the same job every time it runs: it decrypts. It may use a different decryption key each time, but then it should just run through the same steps with a different encryption key. But if it does the same job every time, how can its code possible vary? I can imagine a human writing many completely different source codes that all accomplish exactly the same task, but not a program that can produce many completely different programs that all do the same thing. The response from the UK to my original question here seemed to imply that "filler" is added between the segments of code that do the work, i.e. segments of dummy code that vary every time. But then the actual code still stays the same, and can be scanned for. In short: how are polymorphic viruses possible? I just don't understand!! Thank you all for your responses. Yours curiously and baffled, R. Bondi Thank you very much for your comments and those of the writer from the UK. ------------------------------ Date: Fri, 22 May 92 13:55:00 -0400 From: HAYES@urvax.urich.edu Subject: New strain of Jerusalem (fwd) (PC) Hi. The following post was forwarded to me by our site manager, John Lundin Jr. Best to all, Claude. - ---- begin forwarded msg -- Newsgroups: alt.fractals From: kkkg3408@uxa.cso.uiuc.edu (Dixie Flatline ) Subject: Fractint & Viruses Message-ID: <1992May21.022903.24846@news.cso.uiuc.edu> Sender: usenet@news.cso.uiuc.edu (Net Noise owner) Organization: University of Illinois at Urbana Date: Thu, 21 May 1992 02:29:03 GMT There has been an attack at U. of Illinois by a new strain of the Jerusalem virus. It's rather sneaky- McAffee products do not detect it yet, and like other Jerusalem strains it doesn't seem to want to do much until a specific date. I first noticed it, though, through the use of Fractint! If you get a message that your copy of Fractint cannot locate overlay, run- don't walk- to your nearest ftp site and get F-prot version 2.03a. F-prot will detect and eradicate the virus. - ----- end forwarded msg -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Claude Bersano-Hayes HAYES @ URVAX (Vanilla BITNET) University of Richmond hayes@urvax.urich.edu (Bitnet or Internet) Richmond, VA 23173 ------------------------------ Date: Fri, 22 May 92 22:18:53 +0000 From: mcafee@netcom.com (McAfee Associates) Subject: Re: Virus? Vlad The Inhaler (PC) Hello Bob, The "Vlad the Inhaler" message is a background process of Norton Desktop for Window, Version 2.0, I believe. Apparently one of their programmers accidentally left a message in. Or something. Norton Tech Support should be able to confirm that for you. Their number is 1-310-319-2020. Regards, Aryeh Goretsky McAfee Associates Technical Support /original message follows/ mhuxo!rjg@att.att.com writes: >Has anyone heard of a PC Virus called Vlad The Inhaler? I received a >report from someone saying when they went to hot key between >applications in Windows, a message flashed on the screen >"VladTheInhaler". - -- - - - - McAfee Associates | Voice (408) 988-3832 | mcafee@netcom.com (business) 3350 Scott Blvd, Bldg 14 | FAX (408) 970-9727 | ObQuote: "Log... from Blammo" Santa Clara, California | | 95054-3107 USA | BBS (408) 988-4004 | CompuServe ID: 76702,1714 ViruScan/CleanUp/VShield | USR Courier DS 14.4Kb| or GO VIRUSFORUM ------------------------------ Date: 20 May 92 16:55:04 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Clarifications... part 3 (PC) > > I'm not considering the scanner at all, since as you have said, the > > strongest part is the integrity checker. (The scanner is certainly not > > better than any of the already existing good ones, so this comparison > Okay. INHO, the scanner part is reasonable. I admit, Frisk got a better > scanner. In fact, combining the best parts of several products is a good idea. For instance, I prefer to use Frisk's or Dr. Solomon's scanner before installing UT's integrity checker, and using Dr. Solomon's resident scanner, since the one supplied with UT is signifficantly worse and Frisk's had problems with DR-DOS 6.0 loaded high. > > does not hold too.) And the integrity checker is -weak-, at least when > > compared with other integrity checkers. And my point about > Weak based on what? Your perceptions, assumptions or test results? Based on my knowledge about the possible virus attacks against the integrity checking software. I'm currently writing a paper on this subject for the Virus Bulletin conference; as soon as it is published, I'll make it freely availabe. > DR DOS and non-DOS partitions are taken care of. Now - maybe; I have not checked. My comments were about the version of the program that was avaialble then. > Compressed disks will wait for a future release. An easy solution is not to use the anti-stealth techniques for drives which are device-driven, networked, SUBSTed or JOINed. Or at least provide the user an option to turn the tricks off for such drives. > In LAN environments, VDS integrity checker is > the best way to control virus entry points. It will not work on the > servers. Suspicious ability? You are underestimating its operation ;-) Obviously, you have not seen what the LAN version of the UT provides... :-) > > thing for a security program is to be secure and your package isn't. > Please let's provide some evidence, not just opinions, though they are I mentioned several times two kinds of attack that your program does not take care of. I mentioned a third kind of attack that no integrity checker stops. I offered to explain you privately what can be done to bypass the anti-stealth techniques. What more do you want? > >> Non-resident ones, well you know how common they are :-) > > Boy, I have been in the anti-virus field since the Vienna virus and I > > - -do- know how common it was! > You are missing the point. You claimed that non-resident viruses cannot be common. I demonstrated that you are wrong. Who is missing the point? > Decoys are meant to catch memory resident > viruses that attack upon file access. But they can be improved to catch more cases. I already explained how in one of my previous posts. > If we claim to catch non-resident viruses with decoys, that would be magic! If you claim, that would be foolishness. But if you try to do what can be done, it would be a reasonable thing that sometimes works, not magic. > > Device driver infectors, damn, how many of > > those do you have? > > So many, that I don't remember all of them already... Let's see: Happy > > New Year (3 variants), SVC (5.0a, 5.0b, and 6.0), Involuntary, > > certainly some others whose names I can't recall right now... > Your memory must be failing you lately :-) Again, irrelevant criteria. You asked how many device driver infectors I have. I listed seven. We have about 1,300 different viruses here, nobody can remember what each one of them does. Maybe the other researchers (Frisk? David? Alan?) can provide more examples. What is the irrelevant criterium? > >> StarShip actually infects! > > Note to you, Dave Chess, Fridrik Skulason, and everybody else: Yes, > > StarShip actually infects. > I really would like to see this. I had a similar report from Mike in > Virginia. He got it to infect on a 20M disk somehow. During our tests, > Starship simply goes to no-man's land. It is too paranoid. Or maybe it > makes wrong assumptions about the hard drive. I need to disassemble it one > of those days. Does the hard drive parameters really matter? Any info will > be appreciated, sir. It hates monochrome cards (get a CGA to be sure), funny computers (use a plain XT instead of a PS/half), modern DOSes (get PC-DOS 3.30, not 5.0), large disk partitions (make sure your bootable partition does not exceed 32 Mb), graphical applications (make sure your current video mode is 80x23 text), computers without a hard disk... Also, be sure to zero out the memory are addresses 0000:04B0 to 0000:04E0. > > Not always. The authors of UT claim that a really secure product must > > resist a direct attack even if the intruder has full access to the > > source code of the protection program. They also claim that UT is such > Yes, marketing. I can write similar things all too well. Unlike you, they seem to actually have the knowledge. They knew about the companion attacks and file fragemntation attacks since years and have implemented a way to disable them since the first versions of their product (V-Analyst). Which cannot be said about you. > > a program. Well, to be honest, there -is- a way to bypass UT. Even two > > ways, but the first requires that the virus is already present before > > the package is installed and that the scanner part of the package does > > not detect it (i.e., that it is a new virus). > Wait a minute. Are we talking about the integrity checker component or > the scanner of UT? Why does the integrity checker rely on a virus being > known? Didn't you say above even good virus scanners do the same? I > thought UT's claims are for the integrity checker portion. Please clarify. We are talking mainly about the integrity checker of the package. The scanner part in the version that I have is mostly crap. The attack that I mentioned relies on the virus being installed on the computer - -before- the integrity checker. Therefore, in order to prevent this attack, the installation part of the package must use the scanner and scan the disk. If it does not recognize the virus which is already present and uses the kind of attack that I mentioned, it will proceed with the installation of the package and therefore the virus will survive. After the installation, the virus will continue to spread undetected by the inegrity checker, because it (the virus) uses the kind of attack that I mentioned. Even the best integrity checker relies on being installed on a clean system. Therefore, it requires a good scanner at least once - before installation. Was I clear enough? > > SHELL= in CONFIG.SYS and SET COMSPEC= in AUTOEXEC.BAT? Or with letting > That's a possibility. It should be sufficient in most cases. Yup. UT even has a full parser for AUTOEXEC.BAT and CONFIG.SYS; that is it will detect such things as "call myauto.bat". This is needed not only to find the command interpretter, but also to collect the set of programs that are being executed at boot time. Unfortunately, my version of the package does not support DR-DOS, or more exactly its HILOAD, HIINSTALL, and CHAIN commands... :-( I was told that the next version supports them... > > the user to type in the path and the name of the command interpretter? > That was our initial approach; then we modified it not to confuse people. If the user is knowledgeable enough not to keep the comand interpretter in the root directory and knows how to achieve it, such question won't confuse it. > > Do you know how many people copy (or unarchive) their command > > interpretter to a RAM disk and run in from there for speed? > An old way to speed things up. Yes, even I used to use it. Now the PCs > are fast enough not to notice such speed differences. I agree that the Maybe, but a lot of people might have upgraded the hardware without bothering to change their software configuration... > assumption C:\COMMAND.COM is too restrictive. It should be default and then > installation should try to determine the actual one. Let me pass it on to Exactly! 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: 26 May 92 11:41:38 -0400 From: "David.M.Chess" Subject: re: PC\MS DOS based Viruses & OS\2 2.0 (PC) (OS/2) These aren't Official IBM Answers, but we have (naturally!) spent some time thinking about this and trying things out, and I can give some unofficial techieanswers... >From: >1. Is it possible for a DOS based Virus to survive & thrive on a system with > OS\2 2.0 using the (HPFS file system) instead of the (FAT system)? Yes. A simple "well-behaved" DOS virus, using the standard documented INT 21 calls, will be able to see and read and write files on the HPFS drive that have 8.3 names. So these files will be able to get infected in the usual way. The virus will only execute and infect in DOS sessions, of course, and not in OS/2 itself. Some viruses will refuse to infect OS/2-format EXE files; others destroy them (accidentally) by overlaying parts of the code; a few seem to be able to infect correctly, but the virus only runs when the EXE file is executed under DOS, not under OS/2. >2. Since IBM claims that OS\2 2.0 can run multiple dos sessions In virtual PC > windows, if I opened up 5 windows and one of them crashed as a result of > trying to load a DOS program that was infected by a 1571 Virus would OS\2 > come completely crashing down? Delete "IBM claims that": it's true! *8) In general, an application (whether a virus or not) crashing a DOS session will not do anything bad to OS/2 2.0 itself. You may have to close that session, but the rest of the world should still be up. If you find a DOS app bringing down OS/2 itself, it's most likely a bug that IBM would like to know about. >3. What happens to OS\2 if while using the DOS compatibility box in full > screen a partition table virus like the Jerusalem-b or Michaelangelo infect > system and alter the system? The Jerusalem is a file infector, not a partition table infector. The Michelangelo (and most other boot infectors) infect only at boot time, not after OS/2 or DOS or whatever is running. If you boot an OS/2 machine from a Michelangelo-infected diskette (for instance), the virus will install itself on the hard disk (OS/2 hasn't even loaded yet, so there's nothing it can do about that), and if the date is right (wrong), it will damage your data (same comment: OS/2 isn't in control yet, so it can't prevent this). On the other hand, once OS/2 is up, the virus won't be able to spread from your machine to other diskettes, since the virus depends on INT 13 to spread, and OS/2 doesn't use INT13. If you use Boot Manager or Dual Boot to boot DOS later, the virus will then be able to spread to diskettes. >4. If I loaded DOS, Windows3.0, WIndows 3.1, & OS\2 programs in seperate > windows, and one of my Win3.0 programs get infected by a ping-pong virus The ping-pong is a boot infector, not a file infector, so I don't know exactly what this question means. In general, a file infector will be active in the virtual memory of only the DOS session(s) that have had an infected file run in them; on the other hand, it will infect DOS files that you can then run in other DOS sessions, infecting the memory of those sessions, and if it's a file-infector that knows how to infect COMMAND.COM, and it does so, any DOS sessions started using that COMMAND.COM will have the virus in memory. So I wouldn't personally consider a DOS session under OS/2 to be nearly isolated enough to test viruses in. (We use a locked room with a motion detector, alarm, and no data connections through the walls for this, ourselves! A bit pricey for the average individual, though, hehe...) >5. How do Fat killers, boot sector viruses, and partition table viruses deal > with the HPFS system? What if you have more than one type of operating > system on your hard disk? (ex. DOS, OS2, Unix***, Novell) That's somewhat too general a question; different viruses will interact in different ways with different operating systems. Master boot record infectors ("partition table viruses") generally don't care what operating system is around, because they infect below the os level. They do depend on INT13 to spread, so an os that doesn't use INT13 will not tend to spread them. Boot viruses that make assumptions about the structure of the os partition will tend to mess up when faced with one that doesn't satisfy their assumptions. I will certainly agree that OS/2 is a wonderful place to do several things at once. I personally wouldn't run live viruses on my production machine, though, under -any- operating system... DC ------------------------------ Date: Sat, 23 May 92 14:44:48 +0000 From: an939@cleveland.Freenet.Edu (David Carlin) Subject: Virus Program for a Macintosh? (Mac) Two weeks ago, while at Computer class, I poped in a disk at our schools Macintosh Classic. A program I had bought that is on the System Utilities disk, Said there was a virus, and not to use the disk. I am only in 7th grade, and don't know much about Macintosh Viruses. Can anyone tell me of a Public Domain Program that I might be able to use? Thanx - -- [~~~\ /~\\~\ /~/[~~~][~~~\ David /~~~/ /~\ [~~~~\ [~] [~~~][\~\ [] [ O \ / O \\ \ / / [ ] [ O \ Carlin [ ]~ / O \ [ O / [ ] [ ] [ \ \ [] [ // ___ \\ \/ / [ ] [ / [ ]_ / ___ \ [ /\ \ [ ]_ [ ] [] \ \ ] [___//_/ \_\\__/ [___][___/ an939 \___//_/ \_\[_] \_\[___][___][] \_\] ------------------------------ Date: Thu, 21 May 92 21:48:31 -0400 From: flaps@dgp.toronto.edu (Alan J Rosenthal) Subject: Re: Can a virus survive being pkzipped or otherwise compressed? kjb@calmasd.prime.com (Ken Brucker) writes: >A columnist in a local computer magazine (Computer Edge for those in >the San Diego area) mentioned that viruses can't survive or at least >typically don't survive compression into zip files and other archives. Preposterous. When a file is infected, that file is modified. If a compression program doesn't have the property that when you compress and uncompress a file you get exactly what you started with, it's not a compression program. Things like boot sector viruses live on a non-compressed portion of the disk, of course. ------------------------------ Date: Fri, 22 May 92 13:48:42 +0100 From: Norman Paterson Subject: Re: Taxonomy of viruses Mary K.Kuhner (v5.108) writes: >virus' taxonomy from a scanner. Because of this, I suspect that >numerical taxonomy will give disappointing results in classifying >viruses. It will tend to consider viruses as very different which are >simply rearranged or recoded versions of the same exact functional >structure. It seems particularly iffy for polymorphic viruses, unless >attention can be focused on a non-polymorphic region. (The same Hmm. This could be a problem. Certainly it is possible to devise a distance measure which allows for re-arrangements - I devised one several years ago, it's outlined below. As for recoded versions with the same function - I think you could argue that you *do* want them kept separate. I don't know about the polymorphic viruses though. Any gurus able to comment? The measure I used was intended to find people by name, allowing for the fact that they never write their name the same way twice. For example, I would want to find that "Norman Paterson" is pretty close to "N R Patterson" (with 2 ts) or even "Norma Patrickson". I also used it to find places in a geographical database (many placenames are pronounced completely differently from the way they are written). The method is quite expensive to compute but does give good results, at least with strings *much shorter* than viruses. It works by looking for the longest common substring in the two strings. This divides each string into three parts: the bit before the substring, the substring and the bit after the substring. The similarity is calculated as the square of the length of the common substring, plus the similarity of the before-parts to each other, plus the similarity of the after-parts to each other. This is a recursive definition. The similarity of any string to the empty string is zero. The result of this computation is a positive integer; the bigger it is, the more similar the strings. I guess you could simply invert it to get a distance measure (though you get odd things like a non-zero distance between a string and itself). Anyway, the point of this is to show an example of a distance measure which is quite good at catching rearrangements. It might be better if you allowed the before-part of one string to match the after-part of the other, but that would cost more. Ah well, I'll put my money where my mouth is. If someone will send me, say, 100 strings which look like viruses, I'll try to classify 'em. Identify the strings by number. Don't send me any real viruses, nasty horrible things! Any takers please e-mail me first, I don't want everyone sending stuff! - -Norman ------------------------------ Date: Sat, 23 May 92 16:23:46 +0000 From: refrig@dixie.com (Todd Hedenstrom) Subject: what's this .signature stuff? I'm sorry if this is in a FAQ somewhere I haven't been able to find, but this is starting to nag at me - I keep seeing a line on messages here on the net that says something like 'Hi, I'm a virus - copy me to your .signature file' or something like that. What the heck is that? I just saw the same line, only this time the message was in German. Todd++; refrig@dixie.com ------------------------------ Date: Mon, 25 May 92 17:39:44 +0000 From: mkkuhner@phylo.genetics.washington.edu (Mary K. Kuhner) Subject: Re: Taxonomy of viruses Several people have written asking about the application of biological classification methods to computer viruses, so I've done a general reply. My lab distributes a free software package, Phylip, which can implement the algorithms mentioned here. But please do bear in mind that computer viruses don't evolve in the same way as biological ones, and the results will have to be interpreted with care. It's been proposed to classify a new virus by finding its nearest neighbor in the database of known viruses. I don't think that simply declaring 'New virus X is most similar to Michaelangelo' is particularly useful. A totally new virus will be most similar to *something* in the archives, but the similarity is likely to be meaningless, especially if measured by a bit-by-bit comparison. A more useful approach might be to draw an evolutionary tree (phylogeny) of known viruses, and see where the unknown one falls on it. If it is in the middle of the cluster of Michaelangelo variants, one might be able to make predictions about its behavior; similarly, if it is on a distant branch, it is probably a new or highly revised virus. I can see two distinct ways to construct a computer-virus phylogeny: 1. Distance methods. One can find some measure of bit-by-bit distance between two viruses, and use any one of several algorithms to combine these into a tree. Advantages: This can be completely automated--there is no judgement involved in assessing the similarity of two viruses. It is also similar to what a scanner might see--the greater the bitwise dissimilarity, the less the chance of a common string recognizable by a scanner. Disadvantages: Distance algorithms were designed under the assumption that changes take place one at a time and at random (as in mutation of DNA). Computer viruses more likely change in blocks. Two viruses may be very distant bitwise because a payload message has been changed, or the order of certain operations is different, even though they are otherwise identical. I think this method is especially likely to fail with polymorphic viruses. On the whole, I think distance may work well with very closely related viruses, but will probably fall apart with more distantly related viruses (and is hopeless with unrelated ones, of course). There are a number of programs in the Phylip package which could do distance comparison of computer viruses. All that would be needed would be a program to compute pairwise distances between viruses. I would recommend the program NEIGHBOR, which implements the neighbor-joining algorithm of Saitou and Nei. 2. Parsimony methods. Viruses can be hand-scored for the presence or absence of various features--file types infected, stealth, encoding, polymorphism, file destruction, etc.--and this data can be used to draw a phylogenetic tree via parsimony. The assumption is that these traits are not often changed by virus writers, so that viruses which share many of them are likely to be related. Advantages: The tree produced is likely to reflect intuitive ideas of virus relationships, since it's based on traits that are felt to be important. It won't be misled by such things as different literals in the payload. It would be possible to classify a virus based on a report of its behavior, given enough detail, without having to examine an actual copy of the virus. Disadvantages: This method requires a lot of human work in choosing the traits to be scored, figuring out a consistent way to score them, and scoring each virus. It would be hard or impossible to automate this. Results could be biassed by poor choices of traits. New viruses might force recoding of the categories (i.e. if your choices are 'boot infector' versus 'file infector' and a virus which infects neither is found) which could be a lot of work. These methods are slower than the distance method I recommended; they might take an hour or more to produce a tree of a hundred viruses. They probably can't be made part of a scanner or heuristic analyzer, both for this reason and because it would take a terrific expert system to be able to score the virus' traits automatically. Programs PENNY or CLIQUE from Phylip could be used to make trees from data coded in this fashion. All of the Phylip programs can be obtained by anonymous ftp to evolution.genetics.washington.edu. They are in PASCAL; executables are also available. I hope this is helpful! Mary Kuhner mkkuhner@genetics.washington.edu Felsenstein Lab, Department of Genetics University of Washington ------------------------------ Date: 25 May 92 23:31:39 +0000 From: frisk@complex.is (Fridrik Skulason) Subject: Re: BAD IDEA (was: Where can I find Virus signatures?) In VIRUS-L Digest V5 #106 Christopher Mateja asks: > 1. Are there any lists availible containing all known virus signatures? If you mean "are there any lists containing signatures for all known viruses", the answer is no - simply because not all viruses can be detected with a signature. However, there are several lists floating around, containing a large number of signatures - some are good, others are lousy. You can probably get a decent database by combining them. I don't particularly recommend relying on other people's signatures - I find my own (and keep them secret), but ..... - -frisk ------------------------------ Date: Mon, 25 May 92 00:50:00 +0100 From: Anthony Naggs Subject: Virus hides in printer (again) & Virus In Printer? I would like to draw these strands together, as they are about the same article - perhaps if I had given a longer extract in my posting the other correspondents would have realised the relationship. At school my English teacher always accused me of being telegrammatic, perhaps I still am, (its just that I send more telegrams now, :-)). Anyway last Thursday's edition of New Scientist printed a letter from me highlighting the improbability of such a virus. (Lachlan Cranswick - lachlan@dmp.csiro.au) > One point to make is that general PC users are very susceptable > to these types of stories ( me to (sort of) - because you can never > underestimate the ingenuity of these virus makers). > > My main problem is that other site PC users will read these > articles too; and it is easy for people to > blame printer problems on viruses if they get the chance > (if only they would learn to load the correct printer driver, or > select the correct printer mode) Exactly, this is what makes me angry when such spurious stories appear, particularly in respectable forums. Hopefully the publication of my letter will reassure most of the PC users who see the magazine. (Iain Noble - lba002@prime-a.tees-poly.ac.uk) > > I checked the date of the issue and it wasn't April 1st :-) > (Bob Hutchinson - hutchinson@wrair-emh1.army.mil) > Neither was Hitler's diary. Doesn't make it any less of a hoax. By any > chance, does this magazine print a lot of articles on Liz Taylor's private > life? New Scientist is (some people will say it was until it's recent relaunch) a weekly news & features magazine with a strong regular readership, a little more popular in style than Scientific American. However it has never had a computer consultant, so plausible stories given to the magazine are likely to get published. I have had a telephone discussion with one of their editors which I hope will ensure that in future they check computer virus storie a little more carefully. Regards, Anthony Naggs Internet: amn@vms.brighton.ac.uk or xa329@city.ac.uk Janet: amn@uk.ac.brighton.vms ( cbs%uk.ac.brighton.vms::amn ) or xa329@uk.ac.city ( cbs%uk.ac.city::xa329 ) ------------------------------ Date: Fri, 22 May 92 08:38:06 -0400 From: padgett@hobbes.dnet.mmc.com (A. Padgett Peterson) Subject: Flopticals Since V-L 108 appeared I have received several requests for information that I do not have (am playing with one only). For info I suggest you call INSITE Corporation who makes the drives (several companies are selling them) at (408)946-8080 (California, USA). If you agree with my opinion that they need to be plug-replacements for a regular floppy drive (no SCSI requirement), tell them that. Warmly, Padgett ps Right Coast number is (603)437-8318 (New Hampshire) ------------------------------ Date: Mon, 25 May 92 23:14:08 +0000 From: MIG@politon.msk.su (Igor G. Muttik) Subject: Article about "Starship" virus available (PC) Dear colleagues! For a few weeks I have seen many articles in "comp.virus" on the "Starship" virus. Public interest of virus analysts and PC users to this particular virus is probably linked with its complex behavior and interesting internal structure. I have described this virus after thoroughly investigation and this description is available from archive now. It seems to be a type of research virus, that incorporates many unique features: - it was one of the first multi-partite viruses, infecting both executables and Master Boot Record (MBR) - it places its code in video-memory during boot process - it is rather polymorphic and uses synonyms of processor opcodes - it is encrypted in any form (in files, on HDD and in memory) - when infecting MBR virus changes only three bytes in partition table The article contains description of virus features and necessary information to identify infected files, harddisk and memory. It also contains recommendations on the question: "How to prevent the infection and what typical demonstration it causes?" I think that PC-users of any level will found some interesting information about "Starship" virus. Best regards, Igor. [Moderator's note: Thanks, Igor. The document is available by anonymous FTP on cert.org in pub/virus-l/docs/starship.txt] - -- /----------------------\ /-------------------------------------------------\ | Igor G. Muttik, Ph.D. | "...it is a thing you can easily explain twice | | Moscow, Russia | before anybody knows what you are talking about." | | MIG@politon.msk.su | Winnie-the-Pooh | \----------------------/ \-------------------------------------------------/ ------------------------------ Date: Tue, 26 May 92 08:22:45 -0500 From: John Perry Subject: New Files on Eugene (PC) Hello Everyone! VSUMX205.ZIP is now available on eugene.gal.utexas.edu (129.109.9.21) by anonymous ftp. If you have any problems, please send mail to perry@eugene.gal.utexas.edu. - -- John Perry - perry@eugene.gal.utexas.edu ------------------------------ Date: Sat, 23 May 92 18:00:51 -0700 From: rslade@sfu.ca (Robert Slade) Subject: Earliest computer viral history (CVP) I have been asked to put some indication of the weekly column submissions on the subject line so that those faced with massive network feeds can search for them quickly. I will, therefore, try to remember to put the (CVP) designation on these postings. (I guaratee nothing: I am proverbially absent minded, and even started *this* posting without remembering to do it the first time.) HISINT1.CVP 920523 Earliest history of viral programs Viral programs have a long, and sometimes honourable, history. (I do not intend, by this statement, to be involved in the current debate about whether or not viral programs serve a useful purpose outside research environments.) In the earliest computers it was vital that you knew the initial state of the computer. It was also important that no remnants of other programs remain. (It is hard enough to debug programs now: you don't need extraneous "noise" to deal with.) An instruction was often implemented that had only one function: it would copy itself to the next memory location and then proceed on to that location. Thus, by starting this instruction at the beginning of memory, the entire memory space could be "filled" with a known value. This single instruction could be seen as the first viral type program. As computers progressed, it became possible to run more than one program at a time in a single machine. It was, of course, important that each program, and its associated data, be contained within certain bounds, or partitions. Inevitably, there were programs which "broke the bounds", and would either perform operations on the data or programs belonging to different procedures, or actually transferred control to random areas and tried to execute data as program instructions. Random operations and damage would result. Attempts to trace the "path" of damage or operation would show "random" patterns of memory locations. Plotting these on a printout map of the memory looks very much like the design of holes in "worm- eaten" wood: irregular curving traces which begin and end suddenly. The model became known as a "wormhole" pattern, and the rogue programs became known as "worms". In an early network of computers a similar program, the infamous "Xerox worm", not only broke the bounds within its own computer, but spread from one computer to another. This has led to the use of the term "worm" to differentiate a viral program that spreads over networks from other types. The term is sometimes also used for viral programs which spread by some method other than attachment to, or association with, program files. (Programmers being who they are, the development of such rogue programs became a sport. This is now enshrined in the game of "Core Wars". A program is run which "simulates" a computer environment. A standard set of instructions, known as "Redstone code", is used to build programs which battle each other within the simulated environment. The objective is survival. The use of such tactics as attack, avoidance and replication is of interest to virus research, as is the trade-off between complexity of design and chance of destruction.) copyright Robert M. Slade, 1992 HISINT1.CVP 920523 ============= Vancouver ROBERTS@decus.ca | "Remember, by the Institute for Robert_Slade@sfu.ca | rules of the game, I Research into rslade@cue.bc.ca | *must* lie. *Now* do User CyberStore Dpac 85301030 | you believe me?" Security Canada V7K 2G6 | Margaret Atwood ------------------------------ End of VIRUS-L Digest [Volume 5 Issue 110] ******************************************