241 lines
13 KiB
Plaintext
241 lines
13 KiB
Plaintext
Date: Thu, 15 Sep 88 10:29:56 CDT
|
|
From: Len Levine <len@EVAX.MILW.WISC.EDU>
|
|
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 Macin-
|
|
tosh) 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 some-
|
|
thing 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 pro-
|
|
grams 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 ma-
|
|
chines that many staff members now have will also have their files af-
|
|
fected by the very same virus, and at the same time. If you are prepar-
|
|
ing a paper for publication, writing or working on an exam, or preparing
|
|
some important correspondence, you may well find that your machine read-
|
|
able 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 write-
|
|
lock 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 alumi-
|
|
num 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 infor-
|
|
mation 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 write-
|
|
locked. 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 pur-
|
|
chased 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 incre-
|
|
ments. 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 incremen-
|
|
tal 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 solu-
|
|
tion 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 plant-
|
|
ed 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 proc-
|
|
ess.
|
|
|
|
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 ma-
|
|
chines 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
|
|
|
|
|
|
|
|
|
|
|