================================
C1) What are the symptoms and indications of a virus infection?
Many people associate destruction--file corruption, reformatted disks
and the like--with viruses. Machines infected with viruses that do this
kind of damage often display such damages too. This is unfortunate, as
usually viruses can be detected or prevented from infecting long before
they can inflict any (serious) damage, though many viruses have no
"payload" at all. Note that viruses that simply reformat the hard disk
shortly after infecting a machine tend to wipe themselves out faster
than they spread, so don't get far.
Thus, the more successful viruses typically try to spread as much as
possible before delivering their payload, if any. As these tend to be
the viruses you are most likely to encounter, you should be aware that
there are usually symptoms of virus infection before any (or much!)
damage is done.
There are various kinds of symptoms that some virus authors have written
into their programs, such as messages, music and graphical displays.
The main indications, however, are changes in file sizes and contents,
changing of interrupt vectors, or the reassignment of other system
resources. The unaccounted use of RAM or a reduction in the amount
reported to be in the machine are important indicators. Examination of
program code is valuable to the trained eye, but even a novice can often
spot the gross differences between a valid boot sector and some viral
ones. These symptoms, along with longer disk activity and strange
behavior from the hardware, may instead be caused by genuine software,
by harmless "joke" programs, or by hardware faults.
The only foolproof way to determine that a virus is present is for an
expert to analyse the assembly code contained in all programs and system
areas, but this is usually impracticable. Virus scanners go some way
towards performing this analysis by looking in that code for known
viruses; some even use heuristic means to spot "virus-like" code, but
this is not always reliable. It is wise to arm yourself with the latest
antivirus software and to pay close attention to your system. In
particular, look for any unexpected change in the memory map or
configuration as soon as you start the computer. For users of DOS 5.0+,
the MEM program with the /C switch is very handy for this. If you have
DR DOS, use MEM with the /A switch; if you have an earlier DOS version,
use CHKDSK or the commonly-available MAPMEM utility. You don't have to
know what all the numbers mean, only that they have changed
*unexpectedly*. Mac users have "info" options, which give some
indication of memory use, but may need ResEdit to supply more detailed
information.
If you run Windows on your PC and you suddenly start getting messages at
Windows startup that 32-bit Disk Access cannot be used, this often
indicates your PC has been infected by a boot-sector virus.
C2) What steps should be taken in diagnosing and identifying viruses?
Most of the time, a virus scanner program will take care of that for
you. To help identify problems early, run a virus scanner:
1. On new programs and diskettes (write-protect diskettes before
scanning them).
2. When an integrity checker reports a mismatch.
3. When a generic monitoring program sounds an alarm.
4. When you receive an updated version of a scanner (or you have
a chance to run a different scanner than the one you have
been using).
Because of the time required, it is not generally advisable to set a
scanner to check your entire hard disk on every boot.
If you run into an alarm and your scanner doesn't identify anything or
doesn't properly clean up for you, first verify that the version you are
using is the most recent. Then get in touch with a reputable antivirus
researcher, who may ask you to send in a copy of the infected file.
(Also see C9; and F4 if you decide you need to ask for help on Virus-
L/comp.virus.)
C3) What is the best way to remove a virus?
In order that downtime be short and losses low, do the minimum that you
must to restore the system to a normal state, starting with booting the
system from a clean diskette (see G8). It is *never* necessary to low-
level format a hard disk to recover from a virus infection!
If backups of infected or damaged files are available and, in making
them, appropriate care was taken to ensure that infected files have not
been included in the backups (see D10), restoring from backup is the
safest solution, even though it can be a lot of work if many files are
involved.
More commonly, a disinfecting program is used, though disinfection is
somewhat controversial and problematic (see E8). If the virus is a boot-
sector infector, you can continue using the computer with relative
safety (if the hard disk's partition table is left intact) by booting
from a clean system diskette. However, it is wise to go through all
your diskettes removing any infections as, sooner or later, you will be
careless and leave an infected diskette in the machine when it reboots,
or give an infected diskette to a someone who doesn't have appropriate
defenses to avoid infection.
Most PC boot-sector infections can be cured by the following simple
process--pay particular care to make the checks in Steps 2 and 3.
Note that removing an MBR virus in the following way may not be
desirable, and may even cause valuable information to be lost. For
instance, the One_Half virus gradually encrypts the infected hard drive
"inwards" (starting from the "end" and moving towards the beginning),
encrypting two more tracks at each boot. The information about the size
of the encrypted area is *only* stored in the MBR. If the virus is
removed using the method above, this information will be irrecoverably
lost and part of the disk with unknown size will remain encrypted.
1. Boot the PC from a clean system floppy--this must be MS-DOS
5.0 or version 6.0 or higher of PC-DOS or DR DOS. This
diskette should carry copies of the DOS utilities MEM, FDISK,
CHKDSK, UNFORMAT and SYS. (See G8 for help on making an
emergency boot diskette.)
2. Check that your memory configuration is "normal" with MEM
(see C10 for assistance here). Check that your hard disk
partitioning is normal--run FDISK and use the "Display
partition information" option to check this. MS-DOS 5.0 (or
later) users can use UNFORMAT /L /PARTN.
3. Try doing a DIR of your hard disk/s (C:, D:, etc).
You should continue with Step 4 *only* if all the tests in
Step 2 and this step pass. Do *NOT* continue if you were
unable to correctly access *all* your hard disks, as you will
quite possibly damage critical information making permanent
data damage or loss more likely.
4. Replace the program (code) part of the MBR by using the MS-,
or PC-DOS FDISK /MBR command. If you use DR DOS 6.0, or
later, select the FDISK menu option "Re-write Master Boot
Record".
5. Replace the DOS boot sector using the command SYS C: (or
whatever is correct for your first hard disk partition). For
this step, the version of DOS on your boot diskette must be
*exactly* the same as is installed on your hard disk (this
may mean you have to first reboot with a clean boot diskette
other than that used in Step 1). If you are using a disk
compression system, such as DoubleSpace of DriveSpace, check
the documentation on how to locate the physical drive on
which the compressed volume is installed, and apply the SYS
command to that instead. Usually this is drive H: or I:.
6. Reboot from your hard disk and check that all is well--if not
(which is unlikely if you made the recommended checks), seek
expert help.
7. As you will get re-infected by forgetting an infected
diskette in your A: drive at boot time, you have to clean all
your floppies as well. This is harder, as there is no simple
way of doing this with standard DOS tools. You can copy the
files from each of your floppies, re-format them and copy the
files back, but this is a very tedious process (and prone to
destructive errors!). At this point you probably should
consider obtaining some good antivirus software.
FDISK /MBR will only overwrite the boot loader code in the MBR of the
*first* hard drive in a system. However, a few viruses will infect both
drives in a two drive system. Although the second hard drive is never
booted from in normal PC configurations, should the second drive from
such a machine ever be used as the first drive in a system, it will
still be infected and in need of disinfecting.
C4) What does the
If an antivirus program has detected a virus on your computer, don't
rush to post a question to this list asking what it does. First, it
might be a false positive alert (especially if the virus is found only
in one file--see C5), and second, some viruses are extremely common, so
questions like "What does the Jerusalem virus do?" or "What does the
Stoned virus do?" are asked here repeatedly. While this list is read by
several antivirus experts, they get tired of perpetually answering the
same questions over and over again. In any case, if you really need to
know what a particular virus does (as opposed to knowing enough to get
rid of it), you will need a longer treatise than could be given here.
For example, the Stoned virus replaces the disk's boot record with its
own, relocating the original to a sector on the disk that may (or may
not) occur in an unused portion of the root directory of a DOS diskette;
when active, it sits in an area a few kilobytes below the top of memory.
All this description could apply to a number of common viruses; but the
important points of where the original boot sector goes--and what effect
that has on networking software, non-DOS partitions, and so on--are all
major questions in themselves.
Therefore, it is better if you first try to answer your question
yourself. There are several sources of information about the known
computer viruses, so please consult one of them before requesting
information publicly. Chances are that your virus is rather well known
and that it is already described in detail in at least one of these
sources (see A6 for some help in finding these.)
C5) What are "false positives" and "false negatives"?
A FALSE POSITIVE (or Type-I) error is one in which antivirus software
claims that a given object is infected by a virus when, in reality, the
object is clean. This is a failure of *detection* (see B15). A FALSE
NEGATIVE (or Type-II) error is one in which the software fails to
indicate that an infected object is infected. Clearly false negatives
are more serious than false positives, although both are undesirable.
Following from some of Fred Cohen's work, it has been proven that every
virus detector must have an infinite number of false positives, false
negatives, or both. This is expressed by saying that detection of
viruses, either by appearance or behavior, is UNDECIDABLE. The
interpretation and practical significance of this depends upon the
interpretation of the terms used, and as with Fred's definition of the
term "computer virus", there is some debate over this.
In the case of virus scanners, false positives are rare, but they can
arise if the scan string chosen for a given virus is also present in
some benign objects because the string was not well chosen. In modern
scanners, most false positives probably occur because some virus
encryption engines produce very "normal looking" code and scanners that
only try to decide if a piece of code could have been generated by a
known virus encryption procedure will occasionally detect "innocent"
code as "suspicious". False negatives are more common with virus
scanners because scanners will miss completely new or heavily modified
viruses.
One other serious problem could occur: A positive that is misdiagnosed.
As an example, imagine a scanner faced with the Empire virus in a boot
record that reports it as the Stoned virus. In this case, use of a
Stoned-specific "cure" to recover from an Empire infection could result
in an unreadable disk or loss of extended partitions. Similarly,
sometimes "generic" disinfection (see D1) can result in unusable files,
unless a check is made (e.g. by comparing checksums) that the recovered
file is identical to the original file. The better generic disinfection
products all store information about the original files to allow
verification of recovery processes.
A particular type of false positive, where (part of) an *inactive* virus
is detected, is known as a GHOST POSITIVE. Ghost positives usually
occur in one of four situations (the first two of which are examples of
antivirus programs "upsetting" each other):
Ghost positives can be caused when the disinfection routine of an
antivirus program "unhooks" a virus from its target (be it a file or
boot sector) but it does so in such a way that part of the virus code is
left intact (though that code will never be executed). Another
antivirus program might see this code and report it is an infection. In
this case the second antivirus program is seeing a "ghost"--part of a
virus that was there.
A scanner may "see" the unencoded scan strings of another scanner, left
in memory after the first has run or held in memory by a resident
scanner, and report these "ghosts" as active viruses (see C6 and C8).
As explained elsewhere (see E10) a copy of an infected diskette boot
sector, sitting in the disk buffers, may be detected and reported as an
active virus.
Disinfection procedures can result in virus "remnants" being left in
"slack space" (disk space allocated to files but not actually occupied).
As in the case of copies of infected diskette boot sectors being held in
disk buffers, these remnants can be detected and incorrectly reported as
being active. Ghost positives of this nature should disappear after
running disk defragmentation or "optimization" programs with the option
to "clean" slack space. Occasionally running a defragmenter (like MS-
DOS 6's DEFRAG) after a full data backup (see D10), is a good idea
anyway--especially before installing new software. Unfortunately, DOS's
DEFRAG does not have a "clean slack space" option, though some third-
party defragmenters do. There are also utilities that clean unallocated
and slack space and these should remove ghost positives caused by
"remnants".
C6) Could an antivirus program itself be infected?
Yes, so it is important to obtain this software from good sources, and
to trust results only after running scanners from a "clean" system. But
there are situations where a scanner appears to be infected when it
isn't.
Most antivirus programs try very hard to identify viral infections only,
but sometimes they give false alarms (see C5). If two different
antivirus programs are both of the "scanner" type, they will contain
"scan strings" from which they identify viral infections. If the
strings are not "encoded", then they may be identified as a virus by
another scanner type program. Also, if the scanner does not remove the
strings from memory after it has run, then another scanner may detect a
virus string "in memory". This often causes the second scanner to
report that your system is "infected", *but* only after you have run the
first scanner (which may be a memory resident one). The major
contributors to this group are so tired of dealing with non-virus
reports of this sort that they *strongly* recommend users to avoid
antivirus software which doesn't keep its scan strings encoded in
memory.
Some "change detection" antivirus programs add a snippet of code or data
to a program in order to "protect" it. (This process is sometimes
called "inoculation", but this term is also used for other antivirus
techniques.) These file changes will likely be detected by other
"change detection" programs, and may therefore raise a warning of a
suspicious file change (see F8 for a discussion of the inadvisability of
adding self-checking code to *existing* programs).
It is good practice to use more than one antivirus program but, by their
nature, multiple antivirus programs may confuse each other!
C7) Where can I get a virus scanner for my Unix system?
Basically, you shouldn't bother scanning for Unix viruses at this point
in time. Although it is possible to write Unix-based viruses we have
yet to see any instance of a non-experimental virus in that environment.
Someone with sufficient knowledge and access to write an effective virus
would be more likely to conduct other activities than virus-writing.
Furthermore, the typical form of software sharing in the Unix
environment does not support virus spread as easily as some others.
This answer is not meant to imply that Unix viruses are impossible, or
that there aren't security problems in a typical Unix environment--there
are, and Fred Cohen's first experimental virus was implemented and
tested on a Unix system. True viruses in the Unix environment are,
however, unlikely to spread well. For more information on Unix
security, see the book "Practical Unix Security" by Garfinkel and
Spafford, O'Reilly & Associates, 1991, price $29.95 (it can be ordered
via e-mail from nuts@ora.com).
There *are* special cases in which scanning Unix systems for non-Unix
viruses does make sense. For example, a Unix system acting as a file
server (e.g., PC-NFS) for PC systems is quite capable of containing PC
file infecting viruses that are a danger to PC clients. Note that, in
this example, the Unix system would be scanned for PC viruses, not Unix
viruses. Also, *any* PC is vulnerable to PC MBR infectors, so special
care should be taken to prevent booting a PC hosted Unix OS from a
floppy infected with an MBR virus (see C12).
In addition, a file integrity checker (to detect unauthorized changes in
executable files) on Unix systems is a very good idea. (One free
program that can do this test, as well as other tests, is Tripwire,
available by anonymous FTP from its "home" site of coast.cs.purdue.edu
in /pub/COAST/Tripwire, and from several other antivirus sites.)
Unauthorized file changes on Unix systems are very common, although they
are not usually due to virus activity.
C8) Why does my scanner report an infection only sometimes?
There are circumstances where part of a virus exists in RAM without
being active. If your scanner occasionally reports a virus in memory,
it could be due to the operating system buffering diskette reads or
harmlessly keeping disk contents that include a virus in memory, or
after running another scanner, there may be scan strings left (again
harmlessly) in memory. These are known as GHOST POSITIVE alerts (see C5
for more details).
C9) I think I have detected a new virus; what do I do?
Whenever there is doubt over a virus, you should obtain the latest
versions of several (not just one) major virus scanners. Some scanning
programs now use "heuristic" methods (F-PROT and TBSCAN are examples),
and "activity monitoring" programs can report a program as being
possibly infected when it is in fact perfectly safe (odd, perhaps, but
not infected). If no scanner finds a virus, but a heuristic program
raises some alarms (or there are other reasons to suspect a virus--e.g.
change in size of files, change in memory allocation) then it is
possible that you have found a new virus, although the chances are
probably greater that it is an "odd but okay" disk or file. Start by
looking in recent Virus-L/comp.virus postings for "known" false
positives, then contact the author of the antivirus software that
reports the virus-like features; the documentation for the software may
have a section explaining what to do if you think you have found a new
virus.
C10) CHKDSK reports 639K (or less) total memory on my DOS system; am I
infected?
If CHKDSK displays 639KB (654,336 bytes) for the total memory instead of
640K (655,360 bytes)--so that you are missing only 1KB-- it is possibly
due to reasons other than a virus, but there are a few common viruses
that take only 1KB from total memory (Monkey and AntiEXE). Non-virus
reasons for a deficiency of 1KB include:
1. A PS/2 computer. IBM PS/2 computers reserve 1KB of
conventional RAM for an Extended BIOS Data Area, i.e. for
additional data storage required by its BIOS.
2. A computer with a BIOS, which is set to use the upper 1KB of
memory for its internal variables. (Most BIOSes with this
option can be instructed to use lower memory instead.)
3. Some SCSI controllers.
4. The DiskSecure antivirus program.
5. Mouse buffers for older Compaqs.
If you are missing 2KB or more from the 640KB, 512KB, or whatever the
conventional memory normally is for your PC, the chances are greater
that you have a boot-record virus (e.g. Stoned, Form or Michelangelo),
although, even in this case there may be legitimate reasons for the
missing memory:
1. Many access control programs for preventing booting from a
floppy.
2. H/P Vectra computers.
3. Some special BIOS'es which use memory for a built-in calendar
and/or calculator.
However, these are only rough guides. In order to be more certain
whether the missing memory is due to a virus, you should:
1. run several virus detectors;
2. look for a change in total memory every now and then;
3. compare the total memory size with that obtained when cold
booting from a "clean" system diskette. The latter should
show the normal amount of total memory for your configuration
(although several BIOSes now steal 1KB of conventional memory
when booted from floppy but none when booting from a hard
drive).
Note: In all cases, CHKDSK should be run without software such as MS-
Windows or DesqView loaded, since these operating environments seem to
be able to open DOS boxes only on 1KB boundaries (some seem to be even
coarser); thus CHKDSK run from a DOS box may report unrepresentative
values.
Note also that some machines have only 512KB or 256KB instead of 640KB
of conventional memory.
C11) I have an infinite loop of sub-directories on my hard drive; am I
infected?
Probably not. This happens now and then, when something sets the
"cluster number" field of a subdirectory to the same cluster as an upper-
level (usually the root) directory. On PCs the /F parameter of CHKDSK
should be able to "fix" this (as should many other popular disk-repair
programs), usually by removing the offending directory. *Don't* erase
any of the "replicated" files in the "odd" directory, since that will
erase the "copy" in the root as well (these are not really copies at
all; just a second pointers to the same files).
C12) Can a PC not running DOS be infected with a common DOS virus?
Yes! There are three distinct possibilities here.
One is Novell's NetWare (and possibly other network operating systems),
which boots from a DOS disk and loads a "standard" DOS executable that
takes complete control of the system from DOS. This executable--
SERVER.EXE--could easily be infected by a DOS file infector. For
example, a server's NetWare boot diskette may have to be taken from the
server to a DOS PC to edit some of the configuration and startup files
that have to be on that diskette. If the PC where the editing is done
is infected with a file infecting virus, SERVER.EXE may well be infected
when the new startup files are saved to the diskette. Such infections
are virtually guaranteed to render SERVER.EXE inoperative and the server
would fail at its next restart. No viruses are known to target the
NetWare kernel specifically.
Another possibility is the case of a 386 (or better) system running
NetWare or a self-loading OS, such as Unix, NeXTStep486, Windows NT or
OS/2, since this system is still vulnerable to infection by MBR
infectors (such as Stoned or Michelangelo), as these are operating
system independent. Note that an infection on such a system may result
in the disabling of non-DOS disk partitions (possibly beyond easy
recovery) because the tricks and system conventions these viruses employ
may not apply to operating systems other than DOS. The issue here is
that MBR infectors are not really "DOS viruses" so much as "PC-BIOS
viruses"--they can infect any machine with a PC-compatible BIOS.
Third, *any* OS that offers a "DOS box" or "DOS emulator" to run DOS
programs can, potentially, run a virus-infected DOS program. Such
activation of a virus should allow the virus to spread to any "targets"
available to it under that DOS emulator. For example, a DOS program
infected with a multipartite virus, when run under OS/2 would probably
be able to infect other DOS executables, but not the MBR/DBS, as OS/2
only allows programs to read these critical areas of the hard drive (see
E12 for more details on DOS viruses running under OS/2). With the
increasing sophistication and power of computing environments, DOS
emulators running on non-PC computers are increasingly available and
able to run DOS viruses.
C13) My hard-disk's file system has been garbled: Do I have a virus?
Many things apart from viruses cause corruption of file systems.
With DOS machines possibly the most common is Microsoft's SmartDrive
disk cache program that came with Microsoft Windows 3.1 and subsequent
versions of MS-DOS. Most versions of this software not only cache disk-
reads but, by default, also cache disk-writes. This means that recently
"written" files (say from saving a document in your word processor) may
not have all the information about the associated file system updates
written to disk by the time you exit the application, close Windows and
turn off your PC. Users who simply save work then turn their PC off are
even more likely to suffer from disk caching induced problems like this.
Regardless of what caused your file-system corruption, you should
probably seek expert help *before* trying to fix anything yourself.
While there are many powerful and interesting-sounding utilities of the
"disk fix" kind available, *all* of these have the stunning ability to
render your file system all but unfixable (or at least, fixable to a
much lesser degree) when presented with unusual situations their authors
hadn't considered when designing the programs. Unfortunately, as these
programs (by definition) do not recognize these situations, they
confidently pronounce that you have such-and-such a problem then ask
your permission to fix it. Even when these utilities have "undo"
options, they often cannot restore your file system to its originally
"broken" state to give human experts their best shot at fixing it.
Thus, detecting whether it is safe to let one of these programs loose on
your disks is something you should normally seek expert help in
deciding.
No comments:
Post a Comment