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 AA03492; Tue, 19 Jun 90 07:10:01 -0400 Received: from SEI.CMU.EDU by g.sei.cmu.edu (5.61/2.5) id AA28570; Tue, 19 Jun 90 07:09:58 -0400 Received: from nsfnet-relay.ac.uk by sei.cmu.edu (5.61/2.3) id AA01567; Tue, 19 Jun 90 07:09:39 -0400 Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa05366; 19 Jun 90 9:40 BST From: Anthony Appleyard To: DAVIDF@cs.heriot-watt.ac.uk Date: Tue, 19 Jun 90 09:45:08 BST Message-Id: <$TGWFCWKBBCWF at UMPA> Subject: Here is Virus-L vol 0 #0998 Virus-L Digest Thu, 15 Sep 88, Volume 0 : Issue #0998 Today's Topics Popular Level Paper ------------------------------ Date: Thu, 15 Sep 88 10:29:56 CDT From: Len Levine Subject: Popular Level Paper Not to be outdone by a couple of mere students, I am submitting my paper that was first entered here in rough form. It was published this week in the UWM campus computing newsletter and is at a lower level than the Keil and Lee paper that I read here this week. It serves a different audience. Thanks to those of you who made suggestions, I took some of them. [Potential Virus Attack] by L. P. Levine There has been talk recently about the presence of virus programs running on office computers. There now are a significant number of such machines on this campus. If a virus does infect a significant number of machines here it is possible that many office IBM compatible (or Macintosh) machines will fail or lose files on the same day. It will be a very unpleasant time and our professional staff will be overwhelmed by requests for help and will take some time (weeks) to get the recovery process under way. Most of us are unaware of how dependent we have become on these desktop machines and how much we will be affected by the loss of data that may ensue. Perhaps we should define some terms here. There are two computer program elements that need definition. First is a Trojan Horse program. This sort of program, like its historical namesake, has two functions. On the "outside" it does something to encourage the user to run it. Typically, Trojan Horse programs may be games, small support programs, such as directory listers, or even, in one case already on record, commercial software packages. On the "inside" however, the program does something unfriendly to the computer on which it runs. Some Trojan Horse programs delete files, some reset clocks, some mark disk areas as unusable and some change the operating system of the computer. The most destructive of them cause other programs to change their nature, usually by adding instructions to those programs that make them Trojan Horse programs as well. These added instructions are often called computer viruses. A computer virus is a portion of a program that does not run alone, but requires another program to support it. In this sense it is like a biological virus, requiring a cell for a host in order to allow it to work. Since it does not run alone, it does not appear in any directory and is never directly executed. It moves from program to program by making each program to which it is attached (infected so to speak) a Trojan Horse program for further software infection. A virus may be programmed to appear to do nothing for a long time (remain dormant), and then, when some trigger event occurs, do whatever it is programmed to do. The movement of a virus program element from machine to machine occurs when a Trojan Horse program is run on that machine. If a virus program element infects our office machines, then not only will the company's office machines be affected, but the home machines that many staff members now have will also have their files affected by the very same virus, and at the same time. If you are preparing a paper for publication, writing or working on an exam, or preparing some important correspondence, you may well find that your machine readable copies of that material will become unusable both at home and at the office. This paper discusses some evasive action that you can do now to prepare for the return of your machine to working order. What I am recommending in this paper is no more than good housekeeping and is a practice that each of us should do anyhow, with or without the threat of some mysterious computer virus. What I will discuss for the next few paragraphs applies to users who have machines with either a floppy disk drive and a hard disk drive or have two floppy disk drives on their computers. Step one: Locate the original source disks for the operating system you are now using on your computer. This may no longer be the system delivered with your machine, you may well have had an upgrade. DO NOT PUT THESE DISKS INTO YOUR FLOPPY DRIVE YET. Secure a few dozen writelock tabs and put one on each of the delivery system disks. (When you hold a disk upright the right side of the disk has a 1/4" square notch cut into the black paper jacket. The write-lock tabs are black or aluminum colored gummed paper tags about 3/4" X 1/2" that can be stuck over the edge of the disk covering the front and back of this notch. When that tab is in place it is not possible for the computer to write information onto a floppy disk.) Only after you have write-locked these disks should you put the disk into the computer and compare the system on that disk with the system you are using. STOP AND READ THE NEXT SENTENCE! The simple act of executing the DIR command on an unlocked disk is enough to infect that disk with a virus if your system is already infected and if the disk is not writelocked. I am not kidding. There is a very small probability that your system is already infected. I recommend that you compare the date and size of the file COMMAND.COM on your original source disks and on your working disk or disks to see that they are the same. For my system the results look like this: ------------------------------------ C> dir a:\command.com Volume in drive A is MS330PP01 Directory of A:\ COMMAND COM 25276 7-24-87 12:00a 1 File(s) 5120 bytes free C> dir c:\command.com Volume in drive C has no label Directory of C:\ COMMAND COM 25276 7-24-87 12:00a 1 File(s) 7391232 bytes free ------------------------------------ Note that both copies of COMMAND.COM have the same date and time of creation (midnight on July 24th 1987) and both are the same size (25,276 bytes). The numbers for your machine may well differ from mine, but both should be the same. When those disks have been found, put them away in a safe place. I recommend that they be put in a plastic storage box not too near your computer. Step two: There are a small number of software packages that you would be lost without. In my case they include WordStar, dBase III, PKARC, Kermit, and Directory Scanner. These packages may well be purchased commercial software (WordStar, dBase III), shareware (PKARC, Directory Scanner), and freeware (Kermit). In each case you should have an original source delivery disk for each of these packages. Find those disks, WRITE LOCK THEM, compare them with the copies you are now using, and put them in a safe place. I recommend that they be put with the system disks discussed above. (It is probably true that the creation dates for the running copies of this sort of software will disagree with the creation dates for the delivery disks. Installation of many of these packages entails writing to the program. That is not a problem.) Step three: Using the backup procedure of your choice, perform a backup of the system files on your computer. If I was using a dual floppy based system, I would simply make copies of my working WordStar, dBase III, PKARC, Kermit, and Directory Scanner disks. If I was using a computer with a floppy and a hard disk, I would use backup-restore, or Fastback or some other package to back up the directories C:\WS, C:\DB3, C:\ARK, C:\KERMIT and C:\DS. (Of course these directories have different names on your system.) Write lock these backup disks. Label them with today's date. Using your backup system compare the disks you have just backed up with the disks you are using to ensure that the backup "took". Put the backup disks in a safe place. This will tie up half a dozen disks, but with disks now costing $0.35 each, you will probably find the $2 investment worth while. Step four: (This applies to those users who use hard disk based computers.) Prepare a backup procedure that will permit incremental backups. This will entail backing up the entire system once, and then periodically backing up those files that have changed since the last backup. Perform such incremental backups regularly. After several such incremental backups, the size of the backup set will become quite large. At that time, put the backup set away in a safe place and begin with another set of disks for a full system backup followed by several increments. When the second set is full, put them away and return to the first set. This will afford a very secure set of backup files. I find that 50 disks makes a good backup set. Thus 100 disks would be used for the double backup group. I suspect that most users would need to do a full backup about 4 to 8 times per year, requiring about 1/2 hour of manipulation and should do incremental backups about twice per week, requiring less than 5 minutes. (It is a very good idea to periodically test the backup system with a verification of what you have backed up. Most file backup systems have a Verify command to do this sort of test.) Step five: Go back to your useful work. Recovery from the loss of one or a few files: Sooner or later you will lose some files. They will disappear without apparent cause and you will blame the problem on a virus. It is my experience that in cases like this no virus is involved, the loss of files will be due to an operator error. If you have been doing incremental backups, then the simplest corrective action is to use the recover feature of the backup system that you are using and simply restore the latest copy of the lost file(s) to the hard disk. If you have been conscientious in your backup practice, then the loss of work will entail just a few minutes or, at most, a few hours of rework. Recovery from the loss of the entire system: It may happen that the entire hard disk seems to be lost. This is serious but, in most cases, is likely not the result of a virus. Most failures of the hard disk are due to hardware problems. The best solution is to repair the hardware if the technical people judge that that is the problem, and then, after reformatting the hard disk, restore the system from your latest backup. Almost without fail, this will result in a complete return to a normal system. Really bad news, the restore does not work: This may well be the point of this memo. If a virus has been planted in your system and has been set to trigger on some event, then the only way to recover is to rebuild the system from scratch using the write locked set of disks that I advised you to prepare above. If these disks are not write locked, and if you mount them onto an infected system, then the disks will be infected in turn and you may well be unable to restore from a clean, uninfected source without returning to the system vendor for a fresh copy of each of your executable programs. On the assumption that you first build your system again from scratch, you may restore all of the data files from your backup set. (A data file is one that does not have the extension .com, .exe, or .sys.) Any other file should not be able to carry a virus either between systems or over the backup process. Some facts: There is no reason ever to boot the system from a foreign disk whose history you are not prepared to trust. (For example, booting from a copy protected version of Lotus 1-2-3 is as secure as the Lotus corporation can make it.) There is no reason why a disk used to transport data between machines should have a copy of the files io.sys, msdos.sys, ibmio.sys, ibmdos.sys or command.com on it. No system to date has been infected by the transport to it of data files. Only executable files (including device drivers and the operating system itself) can be used as Trojan Horse programs. Leonard P. Levine Professor Department of Computer Science College of Engineering and Applied Science University of Wisconsin-Milwaukee Milwaukee, Wisconsin 53201 (414) 229-5170 (414) 962-4719 -------------------- *** end of Virus-L issue ***