VIRUS-L Digest Tuesday, 15 Jan 1991 Volume 4 : Issue 10 Today's Topics: Re: Apple //gs "Die!" Virus Stone-2 (PC) Reoccurence of Stoned on formatted drives (PC) QEMM IS _NOT_ A VIRUS (was Re: QEMM Virus? (PC)) Re: Hard Disk Protection (PC) and (Mac) Re: SCAN program for IBM's (PC) Stoned (PC) Re: SCAN program for IBM's (PC) Johsi / Stoned2 (PC) Re: possible macintosh virus (Mac) Re: SCAN program for IBM's (PC) Re: Grapes virus? (Mac) (No) Viruses in Irak's EXOCET? TROJAN WARNING: A VM trojan horse (IBM VM/CMS) 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. 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, 11 Jan 91 16:59:55 +0000 From: ccsjaas@gdr.bath.ac.uk (Julian Sims) Subject: Re: Apple //gs "Die!" Virus A dangerous new virus found at the City University. Article from computer unit newsletter Xmas 1990 A "new" virus that originated in Spain, appears to be very infectious and, after a set number of boot-ups will completely wipe the hard disk. It does not reside in the areas where viruses have bee found to date, so it is not found by any of the detection programs at City. ------------------------------ Date: Fri, 11 Jan 91 10:28:00 -0800 From: Michael_Kessler.Hum@mailgate.sfsu.edu Subject: Stone-2 (PC) Someone mentioned that Stone-2 has not reached the States yet. Maybe not. But I have had an infection that has been "dual." Running Scan, I would be told that I had an infection of Stone and Stone II. But one pass of Clean would remove it. Since then I have switched to F-Prot, have had infection of Stone, but no indication that Stone II was involved (I am using Roman numerals because that is the way it was identified; is there a difference between Stone II and Stone-2?) MKessler@hum.sfsu.edu ------------------------------ Date: Fri, 11 Jan 91 12:38:54 -0600 From: C09615SJ@WUVMD.BITNET Subject: Reoccurence of Stoned on formatted drives (PC) Hi, I have a tendency to only scan VIRUS-L when I read it so I am not sure about the current line of discussion regarding the user who had been reinfected with the STONED virus after "cleaning" his hard drive. Let me present a problem that we had a few weeks ago for your consideration. The equipment: A 386 clone with an 80Mb hard drive AND a floppy controller with four ports; and a gob ( >5Mb ) of extended memory. Floppy A: is a 360K 5 1/4", B: is a 1.2M 5 1/4", and C: is a 1.44M 3.5". The hard drive has four partions (E,F,G, and H) and one RAM drive, I:. We had a version of STONED that McAfee could NOT detect or clean because of the way it had infected our drive. The chain of events went something link this: 1> We had become aware, through a comedy of errors, that our hard drive was STONED after we inserted a known-to-be-clean diskette into the A: drive, used a DIR command, and then removed it and checked the boot sector with Norton Disk Doctor. 2> SCAN would not detect the virus on our E: drive (the boot drive), but would detect it in memory. 3> If we put a clean disk in our 3.5" drive (drive C:) and then SCANed it, it would find STONED "in the partion table" but CLEAN was unable to remove it. now it gets weird... 4> We would boot from a (repeatedly confirmed) clean disk in our A: drive. SCAN memory. Find nothing. Play around on the B: and C: drives. SCAN memory. Find nothing. Change drive to E: and then immediately change back to C:. SCAN memory. Find STONED resident in memory. Our analysis of the situation was that STONED had infected the first sector of our hard drive which was the partion table NOT the boot sector. McAfee's CLEAN was not able to clean our drive because (we guess) the program assumed that the first partion of our hard drive was C: and it couldn't handle the values it was finding for our configuration. We know for a fact that when we attempted to CLEAN our E: drive, nothing would happen. We solved our problem by reformatting and repartioning the hard drive and pulling the old data off of tape. Somewhere in the middle of this process we called McAfee and discussed our problem. They were very responsive and very interested but seemed as stumped was we were. We were expecting a call-back from them but, when one never came, we solved the problem on our own. I would like to state for the record that we feel that they have made an excellent product and that they are an organization with a great deal of integrity. The frightening thing about this whole situation was that STONED would get loaded into our computer's memory whenever we did anything that forced it to check the partion table on our hard drive regardless of whether or not we booted from a clean system diskette. Hope this helps, Jon Jon Spinner C09615SJ@WUVMD ECS computer clinic manager Washington University in St. Louis ------------------------------ Date: 09 Jan 91 15:51:56 +0000 From: mitel!cunews!cognos!cognos!uunet.uu.net!garym@uunet.UU.NET (Gary Murph y) Subject: QEMM IS _NOT_ A VIRUS (was Re: QEMM Virus? (PC)) The code cited in the original posting was a legitimate section of the QEMM install and optimize code --- the sequence in question is part of a 'reboot' procedure. After seeing the original notice in the digest, we contacted Quarterdeck by fax and received the above explanation. As a further note: the original posting did not say _why_ the so-called signature was suspicious or how it was discovered. Our virus checking detected no anomaly. If you find something suspicious, please tell us why and how you found out. Please do not just "pass it on" when you are posting such serious allegations; always check your sources before announcing to the world. These two seemingly innocent postings have probably cost Quarterdeck a fortune in lost time and fax expenses! - -- o| Gary Murphy |o |------------------------------------------------------------------------| o| uunet!mitel!cunews!cognos!garym garym%cognos.uucp@ccs.carlton.ca |o | Cognos Inc. P.O. Box 9707 Ottawa K1G 3N3 (613) 738-1338 x5537 | o| "There are many things which do not concern the process" - Joan of Arc |o ------------------------------ Date: 12 Jan 91 08:22:04 +0000 From: phaedrus@milton.u.washington.edu (Mark Phaedrus) Subject: Re: Hard Disk Protection (PC) and (Mac) padgett%tccslr.dnet@uvs1.orl.mmc.com (Padgett Peterson) writes: [another user's request for something for the PC similar to Mac's SAM deleted] >Could be done with something hooking the timer but why ? MACs execute >code on the floppy when inserted but an IBM or clone does not (unless >you try to boot from it). Under MS-DOS, a program must be requested >for execution before it is loaded and that is when good anti-viral >programs do their thing. Not to pick nits here, but this contains a pretty common misconception about the Mac that should be cleared up (since it's important when considering Mac virus protection). Macs do not automatically "execute code on the floppy when inserted." If you have infected application files in a floppy disk and you insert it, nothing adverse will happen unless you actually try to launch the infected application The Mac viruses (notably WDEF) that infect immediately on disk insertion do this because of the way the Finder stores information on disk, and the way Mac file contents are accessed. Most file access on a Mac is resource-based; instead of a program asking for a specific range of bytes, it asks for, say, desk accessory #12. Depending on which access calls the program uses, it can either look for that resource in one specific file, or in all the currently-opened files, looking in the most recently-opened first (which the System itself usually does). That's how programs like Suitcase II that let you add new fonts and DAs on the fly work; they just hold the new files open, and the System automatically looks through them for resources as well. Every Mac disk has a "Desktop" file that keeps track of where applications are, what their icons look like, etc. When you're running the Finder, it keeps all these files open. The WDEF and similar viruses sneak in by infecting these Desktop files with a resource that's the same ID as one the System uses; when the System looks for this resource, it picks the one in the Desktop file over the one in the System file, since the Desktop file was opened more recently. If the resource is one that would normally be executed (like a WDEF, which tells the Mac how to draw windows), the System will execute the infected resource, which can then copy itself to other Desktop files or do anything else it wants to do. Once you understand how the virus enters and spreads, it's not nearly as threatening. Unless you're running the Finder (or some other program that uses Desktop information), it doesn't matter whether a disk is WDEF-infected or not, since that file is never opened. If you hold down Command-Option during a restart or while inserting a disk (which forces the Desktop to be rebuilt), the virus is eliminated without infecting the Mac, since the infected Desktop file is deleted and replaced by a clean copy. Finally, if you're using Desktop Manager (which I would heartily recommend), your hard disk can't be infected, since there's no Desktop file on it at all and since the files that replace it don't store resources.-- Internet: phaedrus@u.washington.edu (University of Washington, Seattle) The views expressed here are not those of this station or its management. "If you can keep your head while those about you are losing theirs, consider an exciting career as a guillotine operator!" ------------------------------ Date: 13 Jan 91 14:32:42 +0000 From: frisk@rhi.hi.is (Fridrik Skulason) Subject: Re: SCAN program for IBM's (PC) > I am interested in finding a DOS antivirus program which would > automatically scan disks as they are inserted. Why? Doing this seems a bit silly to me, to say the least. Consider the following: On PCs we have basically two types of viruses - Boot secor viruses and program viruses. Assuming we could in all cases detect if a new disk has been inserted, which cannot (I think) be done on the original PC, but only on XTs, ATs and late computers (see INT 13H, function 16H), let's just look at the benefits: It must be kept in mind that the PC does not automatically execute code from the diskette when it is inserted. One some other machines, (for example Amiga) this is done, so an anti-virus program there HAS to check the disk as soon as it is inserted. Boot viruses could be detected by automatic scanning of all disks as they are inserted, but it would be easier just to check the boot sector when Ctrl-Alt-Del is pressed. File viruses could be found as well, but this would take untolerably long time in the "worst case" - a disk full of LZEXE-packed programs, which would have to be unpacked before scanning. I doubt many would tolerate that delay whenever a disk is inserted. Just scanning the programs when they are executed seems by far preferable to me. Also - unlike Mac and Amiga, the PC does not generate any signal when a disk is changed - you would need a resident program continously checking the Diskette Change Line Status. - -frisk - -- Fridrik Skulason University of Iceland | Technical Editor of the Virus Bulletin (UK) | Reserved for future expansion E-Mail: frisk@rhi.hi.is Fax: 354-1-28801 | ------------------------------ Date: Sun, 13 Jan 91 12:09:52 +0000 From: dave@tygra.ddmi.com (David Conrad) Subject: Stoned (PC) Many recent postings have made the point that the Stoned virus overlays a sector in the FAT, thus causing damage to the file system. My question, which I *think* I know the answer to is: Couldn't this sector be restored from the second copy of the FAT? I believe that the answer is yes, but I would appreciate if those who study these beasts could confirm this. - -- David R. Conrad dave@tygra.ddmi.com - -- = CAT-TALK Conferencing Network, Computer Conferencing and File Archive = - - 1-313-343-0800, 300/1200/2400/9600 baud, 8/N/1. New users use 'new' - = as a login id. AVAILABLE VIA PC-PURSUIT!!! (City code "MIDET") = E-MAIL Address: dave@DDMI.COM ------------------------------ Date: 13 Jan 91 21:11:09 +0000 From: woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) Subject: Re: SCAN program for IBM's (PC) DOUGB@comsys.byu.edu (Douglas Barlow) writes: > Only one problem with that idea: How can the machine tell when a disk > is inserted? There isn't any type of sensor in IBM floppy drives likee > in the Mac. Fastback senses when a disk is inserted. There is a flag that is used to determine if a disk has been removed or inserted. A program such as this can certainly query that flag. No problem Cheers Woody ------------------------------ Date: Mon, 14 Jan 91 10:06:42 -0800 From: Jeffrey <3501P@NAVPGS.BITNET> Subject: Johsi / Stoned2 (PC) Thanks to everyone on Virus-l for their help with my Virus problem especially Nick F., Michael B., James O., and Carlos J. The response was great, and sorry if I didn't mention you by name if you replied to my note. Our PC was infected by both viruses simultaneously. Stoned-2 sporadically caused the machine not to boot (but didn't display the "stoned" message), and Joshi disabled the machine when we tried to boot up on Jan. 5 1991 (again without the signature message, "type happy birthday joshi to continue..."). Apparently each virus caused the other one to execute incompletely. Both Virii were successfully removed, though the corruption of the partition table from Johsi neccesitated a cable transfer from my Hard-disk to a clean hard-disk. We now have McAfee's program installed. The virus was apparently picked up from someone who accessed a bulletin board and executed some code they had down-loaded. Lastly, someone replying to my note requested a copy of the virus so they could analyze it and tell me more about it (I forgot who, though). Sorry, but I won't send any live code to anyone for any reason. Thanks again for all the help. --Jeffrey ------------------------------ Date: 14 Jan 91 10:32:46 From: jade!brenda@jade.cpsc.ucalgary.ca (Brenda Barabash) Subject: Re: possible macintosh virus (Mac) mwu@teri.bio.uci.edu writes: >Does anyone know of a Macintosh virus that will make all floppy disks >appear to be locked to the computer? At first, we thought the problem >was with the disk drive, but when it started surfacing on other >computers, we've become a little suspicious. Any help would be >appreciated. >Matt Wu >mwu@teri.bio.uci.edu We are also experiencing problems with floppy disks appearing to be locked when they aren't. This is happening on both new disks and old disks. It's definitely got to be a virus. If anyone knows which one please let us know. Brenda Barabash ...{calgary,arcsun}!jade!brenda Jade Simulations ------------------------------ Date: 14 Jan 91 20:22:24 +0000 From: vail@tegra.com (Johnathan Vail) Subject: Re: SCAN program for IBM's (PC) PFKLAMMER@CUDENVER.BITNET (Pete Klammer/303-556-3915) writes: >Only one problem with that idea: How can the machine tell when a disk >is inserted? There isn't any type of sensor in IBM floppy drives like >in the Mac. >Doug Barlow Isn't the write-protect sensor status available for polling? If you constantly (once per clock tick) check the write-protect detector, you could see the "shadow" of the diskette sleeve (write protected or not) as the disk is inserted or removed. I.e., if the detector toggles in any way, a diskette has been either inserted or removed. If I remember correctly the drve has to be selected. Even if this is possible and isn't precluded by door open, etc., it definately won't work while another drive is selected and being used. jv "Live Free or Die, Death is the lesser of the two evils" -- General John Stark _____ | | Johnathan Vail | n1dxg@tegra.com |Tegra| (508) 663-7435 | N1DXG@448.625-(WorldNet) ----- jv@n1dxg.ampr.org {...sun!sunne ..uunet}!tegra!vail ------------------------------ Date: 15 Jan 91 10:52:45 +0000 From: 6500rgls@ucsbuxa.ucsb.edu (Randall S Geels) Subject: Re: Grapes virus? (Mac) A common problem we see when using FORTAN around the lab is that some program which has the same creator id as all your FORTRAN apps is on the same disk. The solution is to: a) Remove the offending application b) Change the creator id of the offending appl with ResEdit then rebuild the desktop file (hold down option-command as the Mac restarts). This will get rid of your problem and cause all you FORTAN appl icons to revert back to the defaultMac application icon. Randy Geels ------------------------------ Date: 15 Jan 91 11:23:00 +0100 From: Klaus Brunnstein Subject: (No) Viruses in Irak's EXOCET? French press (La Liberation) and media reported (Jan.10) in some details that computer viruses could be planted, either in advance or afterwards, in French EXOCET rockets to influence their performance such as to misguide them. Following a report of the German Press Agency (dpa), German media (on Jan.11) were full of reports about "viruses in Hussein's rockets". According to dpa, (unnamed) French computer scientists said: - manufacturers of war material usually implant, "for mere commercial reasons", viruses in exported war electronics to provoke, after some time, faults and "profitable repair work"; - though Irakian weapon computers are "hermetically cut-off from the outside world", computer viruses could be implanted e.g. via "weather data"; - moreover, the built-in computers contain programs which may be triggered remotely; the control system of (French-built) EXOCET rockets could be switched-off from French ships; the only problem would be the mass of weapon computers to be switched-off simultaneously. As usual in events related to malicious code, truth is mixed up with misunderstandings, errors and impossibilities: - the implementation of weapon software makes self-reproducing programs (=viruses) impossible; moreover, it is very im- probable, that such systems may be (re-)programmed remotely; French "experts" with such arguments are non-trustable; - on the other hand, other aspects of "malicious code" may well be present in weapon computers; at least in the test phase, rockets can be destroyed by triggering a self- destruction system remotely; following the well-established principle "never change a running program", such "backdoors" (the proper name for this type of malicious code) could survive the test version; - moreover, French system analysis might well have foreseen scenarios in which to defend against French-made rockets (e.g. EXOCETS); French warships might remotely influence the EXOCET control systems if this remains unchanged by the (Irakian) users of such technology; with equivalent probab- ility, other Western weapon control systems could contain similar self-protection mechanisms (e.g. US' Hawk missiles having been captured in Kuweit) ; - finally, it is well-published (even in non-military period- icals) that and how electronic countermeasures (ECM) may mislead weapon electronics. Some interesting questions following from such "possibilities": - May Irak detect, influence or adapt such weapon software? As software technology is not well-enough developed in Irak (and most part of the Arab world), they probably must rely on foreign experts (as they evidently do in other Hi-Tech areas). - If French EXOCET rockets are remotely controllable: why did the French not warn their "friends" who suffered severe losses through their weaponry (e.g. UK in Falkland crisis, or US in the Iran crisis, see accident of USS STARK)? Did they at least now warn and properly equip their allies in the Arabian desert? For "RISK experienced" experts, it is not surprising that misinformation lives best in threatening situations (such as at the Gulf); apart from general attitudes of newsmedia, computer scientists who nominate their technological constructs (e.g. "self-reproducing programs") in such inadequate terms as "viruses" (see also: "intelligence" etc) are highly responsible for misinterpretation and misunderstanding by less well informed media people and the public! On the other side, authorities and the public only in such threatening circumstances become aware of riskful assumptions inherent in contemporary computer systems. Such unfortunate experience may lead to the cynic assumption that risks may best be conceived by (hopefully: moderately) "ex post" experiencing them, rather than analysing and avoiding them "ex ante". Postscriptum: computer "viruses" may nevertheless play a role in "Operation Desert Shield". There are (yet unconfirmed) news that several thousands PCs (5000?) have been infected by ordinary "computer viruses". This would not be a surprising experience as the soldiers had to "vaste" ample waiting for Jan.15; in the absence of other possibilities for spending free time, computer games (usually a source of "virus" infections) may have played a major psychological role, maybe with some impact on their "ordinary functional behaviour". ------------------------------ Date: Tue, 15 Jan 91 14:20:51 +0200 From: Guy Sirton Subject: TROJAN WARNING: A VM trojan horse (IBM VM/CMS) I have received, a couple of minutes ago, from someone I don't know, a file called 'GAME2 MODULE'. This file appears to be a VM trojan horse which upon execution scans your names file and sends a copy of itself to everyone in it. If you receive a copy of that file do not run it. Guy ------------------------------ End of VIRUS-L Digest [Volume 4 Issue 10] ***************************************** Downloaded From P-80 International Information Systems 304-744-2253