Return-Path: XPUM04@prime-a.central-services.umist.ac.uk Received: from G.SEI.CMU.EDU by ubu.cert.sei.cmu.edu (5.61/2.3) id AA13777; Fri, 1 Jun 90 11:25:55 -0400 Received: from SEI.CMU.EDU by g.sei.cmu.edu (5.61/2.5) id AA20519; Fri, 1 Jun 90 11:25:51 -0400 Received: from nsfnet-relay.ac.uk by sei.cmu.edu (5.61/2.3) id AA00267; Fri, 1 Jun 90 11:25:17 -0400 Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa23056; 1 Jun 90 16:00 BST From: Anthony Appleyard To: KRVW <@NSFnet-Relay.AC.UK:KRVW@sei.cmu.edu> Date: Fri, 01 Jun 90 16:05:24 BST Message-Id: <$TGTWCZCFFBQG at UMPA> Subject: Virus-L vol 0 issue #0429 Virus-L Digest Fri, 29 Apr 88 Volume 0 : Issue #0429 Today's Topics Hardware write protection Testing More info on Miami U's virus woe's another Miami update ** no subject, date = Fri, 29 Apr 88 09:57:52 EST NO "Virus Killer" Viruses MAC VIRUS info - from Loren Miller Viruses in MS-DOS / PC-DOS ** no subject, date = Fri, 29 Apr 88 13:12:00 EDT Flushot Plus - anti-virus/anti-trojan Re: Viruses in MS-DOS / PC-DOS -------------------- Date: Fri, 29 Apr 88 08:33:42 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: Joe Simpson Subject: Hardware write protection Does anyone know whether the write protect hardware in commonly used microcomputers is a) merely a sensor that operates through software mediatation (and is thereby at risk to hostile software) - or - b) or be operated purely at the hardware digital logic gate, for example via a hardware "or" gate? Of course answers to this question must be specific to hardware. I'll start off with the old Apple II 5.25 disk drives. It's hardware here. -------------------- Date: Fri, 29 Apr 88 08:55:56 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Jim Eshleman Subject: Testing Please ignore this test. Jim Eshleman Lehigh University Computing Center -------------------- Date: Fri, 29 Apr 88 09:39:16 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: More info on Miami U's virus woe's I just spoke with Fred Cohen, who was helping Miami University with their Brain virus problems. He gave me some additional information to pass along to the list. First, their PC virus is indeed a *NEW* strain of the Brain virus. It is quite a lot more sophisticated than its ancestor, however. Major differences: 1) It infects COM files as well as system files. The COM files show no changes in file size or in write date when a DIR command is issued. 2) The virus appears to move around a bit. For example, the ASCII message displaying the Pakistani authors' names and addresses *sometimes* appears in the boot sectors, sometimes not. 3) The new Brain virus can now infect hard drives. The previous one could not infect *anything* other than 5 1/4" disks. At Miami U., some BAT files were found which contained commands to copy some infected COM files to the C: drive. Trying to stop a virus like this from spreading, particularly in a typical university computing environment, is proving to be very difficult indeed. They're currently running a program which checks for any of the standard interrupt addresses to change; whereupon they halt the system. This way, at least they get flagged that the virus is on that system. Placing write protect tabs on most of the disks helps, but is not always feasible - particularly in the case of copy protected software like Lotus 1-2-3. That brings me to another point. It seems that, with the current crop of viruses, copy protected software is presenting a serious security problem. If you cannot write protect a disk, then that disk runs a real threat of becoming infected. So, if you must use copy protected software, make sure you boot the system (power down/up - not just ctrl-alt-del; that's easy to fake!) from a write-protected system disk, and then only use your copy protected program. Do not introduce any outside disks into the system during this time. The original Brain virus spread all over the place fairly quickly. This one is much more elaborate, and has been spotted at more than one university already. The need to be extremely cautious cannot be overstressed. Ken - ---------------------------------------------------------------------- = Kenneth R. van Wyk = If found wandering aimlessly, = = User Services Senior Consultant = please feed and return... = = Lehigh University Computing Center =-------------------------------= = Internet: = This just in: = = BITNET: = Humptey Dumptey was pushed! = - ---------------------------------------------------------------------- -------------------- Date: Fri, 29 Apr 88 10:10:27 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: another Miami update One more thing on the new Brain virus - IT CAN INFECT DATA DISKS. That is, non-system disks containing NO EXECUTABLE FILES. It has been found that, if you try to boot an infected data disk, the pc will respond with NON SYSTEM DISK (or something similar). If you then place a bootable disk in the system and press any key, the bootable disk will boot, and the virus will be resident in memory, even if the bootable disk was previously uninfected. Note that this may not work on all pc clones, depending upon how they boot. That is, not all machines will try to boot another disk if you just press any key after getting a NON SYSTEM DISK message. Also, if you CTRL-ALT-DEL to re-boot, the virus will not remain in memory in this case. Hopefully we'll get yet more information on this new virus in the near future... Ken - ---------------------------------------------------------------------- = Kenneth R. van Wyk = If found wandering aimlessly, = = User Services Senior Consultant = please feed and return... = = Lehigh University Computing Center =-------------------------------= = Internet: = This just in: = = BITNET: = Humptey Dumptey was pushed! = - ---------------------------------------------------------------------- -------------------- Date: Fri, 29 Apr 88 09:57:52 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: DG5EOPER@MIAMIU We've been discussing how to thoroughly clean up a viral infection so that there aren't any remaining copies hangning around to infect the labs all over again. Why not introduce a virus-killer VIRUS? A program that spreads itself just like a virus with a sole purpose of hunting down a particular virus and nullifying it? It would propigate itself and spread just as quickly as a virus and would clean up up student's disks even if they didn't know they were infected. Maybe this is not a good idea. I am rather new to the subject, but find it interesting. Anyone's comments on this idea would be welcomed. David Geis -------------------- Date: Fri, 29 Apr 88 12:55:00 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: UJWSIEC@VAX1.CC.LEHIGH.EDU Subject: NO "Virus Killer" Viruses >Why not introduce a virus-killer VIRUS? >A program that spreads itself just like a virus with a sole purpose >of hunting down a particular virus and nullifying it? It would propigate >itself and spread just as quickly as a virus and would clean up up >student's disks even if they didn't know they were infected. >Maybe this is not a good idea. No, its not a good idea... "Vaccines" should not be viruses themselves. I agree that a program should be developed that would hunt down and kill a particular strain of virus. But the program should not be a virus itself otherwise your wonderful cure, in the future, might become an annoying pain in the ?#s. Once administered, you have no control of it. A virus uncontrollably propagating through computer systems could, as a side effect, cause software to malfunction, take up computing resources, etc. Moreover, you have to put out a new "killer vaccine virus" for every new regular virus, and soon systems would be overloaded with protection viruses that would probably fight amonst themselves and prevent a computer from functioning optimally. - ---------------------------------------------------------------------------- ujwsiec@vax1.cc.lehigh.edu Joe Sieczkowski {ihnp4}!c11ux!lehi3b15!joes AI Lab, CSEE Department jws5@lehigh.bitnet Lehigh University Packard Lab #19 Bethlehem, PA 18015 -------------------------------------------------------------------- "Yes...It was a dark and stormy night that a party of three and myself found, tracked, and destroyed the Lehigh Virus." --------------------------------------------------------- -------------------- Date: Fri, 29 Apr 88 14:27:21 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Jim Eshleman Subject: MAC VIRUS info - from Loren Miller The XWell Mailer does not like addresses that span lines so Loren's posting got sent to me: From: "Loren Miller, Senior Large-Systems Consultant" Please refrain from using addresses like this until I can get the beast fixed. I am working on it. Many thanks. Here's Loren's posting below. Sorry for the delay in getting this to the list. /jce - ---------------- Start of mail from Loren Miller ------------------- Subject: MAC VIRUS info -- relayed from INFO-MAC Date: Tue 26 Apr 88 03:36:16-EDT From: "Vin McLellan" Subject: Virus Sores and Scores Relayed from: INFO-MAC Digest Saturday, 23 Apr 1988 Volume 6 : Issue 40 From jpd@eecs.nwu.edu Mon Apr 18 10:11:09 1988 Subject: The Scores Virus Date: 18 Apr 88 16:11:09 GMT My colleague Bob Hablutzel got a copy of the Scores virus last Thursday and disassembled it, and I've been studying and testing it ever since. So far I've reverse-engineered about half the code and have a thorough understanding of how it works. This note is a preliminary report on what I know so far, after four days of research. It also outlines plans for a disinfectant program. The virus is definitely targeted against applications with signatures VULT and ERIC. I don't know if any applications with these signatures exist or are planned to be released. The virus infects your system folder when you run an infected program. The virus lies dormant for two days after your system folder is first infected. After two, four, and seven days various parts wake up and begin doing their dirty work. Two days after the initial infection the virus begins to spread to other applications. I haven't completely finished figuring out this mechanism, but it appears that only applications that are actually run are candidates for infection. After four days the second part of the virus wakes up. It begins to watch for the VULT and ERIC applications. Whenever VULT or ERIC is run it bombs after 25 minutes of use. If you don't have a debugger installed you'll get a system bomb with ID=12. If you have MacsBug installed you'll get a user break. After seven days the third part of the virus wakes up. Whenever VULT is run the virus waits for 15 minutes, then causes any attempt to write a disk file to bomb. If you don't do any writes for another 10 minutes the application will bomb anyway, as described in the previous paragraph. There's also more code to force a bomb after 45 minutes, but I can't see any way that this code can be reached, given the forced bomb after 25 minutes. The virus identifies VULT and ERIC by checking to see if the application contains any resources of type VULT or ERIC. Applications with signatures VULT and ERIC normally contain these resources, but other applications normally don't. I verified the behaviour of the virus by using ResEdit to add empty resources of types VULT and ERIC to the TeachText application. TeachText bombed as described above on an infected system, even though TeachText itself was not infected! While running my experiments I was in ResEdit on the infected system and heard the disk whir. Sure enough, ResEdit was infected. I've been running on an infected system with an infected ResEdit for three days. I reset the system clock to fool the various parts of the virus into thinking it was time for them to wake up. The Finder has also become infected. ResEdit, Finder, and the rest of the system seem to be functioning normally. Only my version of TeachText modified to look like VULT or ERIC has been affected by the virus. If you repeat any of these experiments be very careful to isolate the virus. I'm using a separate dual floppy SE to perform my experiments, and I've carefully labelled and isolated all the floppies I'm using. My main machine is an SE with a hard drive, where I have MPW and my other tools installed. It's OK to look at infected files on the main machine (e.g. with ResEqual, DumpCode, etc.), but don't run any infected applications on the main machine - that's how it installs itself and spreads. Children should not attempt this without adult supervision :-) An infected application contains an extra CODE resource of size 7026, numbered two higher than the previous highest numbered CODE resource. Bytes 16-23 of CODE resource number 0 are changed to the following: 0008 3F3C nnnn A9F0 where nnnn is the number of the new CODE resource. You can repair an infected application by replacing bytes 16-23 of CODE 0 by bytes 2-9 of CODE nnnn, then deleting CODE nnnn. I've tried this using ResEdit on an infected version of itself, and it works. The MPW utility ResEqual reports that the result is identical to the original uninfected version. The virus creates two new invisible files named Desktop (type INIT) and Scores (type RDEV) in your system folder, and adds resources to the files System, Note Pad File, and Scrapbook File. Note Pad File and Scrapbook File are created if they don't already exist. Note Pad File is changed to type INIT, and Scrapbook File is changed to type RDEV. Both of these files normally have file type ZSYS. The icons for these two files change from the usual little Macintosh to the generic plain document icon. Checking your system folder for this change is the easiest way to detect that you're infected. Copies of the following five resources are created: Type ID Size Files ----- ----- ----- ------------------------------------- INIT 6 772 System, Note Pad File, Scrapbook File INIT 10 1020 System, Desktop, Scores INIT 17 480 System, Scrapbook File atpl 128 2410 System, Desktop, Scores DATA -4001 7026 System, Desktop, Scores A disinfectant program would have to repair all infected applications and clean up the system folder, undoing the damage described above. I don't yet know exactly which files can be infected, but I know for sure that Finder (file type FNDR) can get infected, and that applications (file type APPL) can get infected. For safest results the disinfectant should examine and disinfect the resource forks of all the files on the disk. I recommend the following algorithm: Scan the entire file hierarchy on the disk, and for each file on the disk check it's resource fork. Delete any and all resources whose type, ID, and size match the table above. Delete all files whose resorce forks become empty after this operation. If the resource fork's highest numbered CODE resource is numbered two more than the next highest numbered CODE resource, and if it's size is 7026, then patch the CODE 0 resource as described above, and delete the highest numbered CODE resource. Also examine all files named Note Pad File and Scrapbook File. If their file type is INIT or RDEV, change it to ZSYS. I'm fairly confident that a disinfectant program implemented using the algorithm above would sucessfully eradicate the virus from a disk, restore all applications to their original uninfected state, and not harm any non-viral software on the disk. It should work even on disks with multiple infected system folders. I also believe that it should work even if run on an infected system, and even if the disinfectant program becomes infected itself! There's a small chance that it could delete too many resources, and hence damage some other application, but that's a small price to pay for a clean system. Getting rid of a virus is tricky, even with a disinfectant program. The disinfectant program should be placed on a floppy disk along with a system folder. Make a backup copy of this disk. The machine should be booted using the startup disk you just made, and then the disinfectant should be run on all the hard drives and floppies in your collection, including the backup copy of the startup disk you just made. Don't run any other programs or boot from any other disks while disinfecting - you might get reinfected. When you're all done, reboot from some other (disinfected) disk and immediately erase the startup disk you used to do the disinfecting, which may be (and probably is) infected itself. This should absolutely, positively get rid of all traces of the virus. The backup disk you made and disinfected should contain an uninfected copy of the disinfectant program in case you need to use it again. There are at least two red herrings in the virus. It uses a resource of type 'atpl', which is usually some sort of AppleTalk resource. As far as I can tell, however, the virus does not attempt to spread itself over networks. The 'atpl' resource is used for something else entirely. This is not a bug. Also, the virus creates the file Desktop in your system folder. This is done on purpose. It is not a failed attempt to modify the Finder's Desktop file in the root directory. The file is used by the virus, and has nothing to do with the Finder. I don't know why the virus seems to cause reported problems with MacDraw, printing, etc. Perhaps it's a memory problem - the virus permanently allocates 16,874 bytes of memory at system startup (four blocks in the system heap of sizes 772, 40, 8, and 334, and one bock at BufPtr of size 15360). I've only found one possible bug in the virus code, and it looks pretty harmless. The code is very sophisticated, however, and I can easily understand how I might have overlooked a bug, or how it might interact in strange unintended ways with other applications and parts of the system. When we've finished completely cracking this virus we'll probably distribute another report. I've posted these preliminary results now to get the information out as quickly as possible. We also hope to write the disinfectant program, if someone else doesn't write it first. I've decided not to distribute detailed information on how this virus works. I'll distribute detailed technical information about what it does and how to get rid of it, but not internal details. This was a very difficult decision to make, because normally I firmly believe in the enormous benifit of the free exchange of code and information. The Scores virus is a very interesting and complicated piece of code, I've learned a great deal about the Mac by studying it, and I'm sure other people could learn a great deal from it too. But I don't want to teach twisted minds how to write these incredibly nasty bits of code. If I write the disinfectant program, however, I will distribute its source, because I do want to teach untwisted minds how to get rid of them. So please don't bombard me with requests for more information. You may be the nicest, most honest, incredibly important person, but I won't tell you how it works. I'll make only two exceptions, and that's for a very few of my colleagues at Northwestern University, and for qualified representatives of Apple Computer. Thanks to Howard Upchurch for giving us a copy of the virus, and to Bob Hablutzel for helping me crack it. John Norstad Northwestern University Academic Computing and Network Services 2129 Sheridan Road Evanston, IL 60208 Bitnet: JLN@NUACC Internet: JLN@NUACC.ACNS.NWU.EDU Monday morning, April 18, 1988. -------------------- Date: Fri, 29 Apr 88 14:46:30 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "David M. Chess 862-2245" Subject: Viruses in MS-DOS / PC-DOS I know of five actual viruses: - The "brain" virus, that spreads between boot sectors of floppy diskettes, and apparently does no intentional damage (although I've heard that it has a bug or two that can sometimes cause cross-linked FATs). - The "Jerusalem" virus, that spreads between executable files (both COM and EXE), and that will erase any file that you try to execute on Friday the 13th (starting on May 13 this year). It has a bug, in that it will install a copy of itself in any EXE file you run, even if the file is already infected, so your EXE files will grow very quickly. (COM files get infected only once.) - The COMMAND.COM virus that showed up at Lehigh, and led to this list; it spreads between COMMAND.COMs, changes the date on infected COMMAND.COMs, and trashes all the data it can find after spreading four times. (I've never actually seen a copy of this one.) - Two "april fools" viruses (one for COM files and one for EXE files), that cause your machine to hang up at various intervals, and print annoying messages (one of them will print the message "HA HA HA YOU HAVE A VIRUS" every time you execute any file). I haven't heard any reports of these two showing up in the real world. The COMMAND.COM virus is in a sense the worst, in that it seems to be the only one that will really destroy valuable information. Has anyone heard of it appearing anywhere since it was first Busted? Has anyone heard of any other viruses (not just Trojan Horses) for this environment? I'd especially like more details about the Miami variant of "Brain" that Ken reported above. Has it been isolated and disassembled? Various people asked about write-protection; I'm not a hardware techie, but I know that the write protection on all the genuine IBM floppy drives that I know of is in fact in hardware. A program can write to a write-protected floppy only if the drive itself is broken, or has been modified. There's a microswitch of some kind that, I believe, disables the Write line on the drive. Dave Chess Watson Research Center * Any opinions or information contained herein are my own, * and not Official Statements of any company I might happen * to work for. -------------------- Date: Fri, 29 Apr 88 13:12:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Joseph M. Beckman" In-Reply-To: Message of 27 Apr 88 22:38 EDT from "Loren K Keim -- Lehigh University" I recently listened to the ABC broadcast on viruses. Fred Cohen stated that the Hebrew U. virus propagated to the Mossad (Israeli intelligence agency) and to the United States. Anybody else here of this happening? Any ideas on where in the United States the infection is alleged to have occurred? Will someone who attended the LaSalle talk post a summary to this forum? Which Mac virus is the "Idiot" virus? Joseph -------------------- Date: Fri, 29 Apr 88 15:39:56 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List Comments: Resent-From: KPETERSEN@SIMTEL20.ARPA Comments: Originally-From: phri!dasys1!wfp@NYU.EDU (William Phillips) From: KPETERSEN@SIMTEL20.ARPA Subject: Flushot Plus - anti-virus/anti-trojan The following is a response from Ross Greenberg, author of Flushot+, to several complaints posted to the comp.binaries.ibm.pc newsgroup over the past few days: " After examining the FLUSHOT+ code, I noticed that a comment was left in which would allow the brief bug to bite. That has since been fixed. The current release of FLU_SHOT+ is at Version 1.2, coming to a USENET site near you soon. As to the character who thinks that me charging ten bucks is absurd, please tell him I agree. His option, of course, is to not use the code. The $10 fee entitles him to use it. Obviously, he's using an unregistered copy. Tell him I sincerely hope that he has good luck using the $200 commercial protection programs. Oh! And please have him tear up my phone number!" According to Ross, Flushot+ v 1.2 will be posted via SIMTEL20 within the next few days. -- William Phillips {allegra,philabs,cmcl2}!phri\ Big Electric Cat Public Unix {bellcore,cmcl2}!cucard!dasys1!wfp New York, NY, USA !!! JUST SAY "NO" TO OS/2 !!! -------------------- Date: Fri, 29 Apr 88 15:52:45 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Terry Sanderson Subject: Re: Viruses in MS-DOS / PC-DOS In-Reply-To: Message of Fri, 29 Apr 88 14:46:30 EDT from Hi, I would just like to clarify a point about write-protecting IBM PC type floppy disks. If they are write-protected, they CANNOT be written to. A microswitch or a photo-transistor senses whether or not the copy protect hole is covered. If it is, no matter what you do, the hardware logic disables the "write mechanism" (as I will call it), and you cannot write to the disk. This logic is simple TTL-type stuff, which is NOT programmable by any type of fancy programming. Hope this helps. - ------------------------------------------------------------------------- Terry Sanderson P. Eng. Micro Systems Analyst University of Toronto Computing Services sanders@utoronto.bitnet sanders@gpu.utcs.toronto.edu Just Remember.....It's all fun until somebody loses an eye. - -------------------------------------------------------------------------