💾 Archived View for spam.works › mirrors › textfiles › virus › levine.pap captured on 2023-06-16 at 21:03:19.
-=-=-=-=-=-=-
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