( This is condensed from a keynote report given by the sysop, a Private )
( Detective specializing in the investigation of computer crimes, to a )
( weekend conference of a number of large companies addressing the )
( problem of personal computer viruses and their spread into corporate )
( environments.

Copyright (C) 1988 SPS Missouri

-------------------------------------------------

To: All users
From: Craig Howard, Sysop ProBoard Plus
Re: Computer viruses, trojans et alii

Distribution: Public in entirety only


As some of you have noticed lately, there is a lot of speculation
going around the BBS community regarding computer viruses. Rather than
engage in a "I-saw-it" story, I would like to go into some of the facts
regarding computer viruses, and hopefully clear up some of the confusion as
well.

First of all, I would like to point out that the existence of viruses
are, from your standpoint, irrelevant. Simply because the fire has not yet
engulfed your house does not mean that the risk is not real; you are just
not yet so "blessed." So, too, with the threat of viruses -- due to the
architecture of the IBM PC it is vulnerable to attack from a self-
replicating code virion capable of independent action (a virus, in other
words). And as the typical homeowner braces for the worst with fire
insurance, smoke detectors and fire extinguishers so too should you brace
for a possible "fire" in your PC.

Just HOW vulnerable is your PC? Well, without going into specifics
there are basically seven areas on your computer that could be attacked
that we really can't do much about once an attack is successful (others,
like a format call and the like, are discussed below). They are:

1) Hard/ floppy disks -- These have two areas of danger; the
boot clusters or tracks and the interleave index. Should something write
to any of these the disk is most probably history.
2) Video boards -- It is well-known among "old-timers" that among
the first of the PD screen blankers was some well-intentioned but lethal
code that when run would literally destroy hercules graphics cards. Current
herc cards are still vulnerable to this sort of things, in addition to some
of the newer EGA cards.
3) Processor chips -- It is possible for a programmer to fiddle
with the 8259 chip to cause the chip to begin to run at the equivalent of
several times the normal clock speed (8 Mhz becomes 32, etc.), which causes
the chip to literally cook.
4) Physical disk media -- On both hard and floppy disks there are
actuator arms on which the read/write heads are perched. Normally they are
confined to a narrow area of movement, but it is possible to manipulate the
controller to cause them to move beyond these limits. On a floppy this
would cause a major misalignment of the heads; on a hard drive, it would
destroy the drive in a matter of seconds.
5) CMOS memory (AT only) -- On AT's, it is possible to set the
CMOS to switch into AT protected mode upon bootup. If you had programs
which could boot in protected mode you would be OK; otherwise, the AT just
sits there with drives spinning. The only cure is to disconnect the
battery and wait for the CMOS to discharge (6 to 8 hours).
6) Battery (AT only) -- Again on AT's, one can cause the battery
to "fast-discharge" itself in a matter of hours (this is a commercial
program, by the way -- check with Ray-o-vac for details). This is more of
a nuisance than anything else.
7) COM ports -- due to the programmability of the 8250 UART chip
and its cousins, this chip is also vulnerable to the same "toasting" as the
processor chip above.
Viruses can cause other problems, but these are of a recoverable
nature. These affect
1) Memory -- a virus can replicate "dead code" inside a program,
causing internal stack space to grow until the program literally cannot be
loaded into the machine
2) Disk storage -- a virus can erase FAT tables, cross-link
files, execute a high-level format, delete files, etc.

As I said, once a virus capable of one of the nonrecoverable "zaps"
gets to you the game is up; no appeal, no reprieve. If you are LUCKY you
will have a machine left operating to come back to; if not, you are now
blessed with a big, tan doorstop. Fortunately, however, 90% of the viruses
that ARE out there ARE of the second recoverable type one way or another.
Not everything that causes trouble is a virus, however. At this time I
have been called into 142 cases of computer sabotage in 4 states and in
only 6 of them has a virus been definitely identified as the culprit. Of
them 4 were written in-house specifically for the targeted system, leaving
only 2 which were of the type everyone is concerned about, that of the
publicly spread AIDS-type virus. In all of the other cases it was traceable
to a software or hardware incompatibility which was too-easily blamed on
"the virus." Moral: don't assume that that "A,R,I" error on your disk is a
virus making an appearance!

How is a virus identified and fought? Following a biological lead the
viral code segment, or virion, must have three basic characteristics:
1) It must be capable of inducing replication of the virion code
2) It must be capable of locating a suitable target (generally
the system files, device drivers, and first few clusters of any storage
media)
3) It must be small (to allow for infection into stack space of
programs, typically only 1000 to 10,000 bytes large)
These limitations pose a severe problem for the viral programmer; most
compilers are too "loose" to allow for the type of small code elements
critical to the virus. The viruses generally are of the one shot/ one
target type; they make an attempt at a single target of an assumed name
and location and hope to make a "hit;" should they fail, the attack is
halted (but the virion not "dead;" it will continue to make the initial
attack until the target is found). Herein lies a weakness of virions which
can be exploited -- when it makes its initial attack we can anticipate its
most likely target and monitor for such attacks. Therein is the "fire
alarm" of viral protection; to monitor for attacks upon likely targets and
take action at that point. Several methods are available for this, perhaps
the easiest the program FluShot Plus, currently in version 1.2 at this
writing (RamNet BBS, 201-889-6438 Ross Greenberg Sysop). This program
installs itself in memory and constantly monitors for all recoverable
attacks and two of the unrecoverable. Properly used, it provides an
excellent first line of defense against an initial viral attack.
Its drawback, however, is that the same paths that the virus takes for
its attack is used by many legitimate DOS and program functions; the result
is, as the homeowner disconnects the fire alarm due to one too many
soundings when the wife burns the bacon, the computer user soon becomes
annoyed at the constant interruption of FluShot and disables it. Indeed,
with several programs (such as AutoCad rel. 9) it is incompatible, leading
to machine lockups. The user stops using the program and effectively
negates its protection.

