1752 lines
83 KiB
Plaintext
1752 lines
83 KiB
Plaintext
Archive-name: computer-virus-faq
|
|
Last-modified: 18 November 1992, 7:45 AM EST
|
|
|
|
Frequently Asked Questions on VIRUS-L/comp.virus
|
|
Last Updated: 18 November 1992, 7:45 AM EST
|
|
|
|
====================
|
|
= Preface Section: =
|
|
====================
|
|
|
|
This document is intended to answer the most Frequently Asked
|
|
Questions (FAQs) about computer viruses. As you can see, there are
|
|
many of them! If you are desperately seeking help after recently
|
|
discovering what appears to be a virus on your computer, consider
|
|
skimming through sections A and B to learn the essential jargon, then
|
|
concentrate on section C.
|
|
|
|
If you may have found a new virus, or are not quite sure if some file
|
|
or boot sector is infected, it is important to understand the protocol
|
|
for raising such questions, e.g. to avoid asking questions that can be
|
|
answered in this document, and to avoid sending "live" viruses except
|
|
to someone who is responsible (and even then in a safe form!).
|
|
|
|
Above all, remember the time to really worry about viruses is BEFORE
|
|
your computer gets one!
|
|
|
|
The FAQ is a dynamic document, which changes as people's questions
|
|
change. Contributions are gratefully accepted -- please e-mail them
|
|
to me at krvw@cert.org. The most recent copy of this FAQ will always
|
|
be available on the VIRUS-L/comp.virus archives, including the
|
|
anonymous FTP on cert.org (192.88.209.5) in the file:
|
|
pub/virus-l/FAQ.virus-l
|
|
|
|
Ken van Wyk, moderator VIRUS-L/comp.virus
|
|
|
|
Primary contributors (in alphabetical order):
|
|
Mark Aitchison <phys169@csc.canterbury.ac.nz>
|
|
Vaughan Bell <vaughan@computing-department.poly-south-west.ac.uk>
|
|
Matt Bishop <matt.bishop@dartmouth.edu>
|
|
Vesselin Bontchev <bontchev@fbihh.informatik.uni-hamburg.de>
|
|
Olivier M.J. Crepin-Leblond <umeeb37@vaxa.cc.ic.ac.uk>
|
|
David Chess <chess@watson.ibm.com>
|
|
John-David Childs <con_jdc@lewis.umt.edu>
|
|
Nick FitzGerald <cctr132@csc.canterbury.ac.nz>
|
|
Claude Bersano-Hayes <hayes@urvax.urich.edu>
|
|
John Kida <jhk@washington.ssds.COM>
|
|
Donald G. Peters <Peters@Dockmaster.NCSC.Mil>
|
|
A. Padgett Peterson <padgett%tccslr.dnet@mmc.com>
|
|
Y. Radai <radai@hujivms.huji.ac.il>
|
|
Rob Slade <rslade@sfu.ca>
|
|
Gene Spafford <spaf@cs.purdue.edu>
|
|
Otto Stolz <rzotto@nyx.uni-konstanz.de>
|
|
|
|
====================
|
|
|
|
Questions answered in this document
|
|
|
|
Section A: Sources of Information and Anti-viral Software
|
|
(Where can I find HELP..!)
|
|
|
|
A1) What is VIRUS-L/comp.virus?
|
|
A2) What is the difference between VIRUS-L and comp.virus?
|
|
A3) How do I get onto VIRUS-L/comp.virus?
|
|
A4) What are the guidelines for VIRUS-L?
|
|
A5) How can I get back-issues of VIRUS-L?
|
|
A6) What is VALERT-L?
|
|
A7) What are the known viruses, their names, major symptoms and
|
|
possible cures?
|
|
A8) Where can I get free or shareware anti-virus programs?
|
|
A9) Where can I get more information on viruses, etc.?
|
|
|
|
|
|
Section B: Definitions
|
|
(What is ...?)
|
|
|
|
B1) What are computer viruses (and why should I worry about them)?
|
|
B2) What is a Trojan Horse?
|
|
B3) What are the main types of PC viruses?
|
|
B4) What is a stealth virus?
|
|
B5) What is a polymorphic virus?
|
|
B6) What are fast and slow infectors?
|
|
B7) What is a sparse infector?
|
|
B8) What is a companion virus?
|
|
B9) What is an armored virus?
|
|
B10) Miscellaneous Jargon and Abbreviations
|
|
|
|
|
|
Section C: Virus Detection
|
|
(Is my computer infected? What do I do?)
|
|
|
|
C1) What are the symptoms and indications of a virus infection?
|
|
C2) What steps should be taken in diagnosing and identifying viruses?
|
|
C3) What is the best way to remove a virus?
|
|
C4) What does the <insert name here> virus do?
|
|
C5) What are "false positives" and "false negatives"?
|
|
C6) Could an anti-viral program itself be infected?
|
|
C7) Where can I get a virus scanner for my Unix system?
|
|
C8) Why does an antiviral scanner report an infection only sometimes?
|
|
C9) Is my disk infected with the Stoned virus?
|
|
C10) I think I have detected a new virus; what do I do?
|
|
C11) CHKDSK reports 639K (or less) total memory on my system; am I
|
|
infected?
|
|
C12) I have an infinite loop of sub-directories on my hard drive; am I
|
|
infected?
|
|
|
|
|
|
Section D: Protection Plans
|
|
(What should I do to prepare against viruses?)
|
|
|
|
D1) What is the best protection policy for my computer?
|
|
D2) Is it possible to protect a computer system with only software?
|
|
D3) Is it possible to write-protect the hard disk with only software?
|
|
D4) What can be done with hardware protection?
|
|
D5) Will setting DOS file attributes to READ ONLY protect them from
|
|
viruses?
|
|
D6) Will password/access control systems protect my files from
|
|
viruses?
|
|
D7) Will the protection systems in DR DOS work against viruses?
|
|
D8) Will a write-protect tab on a floppy disk stop viruses?
|
|
D9) Do local area networks (LANs) help to stop viruses or do they
|
|
facilitate their spread?
|
|
D10) What is the proper way to make backups?
|
|
|
|
|
|
Section E: Facts and Fibs about computer viruses
|
|
(Can a virus...?)
|
|
|
|
E1) Can boot sector viruses infect non-bootable floppy disks?
|
|
E2) Can a virus hide in a PC's CMOS memory?
|
|
E3) Can a virus hide in Extended or in Expanded RAM?
|
|
E4) Can a virus hide in Upper Memory or in High Memory?
|
|
E5) Can a virus infect data files?
|
|
E6) Can viruses spread from one type of computer to another?
|
|
E7) Can DOS viruses run on non-DOS machines (e.g. Mac, Amiga)?
|
|
E8) Can mainframe computers be susceptible to computer viruses?
|
|
E9) Some people say that disinfecting files is a bad idea. Is that
|
|
true?
|
|
E10) Can I avoid viruses by avoiding shareware/free software/games?
|
|
E11) Can I contract a virus on my PC by performing a "DIR" of an
|
|
infected floppy disk?
|
|
E12) Is there any risk in copying data files from an infected floppy
|
|
disk to a clean PC's hard disk?
|
|
E13) Can a DOS virus survive and spread on an OS/2 system using the
|
|
HPFS file system?
|
|
E14) Under OS/2 2.0, could a virus infected DOS session infect another
|
|
DOS session?
|
|
E15) Can normal DOS viruses work under MS Windows?
|
|
|
|
|
|
Section F: Miscellaneous Questions
|
|
(I was just wondering...)
|
|
|
|
F1) How many viruses are there?
|
|
F2) How do viruses spread so quickly?
|
|
F3) What is the plural of "virus"? "Viruses" or "viri" or "virii" or...
|
|
F4) When reporting a virus infection (and looking for assistance), what
|
|
information should be included?
|
|
F5) How often should we upgrade our anti-virus tools to minimize
|
|
software and labor costs and maximize our protection?
|
|
|
|
|
|
Section G: Specific Virus and Anti-viral software Questions...
|
|
|
|
G1) I was infected by the Jerusalem virus and disinfected the infected
|
|
files with my favorite anti-virus program. However, Wordperfect
|
|
and some other programs still refuse to work. Why?
|
|
G2) I was told that the Stoned virus displays the text "Your PC is now
|
|
Stoned" at boot time. I have been infected by this virus several
|
|
times, but have never seen the message. Why?
|
|
G3) I was infected by both Stoned and Michelangelo. Why has my
|
|
computer became unbootable? And why, each time I run my favorite
|
|
scanner, does it find one of the viruses and say that it is
|
|
removed, but when I run it again, it says that the virus is still
|
|
there?
|
|
|
|
|
|
================================================================
|
|
= Section A. Sources of Information and Anti-viral Software. =
|
|
================================================================
|
|
|
|
A1) What is VIRUS-L/comp.virus?
|
|
|
|
It is a discussion forum with a focus on computer virus issues. More
|
|
specifically, VIRUS-L is an electronic mailing list and comp.virus is
|
|
a USENET newsgroup. Both groups are moderated; all submissions are
|
|
sent to the moderator for possible inclusion in the group. For more
|
|
information, including a copy of the posting guidelines, see the file
|
|
virus-l.README, available by anonymous FTP on cert.org in the
|
|
pub/virus-l directory. (FTP is the Internet File Transfer Protocol,
|
|
and is described in more detail in the monthly VIRUS-L/comp.virus
|
|
archive postings - see below.)
|
|
|
|
Note that there have been, from time to time, other USENET
|
|
cross-postings of VIRUS-L, including the bit.listserv.virus-l. These
|
|
groups are generally set up by individual site maintainers and are not
|
|
as globally accessible as VIRUS-L and comp.virus.
|
|
|
|
|
|
A2) What is the difference between VIRUS-L and comp.virus?
|
|
|
|
As mentioned above, VIRUS-L is a mailing list and comp.virus is a
|
|
newsgroup. In addition, VIRUS-L is distributed in digest format (with
|
|
multiple e-mail postings in one large digest) and comp.virus is
|
|
distributed as individual news postings. However, the content of the
|
|
two groups is identical.
|
|
|
|
|
|
A3) How do I get onto VIRUS-L/comp.virus?
|
|
|
|
Send e-mail to LISTSERV@LEHIGH.EDU stating: "SUB VIRUS-L your-name".
|
|
To "subscribe" to comp.virus, simply use your favorite USENET news
|
|
reader to read the group (assuming that your site receives USENET
|
|
news).
|
|
|
|
|
|
A4) What are the guidelines for VIRUS-L?
|
|
|
|
The list of posting guidelines is available by anonymous FTP on
|
|
cert.org. See the file pub/virus-l/virus-l.README for the most recent
|
|
copy. In general, however, the moderator requires that discussions
|
|
are polite and non-commercial. (Objective postings of product
|
|
availability, product reviews, etc., are fine, but commercial
|
|
advertisements are not.) Also, requests for viruses (binary or
|
|
disassembly) are not allowed. Technical discussions are strongly
|
|
encouraged, however, within reason.
|
|
|
|
|
|
A5) How can I get back-issues of VIRUS-L?
|
|
|
|
VIRUS-L/comp.virus includes a series of archive sites that carry all
|
|
the back issues of VIRUS-L, as well as public anti-virus software (for
|
|
various computers) and documents. The back-issues date back to the
|
|
group's inception, 21 April 1988. The list of archive sites is
|
|
updated monthly and distributed to the group; it includes a complete
|
|
listing of the sites, what they carry, access instructions, as well as
|
|
information on how to access FTP sites by e-mail. The anonymous FTP
|
|
archive at cert.org carries all of the VIRUS-L back issues. See the
|
|
file pub/virus-l/README for more information on the cert.org archive
|
|
site.
|
|
|
|
|
|
A6) What is VALERT-L?
|
|
|
|
VALERT-L is a sister group to VIRUS-L, but is intended for virus
|
|
alerts and warnings only -- NO DISCUSSIONS. There is no direct USENET
|
|
counterpart to VALERT-L; it is a mailing list only. All VALERT-L
|
|
postings are re-distributed to VIRUS-L/comp.virus later. This group
|
|
is also moderated, but on a much higher priority than VIRUS-L. The
|
|
group is monitored during business hours (East Coast, U.S.A.,
|
|
GMT-5/GMT-4); high priority off-hour postings can be made by
|
|
submitting to the group and then telephoning the CERT/CC hotline at +1
|
|
412 268 7090 -- instruct the person answering the hotline to call or
|
|
page Ken van Wyk.
|
|
|
|
Subscriptions to VALERT-L are handled identically to VIRUS-L --
|
|
contact the LISTSERV.
|
|
|
|
|
|
A7) What are the known viruses, their names, major symptoms and
|
|
possible cures?
|
|
|
|
First of all, the reader must be aware that there is no universally
|
|
accepted naming convention for viruses, nor is there any standard
|
|
means of testing. As a consequence nearly ALL viral information is
|
|
highly subjective and subject to interpretation and dispute.
|
|
|
|
There are several major sources of information on specific viruses.
|
|
Probably the biggest one is Patricia Hoffman's hypertext VSUM. It
|
|
describes only DOS viruses, but almost all of them which are known
|
|
at any given time. Unfortunately, it is regarded by many in the field
|
|
as being inaccurate, so we do not advise people to rely solely on it.
|
|
It can be downloaded from most major archive sites except SIMTEL20.
|
|
|
|
The second one is the Computer Virus Catalog, published by the Virus
|
|
Test Center in Hamburg. It contains a highly technical description of
|
|
computer viruses for several platforms: DOS, Mac, Amiga, Atari ST,
|
|
Unix. Unfortunately, the DOS section is quite incomplete. The CVC
|
|
is available for anonymous FTP from ftp.informatik.uni-hamburg.de
|
|
(IP=134.100.4.42), directory pub/virus/texts/catalog. (A copy of the
|
|
CVC is also available by anonymous FTP on cert.org in the
|
|
pub/virus-l/docs/vtc directory.)
|
|
|
|
A third source of information is the monthly Virus Bulletin, published
|
|
in the UK. Among other things, it gives detailed technical
|
|
information on viruses (see also A9 below). Unfortunately, it is very
|
|
expensive (the subscription price is $395 per year). US subscriptions
|
|
can be obtained by calling 203-431-8720 or writing to 590 Danbury
|
|
Road, Ridgefield, CT 06877; for European subscriptions, the number is
|
|
+44-235-555139 and the address is: The Quadrant, Abingdon, OX14 3YS,
|
|
England.
|
|
|
|
A fourth good source of information on DOS viruses is the "Computer
|
|
Viruses" report of the National/International Computer Security
|
|
Association. This is updated regularly, and is fairly complete.
|
|
Copies cost approximately $75, and can be ordered by calling +1-
|
|
202-244-7875. ICSA/NCSA also publishes the monthly "Virus News and
|
|
Reviews" and other publications.
|
|
|
|
Another source of information is the documentation of Dr. Solomon's
|
|
Anti-Virus ToolKit. It is more complete than the CVC list, just as
|
|
accurate (if not more), but lists only DOS viruses. However, it is
|
|
not available electronically; you must buy his anti-virus package and
|
|
the virus information is part of the documentation.
|
|
|
|
Yet another source of information is "Virus News International",
|
|
published by S & S International. And, while not entirely virus-
|
|
related, "Computers & Security" provides information on many
|
|
aspects of computer security, including viruses.
|
|
|
|
The best source of information available on Apple Macintosh viruses is
|
|
the on-line documentation provided with the freeware Disinfectant
|
|
program by John Norstad. This is available at most Mac archive sites.
|
|
|
|
|
|
A8) Where can I get free or shareware anti-virus programs?
|
|
|
|
The VIRUS-L/comp.virus archive sites carry publicly distributable
|
|
anti-virus software products. See a recent listing of the archive
|
|
sites (or ask the moderator for a recent listing) for more information
|
|
on these sites.
|
|
|
|
Many freeware/shareware anti-virus programs for DOS are available via
|
|
anonymous FTP on WSMR-SIMTEL20.ARMY.MIL (192.88.110.20), in the
|
|
directory PD1:<MSDOS.TROJAN-PRO>. Note that the SIMTEL20 archives
|
|
are also "mirrored" at many other anonymous FTP sites, including
|
|
oak.oakland.edu (141.210.10.117, pub/msdos/trojan-pro),
|
|
wuarchive.wustl.edu (128.252.135.4, /mirrors/msdos/trojan-pro),
|
|
and nic.funet.fi (128.214.6.100, /pub/msdos/utilities/trojan-pro).
|
|
They can also be obtained via e-mail in uuencoded form from various
|
|
TRICKLE sites, especially in Europe.
|
|
|
|
Likewise, Macintosh anti-virus programs can be found on SIMTEL20 in
|
|
the PD3:<MACINTOSH.VIRUS> directory.
|
|
|
|
A list of many anti-viral programs, incl. commercial products and one
|
|
person's rating of them, can be obtained by anonymous ftp from
|
|
cert.org (192.88.209.5) in pub/virus-l/docs/reviews as file
|
|
slade.quickref.rvw.
|
|
|
|
|
|
A9) Where can I get more information on viruses, etc.?
|
|
|
|
There are four excellent books on computer viruses available that
|
|
should cover most of the introductory and technical questions you
|
|
might have:
|
|
|
|
* "Computers Under Attack: Intruders, Worms and Viruses," edited by
|
|
Peter J. Denning, ACM Press/Addison-Wesley, 1990. This is a book of
|
|
collected readings that discuss computer viruses, computer worms,
|
|
break-ins, legal and social aspects, and many other items related to
|
|
computer security and malicious software. A very solid, readable
|
|
collection that doesn't require a highly-technical background.
|
|
Price: $20.50.
|
|
|
|
* "Rogue Programs: Viruses, Worms and Trojan Horses," edited by
|
|
Lance J. Hoffman, Van Nostrand Reinhold, 1990. This is a book of
|
|
collected readings describing in detail how viruses work, where they
|
|
come from, what they do, etc. It also has material on worms, trojan
|
|
horse programs, and other malicious software programs. This book
|
|
focuses more on mechanism and relatively less on social aspects than
|
|
does the Denning book; however, there is an excellent piece by Anne
|
|
Branscomb that covers the legal aspects. Price: $32.95.
|
|
|
|
* "A Pathology of Computer Viruses," by David Ferbrache,
|
|
Springer-Verlag, 1992. This is a recent, in-depth book on the
|
|
history, operation, and effects of computer viruses. It is one of the
|
|
most complete books on the subject, with an extensive history section,
|
|
a section on Macintosh viruses, network worms, and Unix viruses (if
|
|
they were to exist).
|
|
|
|
* "A Short Course on Computer Viruses", by Dr. Fred B. Cohen, ASP
|
|
Press, 1990. This book is by a well-known pioneer in virus research,
|
|
who has also written dozens of technical papers on the subject. The
|
|
book can be obtained by writing to ASP Press, P.O. Box 81270,
|
|
Pittsburgh, PA 15217. Price: $24.00.
|
|
|
|
A somewhat dated, but still useful, high-level description of viruses,
|
|
suitable for a complete novice without extensive computer background
|
|
is in "Computer Viruses: Dealing with Electronic Vandalism and
|
|
Programmed Threats," by Eugene H. Spafford, Kathleen A. Heaphy, and
|
|
David J. Ferbrache, ADAPSO (Arlington VA), 1989. ADAPSO is a
|
|
computer industry service organization and not a publisher, so the
|
|
book cannot be found in bookstores; copies can be obtained directly
|
|
from ADAPSO @ +1 703-522-5055). There is a discount for ADAPSO
|
|
members, educators, and law enforcement personnel. Many people have
|
|
indicated they find this a very understandable reference; portions of
|
|
it have been reprinted many other places, including Denning &
|
|
Hoffman's books (above).
|
|
|
|
It is also worth consulting various publications such as _Computers &
|
|
Security_ (which, while not restricted to viruses, contains many of
|
|
Cohen's papers) and the _Virus Bulletin_ (published in the UK; its
|
|
technical articles are considered good, although there has been much
|
|
criticism in VIRUS-L of some of its product evaluations).
|
|
|
|
|
|
======================================================
|
|
= Section B. Definitions and General Information =
|
|
======================================================
|
|
|
|
B1) What are computer viruses (and why should I worry about them)?
|
|
|
|
According to Fred Cohen's well-known definition, a COMPUTER VIRUS is a
|
|
computer program that can infect other computer programs by modifying
|
|
them in such a way as to include a (possibly evolved) copy of itself.
|
|
Note that a program does not have to perform outright damage (such as
|
|
deleting or corrupting files) in order to to be called a "virus".
|
|
However, Cohen uses the terms within his definition (e.g. "program"
|
|
and "modify") a bit differently from the way most anti-virus
|
|
researchers use them, and classifies as viruses some things which most
|
|
of us would not consider viruses.
|
|
|
|
Many people use the term loosely to cover any sort of program that
|
|
tries to hide its (malicious) function and tries to spread onto as
|
|
many computers as possible. (See the definition of "Trojan".) Be
|
|
aware that what constitutes a "program" for a virus to infect may
|
|
include a lot more than is at first obvious - don't assume too much
|
|
about what a virus can or can't do!
|
|
|
|
These software "pranks" are very serious; they are spreading faster
|
|
than they are being stopped, and even the least harmful of viruses
|
|
could be fatal. For example, a virus that stops your computer and
|
|
displays a message, in the context of a hospital life-support
|
|
computer, could be fatal. Even those who created the viruses could
|
|
not stop them if they wanted to; it requires a concerted effort from
|
|
computer users to be "virus-aware", rather than the ignorance and
|
|
ambivalence that have allowed them to grow to such a problem.
|
|
|
|
|
|
B2) What is a Trojan Horse?
|
|
|
|
A TROJAN HORSE is a program that does something undocumented which the
|
|
programmer intended, but that the user would not approve of if he knew
|
|
about it. According to some people, a virus is a particular case of a
|
|
Trojan Horse, namely one which is able to spread to other programs
|
|
(i.e., it turns them into Trojans too). According to others, a virus
|
|
that does not do any deliberate damage (other than merely replicating)
|
|
is not a Trojan. Finally, despite the definitions, many people use
|
|
the term "Trojan" to refer only to a *non-replicating* malicious
|
|
program, so that the set of Trojans and the set of viruses are
|
|
disjoint.
|
|
|
|
|
|
B3) What are the main types of PC viruses?
|
|
|
|
Generally, there are two main classes of viruses. The first class
|
|
consists of the FILE INFECTORS which attach themselves to ordinary
|
|
program files. These usually infect arbitrary .COM and/or .EXE
|
|
programs, though some can infect any program for which execution is
|
|
requested, such as .SYS, .OVL, .PRG, & .MNU files.
|
|
|
|
File infectors can be either DIRECT ACTION or RESIDENT. A direct-
|
|
action virus selects one or more other programs to infect each time
|
|
the program which contains it is executed. A resident virus hides
|
|
itself somewhere in memory the first time an infected program is
|
|
executed, and thereafter infects other programs when *they* are
|
|
executed (as in the case of the Jerusalem) or when certain other
|
|
conditions are fulfilled. The Vienna is an example of a direct-action
|
|
virus. Most other viruses are resident.
|
|
|
|
The second category is SYSTEM or BOOT-RECORD INFECTORS: those viruses
|
|
which infect executable code found in certain system areas on a disk
|
|
which are not ordinary files. On DOS systems, there are ordinary
|
|
boot-sector viruses, which infect only the DOS boot sector, and MBR
|
|
viruses which infect the Master Boot Record on fixed disks and the DOS
|
|
boot sector on diskettes. Examples include Brain, Stoned, Empire,
|
|
Azusa, and Michelangelo. Such viruses are always resident viruses.
|
|
|
|
Finally, a few viruses are able to infect both (the Tequila virus is
|
|
one example). These are often called "MULTI-PARTITE" viruses, though
|
|
there has been criticism of this name; another name is "BOOT-AND-FILE"
|
|
virus.
|
|
|
|
FILE SYSTEM or CLUSTER viruses (e.g. Dir-II) are those which modify
|
|
directory table entries so that the virus is loaded and executed
|
|
before the desired program is. Note that the program itself is not
|
|
physically altered, only the directory entry is. Some consider these
|
|
infectors to be a third category of viruses, while others consider
|
|
them to be a sub-category of the file infectors.
|
|
|
|
|
|
B4) What is a stealth virus?
|
|
|
|
A STEALTH virus is one which hides the modifications it has made in
|
|
the file or boot record, usually by monitoring the system functions
|
|
used by programs to read files or physical blocks from storage media,
|
|
and forging the results of such system functions so that programs
|
|
which try to read these areas see the original uninfected form of the
|
|
file instead of the actual infected form. Thus the viral modifications
|
|
go undetected by anti-viral programs. However, in order to do this,
|
|
the virus must be resident in memory when the anti-viral program is
|
|
executed.
|
|
|
|
Example: The very first DOS virus, Brain, a boot-sector infector,
|
|
monitors physical disk I/O and re-directs any attempt to read a
|
|
Brain-infected boot sector to the disk area where the original boot
|
|
sector is stored. The next viruses to use this technique were the
|
|
file infectors Number of the Beast and Frodo (= 4096 = 4K).
|
|
|
|
Countermeasures: A "clean" system is needed so that no virus is
|
|
present to distort the results. Thus the system should be built from
|
|
a trusted, clean master copy before any virus-checking is attempted;
|
|
this is "The Golden Rule of the Trade." With DOS, (1) boot from
|
|
original DOS diskettes (i.e. DOS Startup/Program diskettes from a
|
|
major vendor that have been write-protected since their creation);
|
|
(2) use only tools from original diskettes until virus-checking has
|
|
completed.
|
|
|
|
|
|
B5) What is a polymorphic virus?
|
|
|
|
A POLYMORPHIC virus is one which produces varied (yet fully
|
|
operational) copies of itself, in the hope that virus scanners (see
|
|
D1) will not be able to detect all instances of the virus.
|
|
|
|
One method to evade signature-driven virus scanners is self-encryption
|
|
with a variable key; however these viruses (e.g. Cascade) are not
|
|
termed "polymorphic," as their decryption code is always the same and
|
|
thus can be used as a virus signature even by the simplest, signature-
|
|
driven virus scanners (unless another virus or program uses the
|
|
identical decryption routine).
|
|
|
|
One method to make a polymorphic virus is to choose among a variety of
|
|
different encryption schemes requiring different decryption routines:
|
|
only one of these routines would be plainly visible in any instance of
|
|
the virus (e.g. the Whale virus). A signature-driven virus scanner
|
|
would have to exploit several signatures (one for each possible
|
|
encryption method) to reliably identify a virus of this kind.
|
|
|
|
A more sophisticated polymorphic virus (e.g. V2P6) will vary the
|
|
sequence of instructions in its copies by interspersing it with
|
|
"noise" instructions (e.g. a No Operation instruction, or an
|
|
instruction to load a currently unused register with an arbitrary
|
|
value), by interchanging mutually independent instructions, or even by
|
|
using various instruction sequences with identical net effects (e.g.
|
|
Subtract A from A, and Move 0 to A). A simple-minded, signature-based
|
|
virus scanner would not be able to reliably identify this sort of
|
|
virus; rather, a sophisticated "scanning engine" has to be constructed
|
|
after thorough research into the particular virus.
|
|
|
|
The most sophisticated form of polymorphism discovered so far is the
|
|
MtE "Mutation Engine" written by the Bulgarian virus writer who calls
|
|
himself the "Dark Avenger". It comes in the form of an object module.
|
|
Any virus can be made polymorphic by adding certain calls to the
|
|
assembler source code and linking to the mutation-engine and
|
|
random-number-generator modules.
|
|
|
|
The advent of polymorphic viruses has rendered virus-scanning an ever
|
|
more difficult and expensive endeavor; adding more and more search
|
|
strings to simple scanners will not adequately deal with these
|
|
viruses.
|
|
|
|
|
|
B6) What are fast and slow infectors?
|
|
|
|
A typical file infector (such as the Jerusalem) copies itself to
|
|
memory when a program infected by it is executed, and then infects
|
|
other programs when they are executed.
|
|
|
|
A FAST infector is a virus which, when it is active in memory, infects
|
|
not only programs which are executed, but even those which are merely
|
|
opened. The result is that if such a virus is in memory, running a
|
|
scanner or integrity checker can result in all (or at least many)
|
|
programs becoming infected all at once. Examples are the Dark Avenger
|
|
and the Frodo viruses.
|
|
|
|
The term "SLOW infector" is sometimes used for a virus which, if it is
|
|
active in memory, infects only files as they are modified (or
|
|
created). The purpose is to fool people who use integrity checkers
|
|
into thinking that the modification reported by the integrity checker
|
|
is due solely to legitimate reasons. An example is the Darth Vader
|
|
virus.
|
|
|
|
|
|
B7) What is a sparse infector?
|
|
|
|
The term "SPARSE infector" is sometimes given to a virus which
|
|
infects only occasionally, e.g. every 10th executed file, or only
|
|
files whose lengths fall within a narrow range, etc. By infecting
|
|
less often, such viruses try to minimize the probability of being
|
|
discovered by the user.
|
|
|
|
|
|
B8) What is a companion virus?
|
|
|
|
A COMPANION virus is one which, instead of modifying an existing file,
|
|
creates a new program which (unknown to the user) gets executed by the
|
|
command-line interpreter instead of the intended program. (On exit,
|
|
the new program executes the original program so that things will
|
|
appear normal.) The only way this has been done so far is by creating
|
|
an infected .COM file with the same name as an existing .EXE file.
|
|
Note that those integrity checkers which look only for *modifications*
|
|
in *existing* files will fail to detect such viruses.
|
|
|
|
(Note that not all researchers consider this type of malicious code
|
|
to be a virus, since it does not modify existing files.)
|
|
|
|
|
|
B9) What is an armored virus?
|
|
|
|
An ARMORED virus is one which uses special tricks to make the tracing,
|
|
disassembling and understanding of their code more difficult. A good
|
|
example is the Whale virus.
|
|
|
|
|
|
B10) Miscellaneous Jargon and Abbreviations
|
|
|
|
BSI = Boot Sector Infector: a virus which takes control when the
|
|
computer attempts to boot (as opposed to a file infector).
|
|
|
|
CMOS = Complementary Metal Oxide Semiconductor: A memory area that is
|
|
used in AT and higher class PCs for storage of system information.
|
|
CMOS is battery backed RAM (see below), originally used to maintain
|
|
date and time information while the PC was turned off. CMOS memory
|
|
is not in the normal CPU address space and cannot be executed. While
|
|
a virus may place data in the CMOS or may corrupt it, a virus cannot
|
|
hide there.
|
|
|
|
DOS = Disk Operating System. We use the term "DOS" to mean any of the
|
|
MS-DOS, PC-DOS, or DR DOS systems for PCs and compatibles, even
|
|
though there are operating systems called "DOS" on other (unrelated)
|
|
machines.
|
|
|
|
MBR = Master Boot Record: the first Absolute sector (track 0, head 0,
|
|
sector 1) on a PC hard disk, that usually contains the partition table
|
|
(but on some PCs may simply contain a boot sector). This is not the
|
|
same as the first DOS sector (Logical sector 0).
|
|
|
|
RAM = Random Access Memory: the place programs are loaded into in
|
|
order to execute; the significance for viruses is that, to be active,
|
|
they must grab some of this for themselves. However, some virus
|
|
scanners may declare that a virus is active simply when it is found
|
|
in RAM, even though it might be simply left over in a buffer area of
|
|
RAM rather than truly being active.
|
|
|
|
TOM = Top Of Memory: the end of conventional memory, an architectural
|
|
design limit at the 640K mark on most PCs. Some early PCs may not
|
|
be fully populated, but the amount of memory is always a multiple of
|
|
64K. A boot-record virus on a PC typically resides just below this
|
|
mark and changes the value which will be reported for the TOM to the
|
|
location of the beginning of the virus so that it won't get
|
|
overwritten. Checking this value for changes can help detect a
|
|
virus, but there are also legitimate reasons why it may change (see
|
|
C11). A very few PCs with unusual memory managers/settings may
|
|
report in excess of 640K.
|
|
|
|
TSR = Terminate but Stay Resident: these are PC programs that stay in
|
|
memory while you continue to use the computer for other purposes;
|
|
they include pop-up utilities, network software, and the great
|
|
majority of viruses. These can often be seen using utilities such as
|
|
MEM, MAPMEM, PMAP, F-MMAP and INFOPLUS.
|
|
|
|
|
|
=================================
|
|
= Section C. Virus Detection =
|
|
=================================
|
|
|
|
C1) What are the symptoms and indications of a virus infection?
|
|
|
|
Viruses try to spread as much as possible before they deliver their
|
|
"payload", but there can be symptoms of virus infection before this,
|
|
and it is important to use this opportunity to spot and eradicate the
|
|
virus before any destruction.
|
|
|
|
There are various kinds of symptoms which some virus authors have
|
|
written into their programs, such as messages, music and graphical
|
|
displays. However, the main indications 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 known to be in the machine are important indicators. The
|
|
examination of the code is valuable to the trained eye, but even the
|
|
novice can often spot the gross differences between a valid boot
|
|
sector and an infected one. However, these symptoms, along with
|
|
longer disk activity and strange behavior from the hardware, can also
|
|
be caused by genuine software, by harmless "prank" programs, or by
|
|
hardware faults.
|
|
|
|
The only foolproof way to determine that a virus is present is for an
|
|
expert to analyze the assembly code contained in all programs and
|
|
system areas, but this is usually impracticable. Virus scanners go
|
|
some way towards that by looking in that code for known viruses; some
|
|
will even try to use heuristic means to spot viral code, but this is
|
|
not always reliable. It is wise to arm yourself with the latest
|
|
anti-viral software, but also to pay close attention to your system;
|
|
look particularly for any 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 DRDOS, use MEM
|
|
with the /A switch; if you have an earlier version, use CHKDSK or the
|
|
commonly-available PMAP or MAPMEM utilities. You don't have to know
|
|
what all the numbers mean, only that they change. Mac users have
|
|
"info" options that give some indication of memory use, but may need
|
|
ResEdit for more detail.
|
|
|
|
|
|
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. (Remember, though, that scanning programs must be kept up to
|
|
date. Also remember that different scanner authors may call the same
|
|
virus by different names. If you want to identify a virus in order to
|
|
ask for help, it is best to run at least two scanners on it and, when
|
|
asking, say which scanners, and what versions, gave the names.) To
|
|
help identify problems early, run it on new programs and diskettes;
|
|
when an integrity checker reports a mismatch, when a generic
|
|
monitoring program sounds an alarm; or when you receive an updated
|
|
version of a scanner (or a different scanner than the one you have
|
|
been using). However, because of the time required, it is not
|
|
generally advisable to insert into your AUTOEXEC.BAT file a command to
|
|
run a scanner on an entire hard disk on every boot.
|
|
|
|
If you run into an alarm that the scanner doesn't identify, or
|
|
doesn't properly clean up for you, first verify that the version that
|
|
you are using is the most recent, and then get in touch with one of
|
|
the reputable antivirus researchers, who may ask you to send a copy
|
|
of the infected file to him. See also question C10.
|
|
|
|
|
|
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. It is very unlikely that
|
|
you need to low-level reformat the hard disk!
|
|
|
|
If backups of the infected files are available and appropriate care
|
|
was taken when making the backups (see D10), this is the safest
|
|
solution, even though it requires a lot of work if many files are
|
|
involved.
|
|
|
|
More commonly, a disinfecting program is used. If the virus is a boot
|
|
sector infector, you can continue using the computer with relative
|
|
safety if you boot it from a clean system diskette, but it is wise to
|
|
go through all your diskettes removing infection, since sooner or
|
|
later you may be careless and leave a diskette in the machine when it
|
|
reboots. Boot sector infections on PCs can be cured by a two-step
|
|
approach of replacing the MBR (on the hard disk), either by using a
|
|
backup or by the FDISK/MBR command (from DOS 5 and up), then using the
|
|
SYS command to replace the DOS boot sector.
|
|
|
|
|
|
C4) What does the <insert name here> virus do?
|
|
|
|
If an anti-virus 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), and second, some viruses are extremely common, so the
|
|
question "What does the Stoned virus do?" or "What does the Jerusalem
|
|
virus do?" is asked here repeatedly. While this list is monitored by
|
|
several anti-virus 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 to you 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 the answer to question A7, for instance.)
|
|
|
|
|
|
C5) What are "false positives" and "false negatives"?
|
|
|
|
A FALSE POSITIVE (or Type-I) error is one in which the anti-viral
|
|
software claims that a given file is infected by a virus when in
|
|
reality the file is clean. A FALSE NEGATIVE (or Type-II) error is one
|
|
in which the software fails to indicate that an infected file is
|
|
infected. Clearly false negatives are more serious than false
|
|
positives, although both are undesirable.
|
|
|
|
It has been proven by Dr. Fred Cohen that every virus detector must
|
|
have either false positives or false negatives or both. This is
|
|
expressed by saying that detection of viruses is UNDECIDABLE.
|
|
However his theorem does not preclude a program which has no false
|
|
negatives and *very few* false positives (e.g. if the only false
|
|
positives are those due to the file containing viral code which is
|
|
never actually executed, so that technically we do not have a virus).
|
|
|
|
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 programs because the string was not well chosen. False
|
|
negatives are more common with virus scanners because scanners will
|
|
miss a completely new or a heavily modified virus.
|
|
|
|
One other serious problem could occur: A positive that is misdiagnosed
|
|
(e.g., a scanner that detects the Empire virus in a boot record but
|
|
reports it as the Stoned). In the case of a boot sector infector, use
|
|
of a Stoned specific "cure" to recover from the Empire could result in
|
|
an unreadable disk or loss of extended partitions. Similarly,
|
|
sometimes "generic" recovery 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. Some more recent products store
|
|
information about the original programs to allow verification of
|
|
recovery processes.
|
|
|
|
|
|
C6) Could an anti-viral 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 antiviral programs try very hard to identify only viral
|
|
infections, but sometimes they give false alarms. If two different
|
|
antiviral programs are both of the "scanner" type, they will contain
|
|
"signature strings" to identify viral infections. If the strings are
|
|
not "encrypted", then they will be identified as a virus by another
|
|
scanner type program. Also, if the scanner does not remove the
|
|
strings from memory after they are run, then another scanner may
|
|
detect the virus string "in memory".
|
|
|
|
Some "change detection" type antiviral programs add a bit of code or
|
|
data to a program when "protecting" it. This might be detected by
|
|
another "change detector" as a change to a program, and therefore
|
|
suspicious.
|
|
|
|
It is good practice to use more than one antiviral program. Do be
|
|
aware, however, that antiviral programs, by their nature, 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
|
|
an Unix environment would not support virus spread.
|
|
|
|
This answer is not meant to imply that viruses are impossible, or that
|
|
there aren't security problems in a typical Unix environment -- there
|
|
are. However, true viruses are highly unlikely and would corrupt file
|
|
and/or memory integrity. For more information on Unix security, see
|
|
the book "Practical Unix Security" by Garfinkel and Spafford, O'Reilly
|
|
& Associates, 1991 (it can be ordered via e-mail from nuts@ora.com).
|
|
|
|
However, there are special cases for which scanning Unix systems for
|
|
non-Unix viruses does make sense. For example, a Unix system which is
|
|
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.
|
|
|
|
Another example is in the case of a 386/486 PC system running Unix,
|
|
since this system is still vulnerable to infection by MBR infectors
|
|
such as Stoned and Michelangelo, which are operating system
|
|
independent. (Note that an infection on such a Unix PC system would
|
|
probably result in disabling the Unix disk partition(s) from booting.)
|
|
|
|
In addition, a file integrity checker (to detect unauthorized changes
|
|
in executable files) on Unix systems is a very good idea. (One free
|
|
program which can do this test, as well as other tests, is the COPS
|
|
package, available by anonymous FTP on cert.org.) Unauthorized
|
|
file changes on Unix systems are very common, although they usually
|
|
are not due to virus activity.
|
|
|
|
|
|
C8) Why does my anti-viral scanner report an infection only sometimes?
|
|
|
|
There are circumstances where part of a virus exists in RAM without
|
|
being active: If your scanner reports a virus in memory only
|
|
occasionally, it could be due to the operating system buffering disk
|
|
reads, keeping disk contents that include a virus in memory
|
|
(harmlessly), in which case it should also find it on disk. Or after
|
|
running another scanner, there may be scan strings left (again
|
|
harmlessly) in memory. This is sometimes called a "ghost positive"
|
|
alert.
|
|
|
|
|
|
C9) Is my disk infected with the Stoned virus?
|
|
|
|
Of course the answer to this, and many similar questions, is to obtain
|
|
a good virus detector. There are many to choose from, including ones
|
|
that will scan diskettes automatically as you use them. Remember to
|
|
check all diskettes, even non-system ("data") diskettes.
|
|
|
|
It is possible, if you have an urgent need to check a system when
|
|
you don't have any anti-viral tools, to boot from a clean system
|
|
diskette, and use the CHKDSK method (mentioned in C1) to see if it is
|
|
in memory, then look at the boot sector with a disk editor. Usually
|
|
the first few bytes will indicate the characteristic far jump of the
|
|
Stoned virus; however, you could be looking at a perfectly good disk
|
|
that has been "innoculated" against the virus, or at a diskette that
|
|
seems safe but contains a totally different type of virus.
|
|
|
|
|
|
C10) 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, CHECKOUT and SCANBOOT
|
|
are examples), and "activity monitoring" programs can report a disk or
|
|
file as being possibly infected when it is in fact perfectly safe
|
|
(odd, perhaps, but not infected). If no string-matching scan finds a
|
|
virus, but a heuristic program does (or there are other reasons to
|
|
suspect the file, e.g., change in size of files) 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 postings about "known" false positives, then contact
|
|
the author of the anti-virus software that reports it as virus-like;
|
|
the documentation for the software may have a section explaining what
|
|
to do if you think you have found a new virus. Consider using the
|
|
BootID or Checkout programs to calculate the "hashcode" of a diskette
|
|
in the case of boot sector infectors, rather than send a complete
|
|
diskette or "live" virus until requested.
|
|
|
|
|
|
C11) CHKDSK reports 639K (or less) total memory on my system; am I
|
|
infected?
|
|
|
|
If CHKDSK displays 639K for the total memory instead of 640K (655,360
|
|
bytes) - so that you are missing only 1K - then it is probably due to
|
|
reasons other than a virus since there are very few viruses which take
|
|
only 1K from total memory. Legitimate reasons for a deficiency of 1K
|
|
include:
|
|
|
|
1) A PS/2 computer. IBM PS/2 computers reserve 1K of conventional
|
|
RAM for an Extended BIOS Data Area, i.e. for additional data storage
|
|
required by its BIOS.
|
|
2) A computer with American Megatrends Inc. (AMI) BIOS, which is set
|
|
up (with the built-in CMOS setup program) in such a way that the BIOS
|
|
uses the upper 1K of memory for its internal variables. (It can be
|
|
instructed to use lower memory instead.)
|
|
3) A SCSI controller.
|
|
4) The DiskSecure program.
|
|
5) Mouse buffers for older Compaqs.
|
|
|
|
If, on the other hand, you are missing 2K or more from the 640K, 512K,
|
|
or whatever the conventional memory normally is for your PC, the
|
|
chances are greater that you have a boot-record virus (e.g. Stoned,
|
|
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 BIOSes which use memory (e.g.) 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.
|
|
|
|
Note: in all cases, CHKDSK should be run without software such as
|
|
MS-Windows or DesqView loaded, since GUIs seem to be able to open DOS
|
|
boxes only on whole K 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 512K or 256K instead of 640K of
|
|
conventional memory.
|
|
|
|
|
|
C12) 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 some subdirectory the same cluster as an
|
|
upper-level (usually the root) directory. The /F parameter of CHKDSK,
|
|
and any of various popular utility programs, should be able to fix
|
|
this, 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 (it's really not a copy at all; just a
|
|
second pointer to the same file).
|
|
|
|
|
|
===================================
|
|
= Section D. Protection plans =
|
|
===================================
|
|
|
|
D1) What is the best protection policy for my computer?
|
|
|
|
There is no "best" anti-virus policy. In particular, there is no
|
|
program that can magically protect you against all viruses. But you
|
|
can design an anti-virus protection strategy based on multiple layers
|
|
of defense. There are three main kinds of anti-viral software, plus
|
|
several other means of protection (such as hardware write-protect
|
|
methods).
|
|
|
|
1) GENERIC MONITORING programs. These try to prevent viral activity
|
|
before it happens, such as attempts to write to another executable,
|
|
reformat the disk, etc.
|
|
Examples: SECURE and FluShot+ (PC), and GateKeeper (Macintosh).
|
|
|
|
2) SCANNERS. Most look for known virus strings (byte sequences which
|
|
occur in known viruses, but hopefully not in legitimate software) or
|
|
patterns, but a few use heuristic techniques to recognize viral
|
|
code. A scanner may be designed to examine specified disks or
|
|
files on demand, or it may be resident, examining each program
|
|
which is about to be executed. Most scanners also include virus
|
|
removers.
|
|
Examples: FindViru in Dr Solomon's Anti-Virus Toolkit, FRISK's
|
|
F-Prot, McAfee's VIRUSCAN (all PC), Disinfectant (Macintosh).
|
|
Resident scanners: McAfee's V-Shield, and VIRSTOP.
|
|
Heuristic scanners: the Analyse module in FRISK's F-PROT package,
|
|
and SCANBOOT.
|
|
|
|
3) INTEGRITY CHECKERS or MODIFICATION DETECTORS. These compute a
|
|
small "checksum" or "hash value" (usually CRC or cryptographic)
|
|
for files when they are presumably uninfected, and later compare
|
|
newly calculated values with the original ones to see if the files
|
|
have been modified. This catches unknown viruses as well as known
|
|
ones and thus provides *generic* detection. On the other hand,
|
|
modifications can also be due to reasons other than viruses.
|
|
Usually, it is up to the user to decide which modifications are
|
|
intentional and which might be due to viruses, although a few
|
|
products give the user help in making this decision. As in the
|
|
case of scanners, integrity checkers may be called to checksum
|
|
entire disks or specified files on demand, or they may be resident,
|
|
checking each program which is about to be executed (the latter is
|
|
sometimes called an INTEGRITY SHELL). A third implementation is as
|
|
a SELF-TEST, i.e. the checksumming code is attached to each
|
|
executable file so that it checks itself just before execution.
|
|
Examples: Fred Cohen's ASP Integrity Toolkit (commercial), and
|
|
Integrity Master and VDS (shareware), all for the PC.
|
|
|
|
3a) A few modification detectors come with GENERIC DISINFECTION. I.e.,
|
|
sufficient information is saved for each file that it can be
|
|
restored to its original state in the case of the great majority
|
|
of viral infections, even if the virus is unknown.
|
|
Examples: V-Analyst 3 (BRM Technologies, Israel), marketed in the
|
|
US as Untouchable (by Fifth Generation), and the VGUARD module of
|
|
V-care.
|
|
|
|
Of course, only a few examples of each type have been given. All of
|
|
them can find their place in the protection against computer viruses,
|
|
but you should appreciate the limitations of each method, along with
|
|
system-supplied security measures that may or may not be helpful in
|
|
defeating viruses. Ideally, you would arrange a combination of
|
|
methods that cover the loopholes between them.
|
|
|
|
A typical PC installation might include a protection system on the
|
|
hard disk's MBR to protect against viruses at load time (ideally this
|
|
would be hardware or in BIOS, but software methods such as DiskSecure
|
|
and PanSoft's Immunise are pretty good). This would be followed by
|
|
resident virus detectors loaded as part of the machine's startup
|
|
(CONFIG.SYS or AUTOEXEC.BAT), such as FluShot+ and/or VirStop together
|
|
with ScanBoot. A scanner such as F-Prot or McAfee's SCAN could be
|
|
put into AUTOEXEC.BAT to look for viruses as you start up, but this
|
|
may be a problem if you have a large disk to check (or don't reboot
|
|
often enough). Most importantly, new files should be scanned as they
|
|
arrive on the system. If your system has DR DOS installed, you should
|
|
use the PASSWORD command to write-protect all system executables and
|
|
utilities. If you have Stacker or SuperStore, you can get some
|
|
improved security from these compressed drives, but also a risk that
|
|
those viruses stupid enough to directly write to the disk could do
|
|
much more damage than normal; using a software write-protect system
|
|
(such as provided with Disk Manager or Norton Utilities) may help, but
|
|
the best solution (if possible) is to put all executables on a disk of
|
|
their own, protected by a hardware read-only system that sounds an
|
|
alarm if a write is attempted.
|
|
|
|
If you do use a resident BSI detector or a scan-while-you-copy
|
|
detector, it is important to trace back any infected diskette to its
|
|
source; the reason why viruses survive so well is that usually you
|
|
cannot do this, because the infection is found long after the
|
|
infecting diskette has been forgotten with most people's lax scanning
|
|
policies.
|
|
|
|
Organizations should devise and implement a careful policy, that may
|
|
include a system of vetting new software brought into the building and
|
|
free virus detectors for home machines of employees/students/etc who
|
|
take work home with them.
|
|
|
|
Other anti-viral techniques include:
|
|
(a) Creation of a special MBR to make the hard disk inaccessible when
|
|
booting from a diskette (the latter is useful since booting from a
|
|
diskette will normally bypass the protection in the CONFIG.SYS and
|
|
AUTOEXEC.BAT files of the hard disk). Example: GUARD.
|
|
(b) Use of Artificial Intelligence to learn about new viruses and
|
|
extract scan patterns for them. Examples: V-Care (CSA Interprint,
|
|
Israel; distributed in the U.S. by Sela Consultants Corp.), Victor
|
|
Charlie (Bangkok Security Associates, Thailand; distributed in the
|
|
US by Computer Security Associates).
|
|
(c) Encryption of files (with decryption before execution).
|
|
|
|
|
|
D2) Is it possible to protect a computer system with only software?
|
|
|
|
Not perfectly; however, software defenses can significantly reduce
|
|
your risk of being affected by viruses WHEN APPLIED APPROPRIATELY.
|
|
All virus defense systems are tools - each with their own capabilities
|
|
and limitations. Learn how your system works and be sure to work
|
|
within its limitations.
|
|
|
|
From a software standpoint, a very high level of protection/detection
|
|
can be achieved with only software, using a layered approach.
|
|
|
|
1) ROM BIOS - password (access control) and selection of boot disk.
|
|
(Some may consider this hardware.)
|
|
|
|
2) Boot sectors - integrity management and change detection.
|
|
|
|
3) OS programs - integrity management of existing programs,
|
|
scanning of unknown programs. Requirement of authentication
|
|
values for any new or transmitted software.
|
|
|
|
4) Locks that prevent writing to a fixed or floppy disk.
|
|
|
|
As each layer is added, invasion without detection becomes more
|
|
difficult. However complete protection against any possible attack
|
|
cannot be provided without dedicating the computer to pre-existing or
|
|
unique tasks. The international standardization of the world on the
|
|
IBM PC architecture is both its greatest asset and its greatest
|
|
vulnerability.
|
|
|
|
|
|
D3) Is it possible to write-protect the hard disk with only software?
|
|
|
|
The answer is no. There are several programs which claim to do that,
|
|
but *all* of them can be bypassed using only the currently known
|
|
techniques that are used by some viruses. Therefore you should
|
|
never rely on such programs *alone*, although they can be useful in
|
|
combination with other anti-viral measures.
|
|
|
|
|
|
D4) What can be done with hardware protection?
|
|
|
|
Hardware protection can accomplish various things, including: write
|
|
protection for hard disk drives, memory protection, monitoring and
|
|
trapping unauthorized system calls, etc. Again, no tool is foolproof.
|
|
|
|
The popular idea of write-protection (see D3) may stop viruses
|
|
spreading to the disk that is protected, but doesn't, in itself,
|
|
prevent a virus from running.
|
|
|
|
Also, some of the existing hardware protections can be easily
|
|
bypassed, fooled, or disconnected, if the virus writer knows them
|
|
well and designs a virus which is aware of the particular defense.
|
|
|
|
|
|
D5) Will setting DOS file attributes to READ ONLY protect them from
|
|
viruses?
|
|
|
|
No. While the Read Only attribute will protect your files from a few
|
|
viruses, most simply override it, and infect normally. So, while
|
|
setting executable files to Read Only is not a bad idea, it is
|
|
certainly not a thorough protection against viruses!
|
|
|
|
|
|
D6) Will password/access control systems protect my files from
|
|
viruses?
|
|
|
|
All password and other access control systems are designed to protect
|
|
the user's data from other users and/or their programs. Remember,
|
|
however, that when you execute an infected program the virus in it
|
|
will gain your current rights/privileges. Therefore, if the access
|
|
control system provides *you* the right to modify some files, it will
|
|
provide it to the virus too. Note that this does not depend on the
|
|
operating system used - DOS, Unix, or whatever. Therefore, an access
|
|
control system will protect your files from viruses no better than it
|
|
protects them from you.
|
|
|
|
Under DOS, there is no memory protection, so a virus could disable the
|
|
access control system in memory, or even patch the operating system
|
|
itself. On the more advanced operating systems (Unix) this is not
|
|
possible, so at least the protection cannot be disabled by a virus.
|
|
However it will still spread, due to the reasons noted above. In
|
|
general, the access control systems (if implemented correctly) are
|
|
able only to slow down the virus spread, not to eliminate viruses
|
|
entirely.
|
|
|
|
Of course, it's better to have access control than not to have it at
|
|
all. Just be sure not to develop a false sense of security and to
|
|
rely *entirely* on the access control system to protect you.
|
|
|
|
|
|
D7) Will the protection systems in DR DOS work against viruses?
|
|
|
|
Partially. Neither the password file/directory protection available
|
|
from DR DOS version 5 onwards, nor the secure disk partitions
|
|
introduced in DR DOS 6 are intended to combat viruses, but they do to
|
|
some extent. If you have DR DOS, it is very wise to password-protect
|
|
your files (to stop accidental damage too), but don't depend on it as
|
|
the only means of defense.
|
|
|
|
The use of the password command (e.g. PASSWORD/W:MINE *.EXE *.COM)
|
|
will stop more viruses than the plain DOS attribute facility, but that
|
|
isn't saying much! The combination of the password system plus a disk
|
|
compression system may be more secure (because to bypass the password
|
|
system they must access the disk directly, but under SuperStore or
|
|
Stacker the physical disk is meaningless to the virus). There may be
|
|
some viruses which, rather than invisibly infecting files on
|
|
compressed disks in fact very visibly corrupt the disk.
|
|
|
|
The "secure disk partitions" system introduced with DR DOS 6 may be of
|
|
some help against a few viruses that look for DOS partitions on a
|
|
disk. The main use is in stopping people fiddling with (and
|
|
infecting) your hard disk while you are away.
|
|
|
|
Furthermore, DR DOS is not very compatible with MS/PC-DOS, especially
|
|
down to the low-level tricks that some viruses are using. For
|
|
instance, some internal memory structures are "read-only" in the sense
|
|
that they are constantly updated (for DOS compatibility) but not
|
|
really used by DR DOS, so that even if a sophisticated virus modifies
|
|
them, this does not have any effect.
|
|
|
|
In general, using a less compatible system diminishes the number of
|
|
viruses that can infect it. For instance, the introduction of hard
|
|
disks made the Brain virus almost disappear; the introduction of 80286
|
|
and DOS 4.x+ made the Yale and Ping Pong viruses extinct, and so on.
|
|
|
|
|
|
D8) Will a write-protect tab on a floppy disk stop viruses?
|
|
|
|
In general, yes. The write-protection on IBM PC (and compatible) and
|
|
Macintosh floppy disk drives is implemented in hardware, not software,
|
|
so viruses cannot infect a diskette when the write-protection mechanism
|
|
is functioning properly.
|
|
|
|
But remember:
|
|
|
|
(a) A computer may have a faulty write-protect system (this happens!)
|
|
- you can test it by trying to copy a file to the diskette when it
|
|
is presumably write-protected.
|
|
(b) Someone may have removed the tab for a while, allowing a virus on.
|
|
(c) The files may have been infected before the disk was protected.
|
|
Even some diskettes "straight from the factory" have been known to be
|
|
infected in the production processes.
|
|
|
|
So it is worthwhile scanning even write-protected disks for viruses.
|
|
|
|
|
|
D9) Do local area networks (LANs) help to stop viruses or do they
|
|
facilitate their spread?
|
|
|
|
Both. A set of computers connected in a well managed LAN, with
|
|
carefully established security settings, with minimal privileges for
|
|
each user, and without a transitive path of information flow between
|
|
the users (i.e., the objects writable by any of the users are not
|
|
readable by any of the others) is more virus-resistant than the same
|
|
set of computers if they are not interconnected. The reason is that
|
|
when all computers have (read-only) access to a common pool of
|
|
executable programs, there is usually less need for diskette swapping
|
|
and software exchange between them, and therefore less ways through
|
|
which a virus could spread.
|
|
|
|
However, if the LAN is not well managed, with lax security, it could
|
|
help a virus to spread like wildfire. It might even be impossible to
|
|
remove the infection without shutting down the entire LAN.
|
|
|
|
A network that supports login scripting is inherently more resistant
|
|
to viruses than one that does not, if this is used to validate the
|
|
client before allowing access to the network.
|
|
|
|
|
|
D10) What is the proper way to make backups?
|
|
|
|
Data and text files, and programs in source form, should be backed up
|
|
each time they are modified. However, the only backups you should
|
|
keep of COM, EXE and other *executable* files are the *original*
|
|
versions, since if you back up an executable file on your hard disk
|
|
over and over, it may have become infected meanwhile, so that you may
|
|
no longer have an uninfected backup of that file. Therefore:
|
|
1. If you've downloaded shareware, copy it (preferably as a ZIP or
|
|
other original archive file) onto your backup medium and do not
|
|
re-back it up later.
|
|
2. If you have purchased commercial software, it's best to create a
|
|
ZIP (or other) archive from the original diskettes (assuming they're
|
|
not copy protected) and transfer the archive onto that medium. Again,
|
|
do not re-back up.
|
|
3. If you write your own programs, back up only the latest version
|
|
of the *source* programs. Depend on recompilation to reproduce the
|
|
executables.
|
|
4. If an executable has been replaced by a new version, then of
|
|
course you will want to keep a backup of the new version. However, if
|
|
it has been modified as a result of your having changed configuration
|
|
information, it seems safer *not* to back up the modified file; you
|
|
can always re-configure the backup copy later if you have to.
|
|
5. Theoretically, source programs could be infected, but until such
|
|
a virus is discovered, it seems preferable to treat such files as
|
|
non-executables and back them up whenever you modify them. The same
|
|
advice is probably appropriate for batch files as well, despite the
|
|
fact that a few batch file infectors have been discovered.
|
|
|
|
|
|
=======================================================
|
|
= Section E. Facts and Fibs about computer viruses =
|
|
=======================================================
|
|
|
|
E1) Can boot sector viruses infect non-bootable floppy disks?
|
|
|
|
Any diskette that has been properly formatted contains an executable
|
|
program in the boot sector. If the diskette is not "bootable," all
|
|
that boot sector does is print a message like "Non-system disk or disk
|
|
error; replace and strike any key when ready", but it's still
|
|
executable and still vulnerable to infection. If you accidentally
|
|
turn your machine on with a "non-bootable" diskette in the drive, and
|
|
see that message, it means that any boot virus that may have been on
|
|
that diskette *has* run, and has had the chance to infect your hard
|
|
drive, or whatever. So when thinking about viruses, the word
|
|
"bootable" (or "non-bootable") is really misleading. All formatted
|
|
diskettes are capable of carrying a virus.
|
|
|
|
|
|
E2) Can a virus hide in a PC's CMOS memory?
|
|
|
|
No. The CMOS RAM in which system information is stored and backed up
|
|
by batteries is ported, not addressable. That is, in order to get
|
|
anything out, you use I/O instructions. So anything stored there is
|
|
not directly sitting in memory. Nothing in a normal machine loads the
|
|
data from there and executes it, so a virus that "hid" in the CMOS RAM
|
|
would still have to infect an executable object of some kind in order
|
|
to load and execute whatever it had written to CMOS. A malicious
|
|
virus can of course *alter* values in the CMOS as part of its payload,
|
|
but it can't spread through, or hide itself in, the CMOS.
|
|
|
|
A virus could also use the CMOS RAM to hide a small part of its
|
|
body (e.g., the payload, counters, etc.). However, any executable
|
|
code stored there must be first extracted to ordinary memory in order
|
|
to be executed.
|
|
|
|
|
|
E3) Can a virus hide in Extended or in Expanded RAM?
|
|
|
|
Theoretically yes, although no such viruses are known yet. However,
|
|
even if they are created, they will have to have a small part resident
|
|
in conventional RAM; they cannot reside *entirely* in Extended or in
|
|
Expanded RAM.
|
|
|
|
|
|
E4) Can a virus hide in Upper Memory or in High Memory?
|
|
|
|
Yes, it is possible to construct a virus which will locate itself
|
|
in Upper Memory (640K to 1024K) or in High Memory (1024K to 1088K),
|
|
and a few currently known viruses (e.g. EDV) do hide in Upper Memory.
|
|
|
|
It might be thought that there is no point in scanning in these areas
|
|
for any viruses other than those which are specifically known to
|
|
inhabit them. However, there are cases when even ordinary viruses can
|
|
be found in Upper Memory. Suppose that a conventional memory-resident
|
|
virus infects a TSR program and this program is loaded high by the
|
|
user (for instance, from AUTOEXEC.BAT). Then the virus code will also
|
|
reside in Upper Memory. Therefore, an effective scanner must be able
|
|
to scan this part of memory for viruses too.
|
|
|
|
|
|
E5) Can a virus infect data files?
|
|
|
|
Some viruses (e.g., Frodo, Cinderella) modify non-executable files.
|
|
However, in order to spread, the virus must be executed. Therefore
|
|
the "infected" non-executable files cannot be sources of further
|
|
infection.
|
|
|
|
However, note that it is not always possible to make a sharp
|
|
distinction between executable and non-executable files. One man's
|
|
code is another man's data and vice versa. Some files that are not
|
|
directly executable contain code or data which can under some
|
|
conditions be executed or interpreted.
|
|
|
|
Some examples from the IBM PC world are .OBJ files, libraries, device
|
|
drivers, source files for any compiler or interpreter, macro files
|
|
for some packages like MS Word and Lotus 1-2-3, and many others.
|
|
Currently there are viruses that infect boot sectors, master boot
|
|
records, COM files, EXE files, BAT files, and device drivers, although
|
|
any of the objects mentioned above can theoretically be used as an
|
|
infection carrier. PostScript files can also be used to carry a virus,
|
|
although no currently known virus does that.
|
|
|
|
|
|
E6) Can viruses spread from one type of computer to another?
|
|
|
|
The simple answer is that no currently known viruses can do this.
|
|
Although the disk formats may be the same (e.g. Atari ST and DOS), the
|
|
different machines interpret the code differently. For example, the
|
|
Stoned virus cannot infect an Atari ST as the ST cannot execute the
|
|
virus code in the bootsector. The Stoned virus contains instructions
|
|
for the 80x86 family of CPU's that the 680x0-family CPU (Atari ST)
|
|
can't understand or execute.
|
|
|
|
The more general answer is that such viruses are possible, but
|
|
unlikely. Such a virus would be quite a bit larger than current
|
|
viruses and might well be easier to find. Additionally, the low
|
|
incidence of cross-machine sharing of software means that any such
|
|
virus would be unlikely to spread -- it would be a poor environment
|
|
for virus growth.
|
|
|
|
|
|
E7) Can DOS viruses run on non-DOS machines (e.g. Mac, Amiga)?
|
|
|
|
In general, no. However, on machines running DOS emulators (either
|
|
hardware or software based), DOS viruses - just like any DOS program -
|
|
may function. These viruses would be subject to the file access
|
|
controls of the host operating system. An example is when running a
|
|
DOS emulator such as VP/ix under a 386 UNIX environment, DOS
|
|
programs are not permitted access to files which the host UNIX system
|
|
does not allow them to. Thus, it is important to administer these
|
|
systems carefully.
|
|
|
|
|
|
E8) Can mainframe computers be susceptible to computer viruses?
|
|
|
|
Yes. Numerous experiments have shown that computer viruses spread
|
|
very quickly and effectively on mainframe systems. However, to our
|
|
knowledge, no non-research computer virus has been seen on mainframe
|
|
systems. (The Internet worm of November 1988 was not a computer virus
|
|
by most definitions, although it had some virus-like characteristics.)
|
|
|
|
Computer viruses are actually a special case of something else called
|
|
"malicious logic", and other forms of malicious logic -- notably
|
|
Trojan horses -- are far quicker, more effective, and harder to detect
|
|
than computer viruses. Nevertheless, on personal computers many more
|
|
viruses are written than Trojans. There are two reasons for this:
|
|
(1) Since a virus propagates, the number of users to which damage can
|
|
be caused is much greater than in the case of a Trojan; (2) It's
|
|
almost impossible to trace the source of a virus since viruses are
|
|
not attached to any particular program.
|
|
|
|
For further information on malicious programs on multi-user systems,
|
|
see Matt Bishop's paper, "An Overview of Malicious Logic in a Research
|
|
Environment", available by anonymous FTP on Dartmouth.edu
|
|
(129.170.16.4) as "pub/security/mallogic.ps".
|
|
|
|
|
|
E9) Some people say that disinfecting files is a bad idea. Is that
|
|
true?
|
|
|
|
Disinfecting a file is completely "safe" only if the disinfecting
|
|
process restores the non-infected state of the object completely. That
|
|
is, not only the virus must be removed from the file, but the original
|
|
length of the file must be restored exactly, as well as its time and
|
|
date of last modification, all fields in the header, etc. Sometimes
|
|
it is necessary to be sure that the file is placed on the same
|
|
clusters of the disk that it occupied prior to infection. If this is
|
|
not done, then a program which uses some kind of self-checking or
|
|
copy protection may stop functioning properly, if at all.
|
|
|
|
None of the currently available disinfecting programs do all this.
|
|
For instance, because of the bugs that exist in many viruses, some of
|
|
the information of the original file is destroyed and cannot be
|
|
recovered. Other times, it is even impossible to detect that this
|
|
information has been destroyed and to warn the user. Furthermore,
|
|
some viruses corrupt information very slightly and in a random way
|
|
(Nomenklatura, Phoenix), so that it is not even possible to tell which
|
|
files have been corrupted.
|
|
|
|
Therefore, it is usually better to replace the infected objects with
|
|
clean backups, provided you are certain that your backups are
|
|
uninfected (see D10). You should try to disinfect files only if they
|
|
contain some valuable data that cannot be restored from backups or
|
|
compiled from their original source.
|
|
|
|
|
|
E10) Can I avoid viruses by avoiding shareware/free software/games?
|
|
|
|
No. There are many documented instances in which even commercial
|
|
"shrink wrap" software was inadvertently distributed containing
|
|
viruses. Avoiding shareware, freeware, games, etc. only isolates you
|
|
from a vast collection of software (some of it very good, some of it
|
|
very bad, most of it somewhere in between...).
|
|
|
|
The important thing is not to avoid a certain type of software, but to
|
|
be cautious of ANY AND ALL newly acquired software. Simply scanning
|
|
all new software media for known viruses would be rather effective at
|
|
preventing virus infections, especially when combined with some other
|
|
prevention/detection strategy such as integrity management of
|
|
programs.
|
|
|
|
|
|
E11) Can I contract a virus on my PC by performing a "DIR" of an
|
|
infected floppy disk?
|
|
|
|
If you assume that the PC you are using is virus free before you
|
|
perform the DIR command, then the answer is no. However, when you
|
|
perform a DIR, the contents of the boot sector of the diskette are
|
|
loaded into a buffer for use when determining disk layout etc., and
|
|
certain anti-virus products will scan these buffers. If a boot sector
|
|
virus has infected your diskette, the virus code will be contained in
|
|
the buffer, which may cause some anti-virus packages to give the
|
|
message "xyz virus found in memory, shut down computer immediately".
|
|
In fact, the virus is not a threat at this point since control of the
|
|
CPU is never passed to the virus code residing in the buffer. But,
|
|
even though the virus is really not a threat at this point, this
|
|
message should not be ignored. If you get a message like this, and
|
|
then reboot from a clean DOS diskette and scan your hard-drive and
|
|
find no virus, then you know that the false positive was caused by the
|
|
fact that the infected boot-sector was loaded into a buffer, and the
|
|
diskette should be appropriately disinfected before use. The use of
|
|
DIR will not infect a clean system, even if the diskette it is being
|
|
performed on does contain a virus.
|
|
|
|
|
|
E12) Is there any risk in copying data files from an infected floppy
|
|
disk to a clean PC's hard disk?
|
|
|
|
Assuming that you did not boot or run any executable programs from the
|
|
infected disk, the answer is generally no. There are two caveats: 1)
|
|
you should be somewhat concerned about checking the integrity of these
|
|
data files as they may have been destroyed or altered by the virus,
|
|
and 2) if any of the "data" files are interpretable as executable by
|
|
some other program (such as a Lotus macro) then these files should be
|
|
treated as potentially malicious until the symptoms of the infection
|
|
are known. The copying process itself is safe (given the above
|
|
scenario). However, you should be concerned with what type of files
|
|
are being copied to avoid introducing other problems.
|
|
|
|
|
|
E13) Can a DOS virus survive and spread on an OS/2 system using the
|
|
HPFS file system?
|
|
|
|
Yes, both file-infecting and boot sector viruses can infect HPFS
|
|
partitions. File-infecting viruses function normally and can activate
|
|
and do their dirty deeds, and boot sector viruses can prevent OS/2
|
|
from booting if the primary bootable partition is infected. Viruses
|
|
that try to directly address disk sectors cannot function because OS/2
|
|
prevents this activity.
|
|
|
|
|
|
E14) Under OS/2 2.0, could a virus infected DOS session infect another
|
|
DOS session?
|
|
|
|
Each DOS program is run in a separate Virtual DOS Machine (their
|
|
memory spaces are kept separated by OS/2). However, any DOS program
|
|
has almost complete access to the files and disks, so infection can
|
|
occur if the virus infects files; any other DOS session that executes
|
|
a program infected by a virus that makes itself memory resident would
|
|
itself become infected.
|
|
|
|
However, bear in mind that all DOS sessions share the same copy of the
|
|
command interpreter. Hence if it becomes infected, the virus will be
|
|
active in *all* DOS sessions.
|
|
|
|
|
|
E15) Can normal DOS viruses work under MS Windows?
|
|
|
|
Most of them cannot. A system that runs exclusively MS Windows is,
|
|
in general, more virus-resistant than a plain DOS system. The reason
|
|
is that most resident viruses are not compatible with the memory
|
|
management in Windows. Furthermore, most of the existing viruses will
|
|
damage the Windows applications if they try to infect them as normal
|
|
EXE files. The damaged applications will stop working and this will
|
|
alert the user that something is wrong.
|
|
|
|
However, virus-resistant is by no means virus-proof. For instance,
|
|
most of the well-behaved resident viruses that infect only COM files
|
|
(Cascade is an excellent example), will work perfectly in a DOS
|
|
window. All non-resident COM infectors will be able to run and infect
|
|
too. And currently there exists at least one Windows-specific virus
|
|
which is able to properly infect Windows applications (it is
|
|
compatible with the NewEXE file format).
|
|
|
|
Any low level trapping of Interrupt 13, as by resident boot sector and
|
|
MBR viruses, can also affect Windows operation, particularly if
|
|
protected disk access (32BitDiskAccess=ON in SYSTEM.INI) is used.
|
|
|
|
|
|
=========================================
|
|
= Section F. Miscellaneous Questions =
|
|
=========================================
|
|
|
|
F1) How many viruses are there?
|
|
|
|
It is not possible to give an exact number because new viruses are
|
|
being created literally every day. Furthermore, different anti-virus
|
|
researchers use different criteria to decide whether two viruses are
|
|
different or one and the same. Some count viruses as different if
|
|
they differ by at least one bit in their non-variable code. Others
|
|
group the viruses in families and do not count the closely related
|
|
variants in one family as different viruses.
|
|
|
|
Taking a rough average, as of October 1992 there were about 1,800 IBM
|
|
PC viruses, about 150 Amiga viruses, about 30 Macintosh viruses, about
|
|
a dozen Acorn Archimedes viruses, several Atari ST viruses, and a few
|
|
Apple II viruses.
|
|
|
|
However, very few of the existing viruses are widespread. For
|
|
instance, only about three dozen of the known IBM PC viruses are
|
|
causing most of the reported infections.
|
|
|
|
|
|
F2) How do viruses spread so quickly?
|
|
|
|
This is a very complex issue. Most viruses don't spread very quickly.
|
|
Those that do spread widely are able to do so for a variety of
|
|
reasons. A large target population (i.e., millions of compatible
|
|
computers) helps... A large virus population helps... Vendors whose
|
|
quality assurance mechanisms rely on, for example, outdated scanners
|
|
help... Users who gratuitously insert new software into their systems
|
|
without making any attempt to test for viruses help... All of these
|
|
things are factors.
|
|
|
|
|
|
F3) What is the plural of "virus"? "Viruses" or "viri" or "virii" or...
|
|
|
|
The correct English plural of "virus" is "viruses." The Latin word is
|
|
a mass noun (like "air"), and there is no correct Latin plural.
|
|
Please use "viruses," and if people use other forms, please don't use
|
|
VIRUS-L/comp.virus to correct them.
|
|
|
|
|
|
F4) When reporting a virus infection (and looking for assistance), what
|
|
information should be included?
|
|
|
|
People frequently post messages to VIRUS-L/comp.virus requesting
|
|
assistance on a suspected virus problem. Quite often, the information
|
|
supplied is not sufficient for the various experts on the list to be
|
|
able to help out. Also note that any such assistance from members of
|
|
the list is provided on a volunteer basis; be grateful for any help
|
|
received. Try to provide the following information in your requests
|
|
for assistance:
|
|
- The name of the virus (if known);
|
|
- The name of the program that detected it;
|
|
- The version of the program that detected it;
|
|
- Any other anti-virus software that you are running and
|
|
whether it has been able to detect the virus or not, and if yes, by
|
|
what name did it call it;
|
|
- Your software and hardware configuration (computer type,
|
|
kinds of disk(ette) drives, amount of memory and configuration
|
|
(extended/expanded/conventional), TSR programs and device drivers
|
|
used, OS version, etc.)
|
|
|
|
It is helpful if you can use more than one scanning program to
|
|
identify a virus, and to say which scanner gave which identification.
|
|
However, some scanning programs leave "signatures" in memory which
|
|
will confuse others, so it is best to do a "cold reboot" between runs
|
|
of successive scanners, particularly if you are getting confusing
|
|
results.
|
|
|
|
|
|
F5) How often should we upgrade our anti-virus tools to minimize
|
|
software and labor costs and maximize our protection?
|
|
|
|
This is a difficult question to answer. Antiviral software is a kind
|
|
of insurance, and these type of calculations are difficult.
|
|
|
|
There are two things to watch out for here: the general "style" of the
|
|
software, and the signatures which scanners use to identify viruses.
|
|
Scanners should be updated more frequently than other software, and it
|
|
is probably a good idea to update your set of signatures at least once
|
|
every two months.
|
|
|
|
Some antiviral software looks for changes to programs or specific
|
|
types of viral "activity," and these programs generally claim to be
|
|
good for "all current and future viral programs." However, even these
|
|
programs cannot guarantee to protect against all future viruses, and
|
|
should probably be upgraded once per year.
|
|
|
|
Of course, not every anti-virus product is effective against all
|
|
viruses, even if upgraded regularly. Thus, do *not* depend on the
|
|
fact that you have upgraded your product recently as a guarantee that
|
|
your system is free of viruses!
|
|
|
|
|
|
=====================================================================
|
|
= Section G. Specific Virus and Anti-viral software Questions... =
|
|
=====================================================================
|
|
|
|
|
|
G1) I was infected by the Jerusalem virus and disinfected the infected
|
|
files with my favorite anti-virus program. However, Wordperfect
|
|
and some other programs still refuse to work. Why?
|
|
|
|
The Jerusalem virus and WordPerfect 4.2 program combination is an
|
|
example of a virus and program that cannot be completely disinfected
|
|
by an anti-virus tool. In some cases such as this one, the virus will
|
|
destroy code by overwriting it instead of appending itself to the
|
|
file. The only solution is to re-install the programs from clean
|
|
(non-infected) backups or distribution media. (See question D10.)
|
|
|
|
|
|
G2) I was told that the Stoned virus displays the text "Your PC is now
|
|
Stoned" at boot time. I have been infected by this virus several
|
|
times, but have never seen the message. Why?
|
|
|
|
The "original" Stoned message was ".Your PC is now Stoned!", where the
|
|
"." represents the "bell" character (ASCII 7 or "PC speaker beep").
|
|
The message is displayed with a probability of 1 in 8 only when a PC is
|
|
booted from an infected diskette. When booting from an infected hard
|
|
disk, Stoned never displays this message.
|
|
|
|
Recently, versions of Stoned with no message whatsoever or only the
|
|
leading bell character have become very common. These versions of
|
|
Stoned are likely to go unnoticed by all but the most observant, even
|
|
when regularly booting from infected diskettes.
|
|
|
|
Contrary to some reports, the Stoned virus -does NOT- display the
|
|
message "LEGALISE MARIJUANA", although such a string is quite clearly
|
|
visible in the boot sectors of diskettes infected with the "original"
|
|
version of Stoned in "standard" PC's.
|
|
|
|
|
|
G3) I was infected by both Stoned and Michelangelo. Why has my
|
|
computer became unbootable? And why, each time I run my favorite
|
|
scanner, does it find one of the viruses and say that it is
|
|
removed, but when I run it again, it says that the virus is still
|
|
there?
|
|
|
|
These two viruses store the original Master Boot Record at one and the
|
|
same place on the hard disk. They do not recognize each other, and
|
|
therefore a computer can become infected with both of them at the same
|
|
time.
|
|
|
|
The first of these viruses that infects the computer will overwrite
|
|
the Master Boot Record with its body and store the original MBR at a
|
|
certain place on the disk. So far, this is normal for a boot-record
|
|
virus. But if now the other virus infects the computer too, it will
|
|
replace the MBR (which now contains the virus that has come first)
|
|
with its own body, and store what it believes is the original MBR (but
|
|
in fact is the body of the first virus) AT THE SAME PLACE on the hard
|
|
disk, thus OVERWRITING the original MBR. When this happens, the
|
|
contents of the original MBR are lost. Therefore the disk becomes
|
|
non-bootable.
|
|
|
|
When a virus removal program inspects such a hard disk, it will see
|
|
the SECOND virus in the MBR and will try to remove it by overwriting
|
|
it with the contents of the sector where this virus normally stores
|
|
the original MBR. However, now this sector contains the body of the
|
|
FIRST virus. Therefore, the virus removal program will install the
|
|
first virus in trying to remove the second. In all probability it
|
|
will not wipe out the sector where the (infected) MBR has been stored.
|
|
|
|
When the program is run again, it will find the FIRST virus in the
|
|
MBR. By trying to remove it, the program will get the contents of the
|
|
sector where this virus normally stores the original MBR, and will
|
|
move it over the current (infected) MBR. Unfortunately, this sector
|
|
still contains the body of the FIRST virus. Therefore, the body of
|
|
this virus will be re-installed over the MBR ad infinitum.
|
|
|
|
There is no easy solution to this problem, since the contents of the
|
|
original MBR is lost. The only solution for the anti-virus program is
|
|
to detect that there is a problem, and to overwrite the contents of
|
|
the MBR with a valid MBR program, which the anti-virus program will
|
|
have to carry with itself. If your favorite anti-virus program is not
|
|
that smart, consider replacing it with a better one, or just boot from
|
|
a write-protected uninfected DOS 5.0 diskette, and execute the program
|
|
FDISK with the option /MBR. This will re-create the executable code
|
|
in the MBR without modifying the partition table data.
|
|
|
|
In general, infection by multiple viruses of the same file or area is
|
|
possible and vital areas of the original may be lost. This can make
|
|
it difficult or impossible for virus disinfection tools to be
|
|
effective, and replacement of the lost file/area will be necessary.
|
|
|
|
====================
|
|
[End of VIRUS-L/comp.virus FAQ]
|
|
|