VIRUS-L Digest Monday, 30 Oct 1989 Volume 2 : Issue 226 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., and sent to VIRUS-L@IBM1.CC.LEHIGH.EDU (that's LEHIIBM1.BITNET for BITNET folks). Information on accessing anti-virus, document, and back-issue archives is distributed periodically on the list. Administrative mail (comments, suggestions, and so forth) should be sent to me at: krvw@SEI.CMU.EDU. - Ken van Wyk Today's Topics: Virus scanning on PCs? Re: Protection in Operating Systems How to Become a Virus Expert (Mac) Re: Lode [sic] Runner Virus (Apple) Where are the Sophisticated Viruses? 2608- possible virus? (AMIGA) BOOTCHEK (possible virus) (PC) Defensive computing... Re: Obj - anti-virus (PC) MacDraw II 1.1/GateKeeper 1.1 problems (Mac) Self-checking programs (PC anti-virus protection) --------------------------------------------------------------------------- Date: 26 Oct 89 16:07:15 +0000 From: davidsen@crdos1.crd.ge.com (Wm E Davidsen Jr) Subject: Virus scanning on PCs? Do scanning programs (in particular scanv45) check video memory for a virus? I once developed a program which installed itself in the 2nd page of video memory because there was nowhere else for it. Not a virus, just a fix for some BIOS bugs, but someone else could hide a virus there if they were so inclined. Very little software ever uses any page but the first. Oh, if the video pages were swapped and then output to the serial port was done, the display was really pretty! - -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon ------------------------------ Date: 26 Oct 89 16:03:14 +0000 From: davidsen@crdos1.crd.ge.com (Wm E Davidsen Jr) Subject: Re: Protection in Operating Systems In article <0001.8910231129.AA06880@ge.sei.cmu.edu>, WHMurray@DOCKMASTER.ARPA w rites: | However, as it relates to viruses, the big difference between them | today is the number and nature of uses and users. If UNIX were being | used for the same things and by the same number of users as DOS, it | would be just as vulnerable. I don't see how that relates to the technical issues. DOS allows any program to write anywhere in memory, including over the o/s. UNIX does not. DOS allows any program to write directly on the hard disk. UNIX does not. DOS allows any program to write to a floppy disk. UNIX may or may not, but in general UNIX seldom uses floppies at all, and when it does the formats are usually not susceptable to changing one file without changing others (ie. tar, cpio). DOS allows any program to modify any file on any disk. UNIX does not. This is not a case of one being "better" than another, just a case of inherent characteristics of the systems. Yes, if someone is running UNIX on an 8088 machine many of the protections are bypassed. - -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon ------------------------------ Date: Fri, 27 Oct 89 15:48:39 -0500 From: Joe McMahon Subject: How to Become a Virus Expert (Mac) 1) Read this digest. There are probably more contributors here than in any other spot around. 2) Study Inside Macintosh, particularly the sections on ROM patches, INITs, and VBL tasks. These are the principle attack vectors for Mac viruses. 3) Become adept at using TMON, Macsbug, or some other disassembler/ debugger. This will help you track down what is happening during a given infection. I don't know of anything equivalent to the "microscope and tweezers" report on the Internet worm for any Mac virus, so I can't refer you to any articles which talk about the mechanics of any virus in great detail. The only one which might be of use to you is an article in MacTutor magazine (last year? check the MacTutor anthologies) which has a description of an nVIR infection and a primitive but useful removal program. --- Joe M. ------------------------------ Date: Fri, 27 Oct 89 14:59:56 -0700 From: nparker@cie.uoregon.edu Subject: Re: Lode [sic] Runner Virus (Apple) In article <0010.8910231129.AA06880@ge.sei.cmu.edu>, davidbrierley@lynx.northeastern.edu posted an article about the Apple IIGS LOAD RUNNER virus, and asked the following questions: > [...] (1) Does any reader of VIRUS-L >know if the French expression "non-destructeur" means >"non-destructive" or "indestructible?" (2)Could anyone post a >version of VIRUS.KILLER (source code follows the report) written >in BASIC? (It could be posted here or to Info-apple@brl.mil) >(3) Because the university does not import VIRUS ALERT I >have not posted this report to it, for fear of replication. Could >someone post this message to VIRUS ALERT if it has not appeared there >already? Way back in July, I found this beasty lurking on some of my disks, and did a fairly thorough analysis of it, which culminated in the writing of the program which appeared at the end of the original article (copies of the program are available from me at the addresses below). I think I can provide some answers and information. I speak no French, but I think I can say after looking at the virus code that whatever "non-destructeur" really means, it OUGHT to mean "non-destructive." The damage done by this virus is minimal--it destroys only the boot blocks of a 3.5" disk (5.25" disks and hard disks seem to be immune), leaving all the files and directories intact (it can, however, render some copy-protected games unusable). My impression is that the author of the virus was thinking something like "I'm going to release this virus, which is a really bad thing to do, but it will be all right if it doesn't do any real damage." This impression seems to be reinforced by the fact that LOAD RUNNER has a finite life-span built in-- at the same time it starts damaging, it also stops propagating, and being a boot block virus, it destroys copies of itself when it destroys the boot blocks. Posting a BASIC version of VIRUS.KILLER isn't really practical--the steps that it takes to eliminate LOAD RUNNER are pretty much beyond the capabilities of poor old Applesoft BASIC. Any BASIC program would probably be just a short menu routine wrapped around a machine-language core which would be essentially the same as the current program. It's probably a bit late for a VIRUS ALERT message. I first saw LOAD RUNNER back in July (at which point it had probably already been around for a while), and if memory serves, the article quoted in the original posting was first posted sometime around August or September. Besides, LOAD RUNNER's trigger dates are any time between Oct. 1 and Dec. 31 inclusive, so any infected users have probably aready seen it run its course, and an alert now would be somewhat akin to locking the proverbial barn door after the horse has escaped. - ------------------------- A summary of LOAD RUNNER: Entry................: LOAD RUNNER Alias(es)............: (none) Virus detection when.: July, 1989 where.: Various places in the US and Canada Classifications......: Boot block virus Length of virus......: 1024 bytes (all of blocks 0 and 1) Operating system(s)..: ProDOS 8, ProDOS 16, GS/OS Version/release......: all Computer model(s)....: Apple IIGS Identification.......: Boot blocks are changed. System: Virus copies itself to $E1/BC00 thru $E1/BFFF. Type of infection....: Virus resides in the boot blocks of a 3.5" disk. Copies itself to $E1/BC00 when disk is booted. Copies itself to disk in slot 5, drive 1 when CONTROL-APPLE-RESET is pressed. Propagation routine gains control by patching undocumented system vector in Memory Manager. Original boot blocks are not saved--virus contains code to emulate standard boot process. Infection trigger....: Infects disks in slot 5, drive 1 only. Infection of disks occurs when CONTROL-APPLE-RESET is pressed. Infection of host machine occurs when an infected disk is booted. Interrupts hooked....: n/a Damage...............: Erases boot blocks of disk in slot 5, drive 1. No files are damaged. Damage trigger.......: Any date between Oct. 1 and Dec. 31 inclusive, of any year. Damage occurs when an infected disk is booted. If damage occurs, further infection will not occur. (Note that the damage process wipes the virus off of the infected disk.) Acknowledgment: Location.............: University of Oregon Documented by........: Neil Parker (nparker@cie.uoregon.edu) Date.................: 27-October-1989 Personal opinion: A rather wimpy virus. Damage is minimal and easily repaired. The virus code uses no special tricks, except for the method used to survive and gain control after RESET. All in all, it's not worth making much of a fuss about (except to the extent that ALL viruses are worth making a fuss about). (This is my first posting to comp.virus/VIRUS-L. Did I get the report format right?) Neil Parker nparker@cie.uoregon.edu parker@astro.uoregon.edu DISCLAIMER: Opinions are mine alone. ------------------------------ Date: Sat, 28 Oct 89 01:46:00 -0400 From: TMPLee@DOCKMASTER.ARPA Subject: Where are the Sophisticated Viruses? For various reasons I have been behind in my reading of Virus-L, and so I found myself skimming something like the last dozen issues of the digest all at once. I was struck by something: are we lucky and there are no competent, sophisticated writers of viruses out there, or are we just fooling ourselves? Although the details of most of the virus prevention programs (e.g., Gatekeeper for the Mac) haven't been discussed at all or recently enough that I remember them, it seems to me that any virus writer willing to get his hands dirty and write code that directly uses the I/O hardware (rather than rely on the operating system) should be able to write a virus that could not be detected by any of the preventative defenses that are supposed to be watching for suspicious writes and that would only be detected after-the-fact by reactive defenses that did a lot of robust integrity checksumming. (Looking for file modification dates would be useless since the virus would of course not be polite enough to update any directories; scanning programs would be useless on the assumption that the virus remains undetected until it goes off so no-one would have included a signature to scan for.) Suppose some suitably motivated person wrote such a virus and set the trigger for a year or two away (provided the virus had been executed and/or propagated some number of times) -- how far within the IBM-PC or Mac community would it likely spread before the trigger fired? How do we know one or more such beasts isn't already out there, just biding its time? ------------------------------ Date: 29 Oct 89 00:16:58 +0000 From: n8735053@unicorn.wwu.edu (Iain Davidson) Subject: 2608- possible virus? (AMIGA) In article <0007.8910261143.AA02119@ge.sei.cmu.edu> okay@tafs.mitre.org (Okay S J) writes: >I received this from Amiga-relay this morning....From all reports, it >appears that Xeno, if it is a virus, is the 1st non-boot infector virus >in the Amiga community. All the others I've seen so far live in the boot >sector and most Amiga anti-virals seem to only worry about the boot sector >and in RAM at the time. >I'll cross-post anything I hear from either side to their respective >lists. > >Stephen Okay Technical Aide, The MITRE Corporation >x6737 OKAY@TAFS.MITRE.ORG/m20836@mwvm.mitre.org [Text deleted] Well, while up in Vancouver, BC at an Amiga Users Group meeting, a interesting thing was demostrated..... I call it the "2608" virus. (don't know the offical name). It worked like the IRQ virus attaching itself to the first executable in the startup-sequence. But with a slight twist. It would copy the found executable to devs:" " and copy itself into the old name in the "C" directory (size 2608 bytes). The way that it was noticed was that the person had typed "echo blah blah" in his startup-sequence, but in "C" directory he had "echo" called "Echo" . One day he had noticed that the command was in all lowercase and 2608 bytes long (not the usual 653? bytes long). He also noticed that he had a extra file " " in the devs: directory the same size as the echo command. Evidently, the virus copyed itself to the command location, then copied the command to the devs: directory. Everytime the command was executed it would call the virus-program which in turn would call the REAL command. Appearing as though all worked fine. Another interesting thing.... about every 5 times he warm-boot, a message would come up saying something like "Virus Exterminator.. blah blah.... Virus by Blah Blah (i don't remember the specifics)" this only appeared for a brief second ... not long enough to read the whole thing. Anybody else have any info on this ? - -Iain Davidson IAIN@wwu.edu n8735053@unicorn.wwu.edu uw-beaver!wwu.edu!IAIN ------------------------------ Date: Sun, 29 Oct 89 00:19:00 -0500 From: PERRY@northeastern.edu Subject: BOOTCHEK (possible virus) (PC) HI! This list provides a service of great benefit to many many computer users! Congratulations. I recently downloaded BootChek 1.0 from Simtel20. With increasing frequency it has been saying my boot sector has been modified. I have allowed it to replace the "corrupt" boot sector on each of these occaisions. The complaint only happens on cold boots and not everytime the machine is cold booted. BootCHek lists the offset at which the sector starts to be different as 11 (on other occaisions 17, and most recently as 6.) The most recent time this symptom occured was after three reboots (each of which set off bootchek) Viruscanv42 shows no viruses on my 10 meg hard disk. I also run flushot plus ver 1.5 and UNVIRUS6 from Simtel20. These are running on my 4.77mhz IBM PC Clone with a DTK BIOS. I am concerned that BootChek has a bug, a virus, or both. Would someone please respond ASAP with any thoughts or info on my concerns! Jeffrey Perry Northeastern University PC Users Group PS. I have the corrupt.hex file produced by each of the five times bootchek claimed my boot sector had been changed. If anyone wants to analyze them I would be glad to send them along. PSS. I have backed up my Hard Disk so I am ready for just about anything BUT I hope it is merely a bug in bootchek!!! ------------------------------ Date: Sun, 29 Oct 89 09:33:05 -0500 From: dmg@lid.mitre.org (David Gursky) Subject: Defensive computing... Just a "friendly reminder" to the readers of Virus-L (and apologies to those who get both RISKS and Virus-L, and saw this note in RISKS some weeks ago). There are several key dates that electronic vandals like to strike on: Any Friday the 13th, April Fool's Day, and Halloween. The latter is Tuesday, and it would be exceedingly prudent (not to mention cheap insurance) for people to back up their disks in the event they are infected with a virus, or are unwittingly using a Trojan Horse, equipped with a time-bomb set for Halloween. A backup will not prevent the time-bomb from going off, nor will it remove the virus or Trojan Horse from your system, but it will be invaluable in recovering any data you may loose. ------------------------------ Date: 29 Oct 89 19:56:08 +0000 From: kerchen@iris.ucdavis.edu (Paul Kerchen) Subject: Re: Obj - anti-virus (PC) In article <0003.8910271112.AA11335@ge.sei.cmu.edu> s0703pdb@semassu.bitnet (Pa ul Bienvenue) writes: > [stuff about distributing OBJ files as anti-viral technique] > > It's a nice idea, but it wouldn't really stop virus writers, just >make life a little more difficult for them. That's the whole point: to make life more difficult for virus writers. The whole virus problem is NP complete, meaning that there is no way to ever completely solve it. For every protection scheme, there is a way to break it; just look at the copy protection war that has been going on for years now. Anyone who's in the virus business (either attacking or defending) had better know that they can never hope to create a virus/vaccine which is completely bulletproof. There will always be someone on the other side who will figure out a scheme to counter that virus/vaccine. Therefore, no solution should ever be ruled out simply on the basis that it cannot stop virus writers (I know that this isn`t the only reason Paul gave, but I just wanted to make this point). Stopping virus writers isn`t going to happen in software or hardware, but in societal pressure. (Perhaps some future first lady will make that her project: viruses--just say no. :-) ) Paul Kerchen | kerchen@iris.ucdavis.edu ------------------------------ Date: Sun, 29 Oct 89 15:14:00 -0500 From: HONORS@kuhub.cc.ukans.edu Subject: MacDraw II 1.1/GateKeeper 1.1 problems (Mac) Question: Does GateKeeper 1.1 have problems with MacDraw 1.1? Our installation has version 1.1 running on a machine protected with GateKeeper. Whenever we try to save a previously opened document, we get a dialog box saying "File not Found". SOMETHING is saved, because the changes are there when we open the document; but MacDraw does not recognize this. I've pretty much narrowed the trouble down to either GateKeeper or a virus in MacDraw II, because when I use the override feature on GateKeeper, MacDraw works fine. But even when I give MacDraw II 1.1 full privliges, (Res/File on Other, System, and Self) it still gives the File Not Found dialog box. Has anyone else had this problem? Travis Butler at HONORS@kuhub.cc.ukans.edu ------------------------------ Date: Sun, 29 Oct 89 21:13:00 -0500 From: JHSangster@DOCKMASTER.ARPA Subject: Self-checking programs (PC anti-virus protection) Bob McCabe of the University of Guelph wrote (27 Oct) "it struck me that it should be possible to work out a scheme by which any program could check itself at load time for infection..." This is quite true, and in fact there is at least one commercial anti-virus product out there which implements this idea. (There may well be others.) The one I have noticed is VACCINATE PLUS, by Computer Integrity Corp. of Boulder Colorado. Along with several other anti-viral tools, this product includes an "INSTALL" utility which "vaccinates" the boot track and all executables on the disk. "Vaccination" consists of appending a cryptographic "seal" checking module (smaller than a typical virus!) and patching the load module header so that this module executes first, then passes control to the original application program if the program is "clean", otherwise halting and issuing a warning message. According to Larry Martin of Computer Integrity Corp., the resulting protection is entirely transparent to the end user, i.e. no keystrokes are required, you just run a program in the normal way, and it runs normally unless the file has been infected, in which case it issues the warning and returns control to DOS. Computer Integrity Corp. can be reached by phone at (303) 449-7377 (FAX number is 449-7477). Their address is PO Box 17721, Boulder CO 80308. (I have no commercial connection with this company.) Regarding the specific scheme Bob McCabe described, i.e. computing a CRC on a program and then encrypting it, it is fairly well known that since the CRC process is linear over the binary field (commonly called "GF(2)" by algebraists), it is little more than a high school algebra exercise to make your desired changes to the program, then make a few more bits' worth of additional changes (determined by simple linear algebra over GF(2)) which restore the CRC bits to their former value so that they will still perfectly match the bits recovered from the encrypted CRC -- thus defeating the protection scheme. The only trick, in an executable program, is to set up the code so that the additional bits you have to diddle to restore the CRC do not adversely affect execution, e.g. include a branch around them or whatever suits your fancy. The basic idea is OK, but you need to use a "one-way" hash function, rather than something readily invertible like a linear CRC. See Dorothy Denning's book or any of a number of recent articles for ideas on better hash functions, or use one of the "chained" modes of the DES which have been proposed for detecting data alterations. The key (so to speak) property that is needed is that it must be difficult to construct a second message or in this case computer program with the same value for the hashing function's output. - -John Sangster SPHINX Technologies, Incorporated (617) 235-8801 P.O. Box 81287 Wellesley Hills, MA 02181 ------------------------------ End of VIRUS-L Digest ********************* Downloaded From P-80 International Information Systems 304-744-2253