VIRUS-L Digest Tuesday, 18 Feb 1992 Volume 5 : Issue 32 Today's Topics: Re: Michaelangelo ID sigs comp/w Stoned (PC) Re: IBM PS/2 and CHKDSK ... (PC) Re: Michelangelo threat (PC) Re: Ohio Virus? (PC) Re: two small comments (PC) Re: Will re-formatting a floppy remove ALL vires (PC) New original disks with Michelangelo (PC) Re: AUX files (PC) Intel enters the game (PC) Floppy boot sectors & viruses (PC) Network World 10FEB92 (PC) Non-inanimate Michelangelo (PC) Re: AUX files (PC) WDEF infection at a school (Mac) 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: 10 Feb 92 21:53:56 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Michaelangelo ID sigs comp/w Stoned (PC) PIPHER@vm.utcs.utoronto.ca (William) writes: > The little program, which I call "stone.com" reads in sector 1 track 0 > and scans it for a unique string which identifies the presence of the > "STONED" virus, and if found, the program displays a warning message > and terminates with an errorlevel code. In the case of the stoned > virus, a 100% reliable search string is simply the word "stone" (read > case insensitive). Be careful. There are several versions of this virus, most of which are just a trivial patch. Some of them do not contain the word "stoned". For instance, one of the variants says "sanded"... > My question to the net is -- what is an analogous ID string for the > Michaelangelo virus that I could look for at the same time as I look > for "stone"? If you mean a plain ASCII text - no, there isn't any. You must modify your program to be able to scan for hex strings as well... > Normally I don't worry extremely too much about virus's, but the boot > sector kind are such pests, and if Mikey is as stupid as stoned, I'd Please, be careful when naming viruses. Michelangelo, not Mikey. There is a virus, named Miky, which is a completely different one, so you may confuse some people... Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Bontchev@Informatik.Uni-Hamburg.De Fachbereich Informatik - AGN, rm. 107 C Tel.:+49-40-54715-224, Fax: -226 Vogt-Koelln-Strasse 30, D-2000, Hamburg 54 ------------------------------ Date: 10 Feb 92 21:09:55 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: IBM PS/2 and CHKDSK ... (PC) BRENNAAA@DUVM.OCS.DREXEL.EDU (Andrew Brennan) writes: > When you run CHKDSK under Dos 3.3 on a PS/2, shouldn't the > numbers for total memory still come up to 655360? I have four Nope. I'm on a PS/2 Model 50Z right now, using DOS 5.0 and also have a 1 Kb missing. This often happens with the PS/2 models, they are meant to be like that. > machines here (at least) all pulling 1k short of that. The > only explanation I have is that it might be linked to the > Microchannel, etc. I booted from (what I think to be a) clean My (wild) guess is that it has something to do with the configuration. Try to play with the configuration program and see if you can get better results. > Dos and still have the same results. Calm down, you don't have a virus. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Bontchev@Informatik.Uni-Hamburg.De Fachbereich Informatik - AGN, rm. 107 C Tel.:+49-40-54715-224, Fax: -226 Vogt-Koelln-Strasse 30, D-2000, Hamburg 54 ------------------------------ Date: 10 Feb 92 21:59:44 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Michelangelo threat (PC) padgett%tccslr.dnet@mmc.com (A. Padgett Peterson) writes: > With the latest announcement of Michelangelo being distributed on > BitCom disks packed with modems, it seems apparent that the spread of > this virus is getting out of hand. BitCom too? My God, this sounds like a conspiracy... Is there a major software dealer, who HAS NOT shipped Michelangelo recently? Or maybe they have decided to cut off the funds for the quality control departments? Just wondering... Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Bontchev@Informatik.Uni-Hamburg.De Fachbereich Informatik - AGN, rm. 107 C Tel.:+49-40-54715-224, Fax: -226 Vogt-Koelln-Strasse 30, D-2000, Hamburg 54 ------------------------------ Date: 10 Feb 92 22:09:28 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Ohio Virus? (PC) treeves@magnus.acs.ohio-state.edu (Terry N Reeves) writes: > Ohio virus is real there are 5 or 6 variations on it at least. It is a Let's not exaggerate. Ohio is juts one of the Den Zuk variants and the whole Den Zuk family consists of 4 different viruses. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Bontchev@Informatik.Uni-Hamburg.De Fachbereich Informatik - AGN, rm. 107 C Tel.:+49-40-54715-224, Fax: -226 Vogt-Koelln-Strasse 30, D-2000, Hamburg 54 ------------------------------ Date: 10 Feb 92 22:26:01 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: two small comments (PC) hobbit@vax.ftp.com (*Hobbit*) writes: > F-prot 2.02 believes that Central Point's "vsafe" and "vwatch" are > Flip variants. This may have been stated already on virus-l and I > think I dimly remember it, but perhaps it should find its way into the > doc... Yes, it has been mentioned. But, IMHO, it should find its way into CPS' software, because it's their problem. Any anti-virus scanning program -must- encrypt the scan strings it uses, otherwise it risks to be flagged as infected by other virus scanning software. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Bontchev@Informatik.Uni-Hamburg.De Fachbereich Informatik - AGN, rm. 107 C Tel.:+49-40-54715-224, Fax: -226 Vogt-Koelln-Strasse 30, D-2000, Hamburg 54 ------------------------------ Date: 10 Feb 92 22:43:33 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Will re-formatting a floppy remove ALL vires (PC) washer@sequent.com (Jim Washer) writes: > I am know the proud and happy owner of an infected 3.5" 1.44Mb floppy. > Should I immediately burn it in a large bonfire, or will re-formatting > exorcise it adequately. Formatting should be enough - if you don't have a virus in memory. Otherwise you'll destroy everything... except the virus. :-) Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Bontchev@Informatik.Uni-Hamburg.De Fachbereich Informatik - AGN, rm. 107 C Tel.:+49-40-54715-224, Fax: -226 Vogt-Koelln-Strasse 30, D-2000, Hamburg 54 ------------------------------ Date: Tue, 11 Feb 92 19:28:03 +0100 >From: ralfscheckenbach@uaimzd.Mathematik.Uni-Mainz.DE Subject: New original disks with Michelangelo (PC) Hello netters, Our university purchased a ARTEC mouse at a large vendor in Germany (Computer Schmitt). This mouse is delivered with a black, not writable 5 1/4 " diskette (no hole). On this diskette was Michelangelo (Scan 85).Is there the possibility of a mutation, because it infected an PC and it seems that this PC never was booted or started with this diskette in the drive. RALF ------------------------------ Date: Thu, 13 Feb 92 07:57:28 -0500 >From: David_Conrad@MTS.cc.Wayne.edu Subject: Re: AUX files (PC) In VIRUS-L Digest v5i27 Vesselin Bontchev writes: >... If somebody has DOS 3.3 and FF from version >4.5 of NU, could you please check and >confirm or deny this? ... > >Regards, >Vesselin I am running MS-DOS 3.3 and Norton Utilities 4.50 Advanced Edition. I haven't been able to duplicate this with FF (FileFind), but quite similar behaviour is produced by FI (FileInfo), a DIR command replacement. I first noticed this about a month ago, but with NUL instead of with AUX. (Funny how it should come up here so soon after I bumped into it.) Anyway, I was briefly worried, not about a virus but that through some strange error in a program I had just completed I had managed to create a file with the name "NUL" while trying to tell the program to send its output to the NUL device. However, examination of the directory with the Norton Utilities main program, NU, quickly revealed that there was no actual file named "NUL" in the directory. Running "FI NUL", "FI CON", "FI PRN", etc., and especially relevant to this discussion, "FI AUX", will seem to indicate that there is such a file in the current directory, *whatever the current drive and directory may be*! Incidentally, the DIR command of COMMAND.COM doesn't display these 'ghosts' of the device drivers, however I use a command aliaser and have the "DIR" command mapped to Norton's "FI" program. Perhaps the worried user does something similar? I don't often remember that I'm running a program and not executing a built-in command when I type 'DIR', and this has the psychological effect of making the output seem more 'official' since I think it's being reported by the Operating System. In any case, this problem is caused by a bug in either DOS 3.3 or Norton's FileInfo 4.5, and not by any virus, trojan, or logical error on the disk, and ought to be in some FAQ list somewhere. It's certainly no cause for alarm. Since we're so into nomenclature lately, we could call these 'device driver ghosts' or just 'device ghosts' for short. Regards, David R. Conrad David_Conrad@mts.cc.wayne.edu ------------------------------ Date: Thu, 13 Feb 92 12:50:48 -0500 >From: hobbit@ftp.com (*Hobbit*) Subject: Intel enters the game (PC) I haven't seen a reference to this yet, so it might be new info. At Networld this week I had a brief look at a product Intel is offering "rsn", which is a network-based virus scanner that runs "continuously" as well as being able to do one-time scans. It can also scan files going in and out of the server on the fly as they are opened. Looked pretty cute. I grilled them about their detection methods; they claimed to get all their samples and info from NCSA. [Does this mean that NCSA will send virus samples to "just anybody", or if not, what are their criteria?] _H* ------------------------------ Date: Thu, 13 Feb 92 12:24:56 -0500 >From: padgett%tccslr.dnet@mmc.com (A. Padgett Peterson) Subject: Floppy boot sectors & viruses (PC) >From: martin zejma <8326442@AWIWUW11.BITNET> >Subject: unremoveable michelangelo virus (PC) >In response to tong@ee.ubc.ca (Issue # 19 ) : lengthy destription of multiple-infection deleted - ------------------------------ >From: martin zejma <8326442@AWIWUW11.BITNET> >Subject: clean up v85 destroys floppy (PC) > Due to a slight wonder ( for me) explained by Frisk or Vesselin a while ago > the floppy is still usable ( cause the Media Descriptor Byte in the bootsct > is only read under certain conditions which I don't remember ) , but > I Wonder what happens if I try to boot using this disk ( I expect a message > from the ROM-BIOS , cause even the 'No bootable disk' message isn't there). This is the reason I do not bother in the FixFBR program to try to retrieve the original boot sector. Instead, for any of the four main floppy disk types 360k & 1.2 Mb 5 1/4, 720k & 1.44 Mb 3 1/2, I simply replace the "infected" boot record with a complete new one consisting of a "generic" table and my SafeFBR code that checks the integrity of the system and displays a message if there is a problem. Since the Floppy boot record cannot be trusted, it is just replaced. If the media type is not there or wrong, the user must physically examine the disk (software does not have eyes) and select the appropriate size. Of course, this is primarily for use on uninfected disks (if you boot from an infected floppy with the SafeFBR (FREEWARE) code, it will warn you). However, an infected floppy's integrity cannot be trusted thereafter (after data is retrieved, reformatting of the floppy is recommended) since if the virus overwrote part of the FAT, while the virus can be defanged, the corruption is still there. This all stems from my basic concept - without hardware it is impossible to protect a system from an accidental reboot with an infected floppy. 98% maybe (see NoFBoot, also FREEWARE) but not 100%. Similarly, you cannot protect (without hardware again) and infected PC from infecting a floppy. However, IMHO, if you detect the infection immediately and force the user to eradicate the virus before going further, they are not going to spread very far. SafeFBR will do this. Actually, I wrote FixFBR more to provide this kind of protection for floppies. The fact that it has proven 100% successful in making boot-sector-infected (e.g. Michelangelo) floppies non-contageous was serendipious (though welcome). If I ever get the time, my plan is to complete the trio with a program to replace the hard disk DOS boot record with a similar construct for protection & active detection of those infections which replace the MBR (e.g. Azusa) and those which replace the DBR (e.g. MusicBug) from the BIOS level. This is a bit more complicated since I also intend to include recovery but after examining the Microsoft DOS 5.0 DBR, IMHO I couldn't do any worse. Chilly (fog still there @ 11 am) Padgett Usual Disclaimers... ------------------------------ Date: Thu, 13 Feb 92 14:03:24 -0600 >From: THE GAR Subject: Network World 10FEB92 (PC) An article in this week's Network World reported on a test by the National Computer Security Association which rated 19 virus scanning products on their ability to detect viruses, and how many additional detection features they had. It did not say what those additional features were. Please note that many of the below products have been updated since the versions below. Here are some excerpts, which I take from their graphic. The address of the NCSA follows if you would like the full report. Or you could call Network World at (800) 622-1108. The article was by Salvatore Salamone, and the graphic I refer to below was by Susan Slater. Top 5 Features 76 points possible - ------------------ 69 Dr. Solomon's ToolKit FindVirus V3.2 68 Certus International Corp.'s NOVI V1.0 64 Fridrik Skulason's F-Prot V2.0 63 Lerechaun Software Internationsl, Ltd's Virus Buster Doctor V3.75.0 61 XTree Co.'s ViruSafe LAN V4.50 Top 5 Detection 77 Points Possible - ------------------ 76 McAfee Associates Scan V7a9V84 75 Central Point Software, Inc.'s Anti-Virus V1.1 75 Leprechaun Software International's Virus Buster Doctor V3.75.0 75 RG Software Systems, Inc.'s Vi-Spy V7.0 74 Fridrik Skulason's F-Prot V2.0 The above data was in a graphic labelled Virus Scanner Scorecard which said at the bottom: "The NCSA rated virus scanner programs both on the product's ability to detect viruses and features that help net managers find virus infections." Hope this is useful to someone,. Later Gary Warner Disclaimer: The above data in no way reflects my personal opinion. I am merely passing on information that I thought might be useful to some of you. If you would like the full report of the NCSA's findings send $75 to: NCSA 227 W. Main St. Mechanicsburg, PA 17055 (717) 258-1816 ------------------------------ Date: Thu, 13 Feb 92 12:38:49 -0800 >From: Richard W. Lefkon Subject: Non-inanimate Michelangelo (PC) Here is a several-words statement whihch, each time I mention it, the listener generally says, "probably true." It is aimed at product vendors, many of whom are recipients of virus-L or friends of those who are: IT IS STATISTICALLY IMPROBABLE THAT THE THREE OR MORE SHRINK-WRAPPED BROADCASTS OF MICHELANGELO COULD HAVE COME ABOUT WITHOUT EXPLICIT HUMAN INTERVENTION - PERHAPS BY DISGRUNTLED INSIDERS AT THE SOURCE COMPANIES. IT'S NOT OUTLANDISH TO CONSIDER THE POSSIBILITY THANT TWO OR MORE OF THESE INDIVIDUALS HAVE BEEN IN TOUCH WITH ONE ANOTHER. Very few Virus-L readers would want to see more instances of the statistically unlikely avoidance of successful companies' quality control procedures by the Michelangelo Virus. If you would like, please pass this along to someone who might want to be reminded about enforcing all points of their quality control process over the next few weeks. This one isn't "you are stoned, or "your computer wears army boots," and it could matter. Thanks, - -dick P.S. This statement isn't the official position of an y university, comp[nany or professional group I may be associated with. ------------------------------ Date: Thu, 13 Feb 92 16:00:42 -0600 >From: johnboyd@ocdis01.oc.aflc.af.mil (John Boyd;LAHDI) Subject: Re: AUX files (PC) In your message of 13 Feb 1992 at 1548 CST, you write: > > Date: Fri, 07 Feb 92 05:52:49 -0600 > >From: terry@lawton.lonestar.org (Terrence R. Redding) > Subject: Re: AUX files (PC) > > Reference the AUX file in every directory. Check the date each file > was created. It may simply be a reflection of the way the software > was installed on the HD. If each software package was installed as if > it was the only software on the drive then a separate AUX file might > result. > > - --- > DOMAIN: terry@lawton.lonestar.org (Terrence R. Redding) > UUCP: ...!rwsys!lawton!terry (Terrence R. Redding) > Good News II BBS Lawton, OK USA +1 (405) 357-0478 > One other bit of weirdness I'd like to inject here. At home I have an ATT 6300 PC, it's an XT compatible, running ATT's MSDOS 4.01, and NDOS 6.01. Just for the halibut after you guys started talking about this, I typed dir aux /s or something like that in my root directory, and lo and behold, in every directory it showed an 'aux' file that, if you went to any single directory and issued a dir, would not show. This same behavior was exhibited with the 'filenames' lpt, con, etc. BUT, I tried it on my Zenith Z-248 @work, running MSDOS 3.2, and it chokes (of course!). I don't understand it either, and wouldn't have tried it if I hadn't read the discourse. Just when you think you've seen everything..... B-{). ------------------------------ Date: Thu, 13 Feb 92 20:58:19 +0000 >From: rp@llex.ll.mit.edu ( Richard Pavelle) Subject: WDEF infection at a school (Mac) My 4th grader uses one of ten Macs at her school and often when she brings home her floppies they are infected with WDEF A. The Macs do not have hard drives and I checked to verify that all startup disks are indeed infected. Is there a small program I can install on each startup (after I have disinfected them) to keep this virus off? Or is there a better way to deal with this problem? Thanks. ------------------------------ Date: 10 Feb 92 20:21:20 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Cohen's error RADAI@HUJIVMS.BITNET (Y. Radai) writes: > 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 I'll show you a copy of the paper the next time we meet personally. Since it is a pre-release version, I felt somewhat unetical to quote the whole thing publicly. > 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. Well, to be honest, I have't thought about this possibility at all... :-) > 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 Well, the greater simplicity is arguable; I guess that Cohen has been charmed by the elegant way to reduce the virus problem to the halting problem (or more exactly, by the elegantness of the proof for the halting problem, so he tried to apply the same method)... > 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. Especially (2) is extremely useful from the practical point of view... > 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. Wait a minute; there is still something that I do not understand. The computer has a finite amount of memory. Any program (or overlay) is a particular configuration of states of the memory cells. However, since the total amount of memory cells is finite, then the total amount of permutations of the states of these cells (which represents the total amount of possible programs/overlays) must be also finite. Therefore, the total amount of possible programs is finite for the real computers. Or do you consider the two-times load of one and the same program to be some kind of super-program, which is loading its two overlays? > >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 No, I wasn't saying that the second kind of infinity is not infinity in the mathematical sense. I wasn't clear enough, I must admit. But I - -do- make a difference between the two kinds of infinity, because the second kind provides a compact way to express all its members (via the generation rule), while the third kind is a more general one. > third kinds consists in distinguishing between denumerable and > non-denumerable infinities, or between cardinal and ordinal numbers, No, numerability was not what I meant... Maybe the difference between the cardinal and ordinal numbers, yes... > but the second kind is certainly a mathematical one. Certainly; I agree with that. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Bontchev@Informatik.Uni-Hamburg.De Fachbereich Informatik - AGN, rm. 107 C Tel.:+49-40-54715-224, Fax: -226 Vogt-Koelln-Strasse 30, D-2000, Hamburg 54 ------------------------------ End of VIRUS-L Digest [Volume 5 Issue 32] ***************************************** Downloaded From P-80 International Information Systems 304-744-2253