The next line of defense is one which a certain famous football coach
advocated: a good offense. Instead of waiting for a virus to strike, we
seek it out. There are three things we can look for changes in to see if a
file has been infected with the virion code; the size of the file, the date
stamp, and the file CRC value. Each of these could be changed by a viral
attack, depending upon how "sloppy" the virus was in its attack (some can
infect without changing anything). Indeed, the simple expedient of making
ALL vulnerable files such as all .COM, .EXE and .SYS files read-only would
do much to limit viral effectiveness. Other tactics such as keeping only
minimal items in the root directory and reassigning COMSPEC would further
compound the virus' work.
Again, though, these have the drawback that they are inconvenient to
the user and thus ignored after awhile. Programs which automatically check
for changes are rare, although FluShot can be changed to monitor changes in
program CRC each time the program loads, thus signalling a possible viral
attack.

The final line of defense, that of the "insurance," is perhaps the
hardest of all for the user to tolerate yet the one most capable of
recovering from disaster. This final line, of course, is that of the
backup. Here data is copied and physically removed from the machine,
insulating it not only from all of the above viruses but from other hazards
such as electric surge, operator error and fire of the real type. Methods
of backup are almost as varied as machines, yet several guidelines can be
drawn for anti-viral operation.
1) Make two types of backup, system and IBU. On the system
backup only those files which will not change, such as all .COM, .EXE,
.SYS, and others. Be sure that all anti-viral programs such as FluShot
are engaged, to prevent viral contamination of the backups. The IBU (or
Incremental Back Up) set will be made up of files which change constantly
such as data files. Note that due to the types of data, the system backup
is done rarely and the IBU quite often.
2) Make two sets of each type, labeled 1 and 2. These will be
initially be identical sets but will then be rotated such that as one is
being backed up the other sits safely offsite. This ensures that a valid
backup always exists (even if a little old) should a backup become
contaminated. More importantly, all backup algorithms erase a backup being
written over, such that once a backup is begun over an old one, the old one
is gone forever. Should you have just one backup and disaster strike as
you were in the middle of making a new backup over the old one, there would
be NO backup protection.
The purpose for making two sets is that due to the fact that the
system backups would rarely, if ever, change one could take BOTH sets of
backups to storage aware that were a virus to strike, one could low-level
the system and restore the system backups with more than reasonable
knowlege that the virus would be gone (virion code does not, to my
knowlege, invade data files). The IBU backups would as well be free of
contamination, thus allowing a recovery from an unknown viral infection.
The flaw in this, of course, is that backing up drives is second only
to taxes and root canal work in terms of user enthusiasm. I feel that you
should back up what you would not like to replace; therefore, I back up at
least every day (if not more). The same should guide your backup schedule.

In summary, then, there are three points to be made about the current
generation of viruses; they are
1) Viral infections, and virion-caused damage, are real
possibilities not be be discounted or avoided. However, a viral attack is
not at the heart of every glitch encountered on a computer; better first to
eliminate possible hardware/ software incompatibilities before suspecting a
viral infection.
2) Most viral attacks can be restored using the services of
utilities such as Norton Advanced Utilities, PC Tools Deluxe, and others.
There are very few "no appeal, no reprieve" executioners out there.
3) Defenses exist against viral attack which are effective
against a vast majority of attackers. However, they are no good unless
used on an ongoing, continuous basis by the users they protect. Chief
among these defenses is a consistent, strong policy of drive backups.

Viruses have the capability of doing enormous amounts of damage to
both the individual user and the telecommunications community at large.
Their authors are individuals who write and exhibit viruses and their
effects with the same pride as would an artisan with a finely crafted piece
of work. It is seen as a challenge to craft a more insidious, destructive
virion than the last -- especially when there are countermeasure programs
to bypass. Just as at one time there was an "arms race" between the makers
and breakers of copy protection, so too is there one between makers and
breakers of virions. Only by judiciously using all lines of defense
available can we continue to enjoy the fruits of the telecommunications
world without becoming refugees of the current viral wars.


- Det. Craig Howard
Sysop, ProBoard Plus
(816) 924-0301
MCI #352-6727

registered on most large BBS's

P.S. As for my "I-saw-it" story, the one actual virus was one that
attacked the relatively common IO.SYS driver on MS-DOS disks and
reprogrammed the 8259 chip to toast the processor after 100,000
machine cycles had gone through. Replication was through anything
that used INT 5 for disk access rather than normal channels
triggering a search for, and attack on, another IO.SYS wherever the
INT 5 addressed. The programmer was found due to an informant and
introduced to 18 USC 2510 regarding felony tampering and wire fraud;
the perp is now serving a suspended sentence of 5 years after a
$20,000 fine and confiscation of all computer equipment under Federal
Seizure laws, in addition to civil damages from the damaged company.

Fini.

-------------------------------------------------