Facts and Fibs About Computer Viruses

Facts and Fibs About Computer Viruses
=====================================================

E1) Can boot sector viruses infect non-bootable DOS floppy disks?

Any DOS diskette that has been properly formatted contains some
executable code in its boot sector. (There is some debate as to whether
this code should be called a program or not. The important thing here
is that this code is *executed* at system startup if the diskette is in
the system's boot drive.) If a diskette is not "bootable", all that
boot sector (normally) does is print a message (on a PC, typically
something like "Non-system disk or disk error; replace and strike any
key when ready"). However, the boot sector is still executable and
therefore vulnerable to infection. Should you accidentally boot your
machine with a "non-bootable" diskette in the boot drive, and see that
message, it means that any boot virus that may have been on that
diskette *has* run, and had the chance to infect your hard drive, or
whatever. So, when talking about viruses, the words "bootable" and "non-
bootable" are misleading. All formatted diskettes are capable of
carrying boot sector viruses.

Most current computers will try to boot from their (first) floppy drive
before trying to load an operating system off their hard disks. Because
of this and the fact that every floppy disk is possibly infected with a
boot sector virus, it is a *very* good idea to set your computer to try
to boot from its hard disk. Many newer PCs offer the option to select
boot order in their system CMOS setup routines. If your computer has
such an option, set it to try to boot from your hard disk first.


E2) Can a virus hide in a PC's CMOS memory?

No. The CMOS RAM in which PC system information is stored and backed up
by batteries is accessible through the I/O ports and not directly
addressable. That is, in order to read its contents you have to use I/O
instructions rather than standard memory addressing techniques.
Therefore, anything stored in CMOS is not directly "in memory". Nothing
in a normal machine loads the data from CMOS and executes it, so a virus
that "hid" in CMOS RAM would still have to infect an executable object
of some kind in order to load and execute whatever had been 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.

Further, most PCs have only 64 bytes of CMOS RAM and the use of the
first 48 bytes of this is predetermined by the IBM AT specification.
Several BIOS'es also use many of the "extra" bytes of CMOS to hold their
own, machine-specific settings. This means that anything that a virus
stores in CMOS can't be very large. A virus could use some of the
"surplus" CMOS RAM to hide a small part of its body (e.g. its payload,
counters, etc). Any executable code stored there, however, must first
be extracted to ordinary memory in order to be executed.

This issue should not be confused with whether a virus can *modify* the
contents of a PC's CMOS RAM. Of course viruses can, as this memory is
not specially protected (on normal PCs), so any program that knows how
to change CMOS contents can do so. Some viruses do fiddle with the
contents of CMOS RAM (mostly with ill-intent) and these have often been
incorrectly reported as "infecting CMOS" or "hiding in CMOS". An
example is the PC boot sector virus EXE_Bug, which changes CMOS settings
to indicate that no floppy drives are present (see G8 for more details).


E3) Can a PC virus hide in Extended or in Expanded RAM in a PC?

Yes. If one does though, it has to have a small part resident in
conventional RAM; it cannot reside *entirely* in Extended or in Expanded
RAM. Currently there are no known XMS viruses and only a few EMS
viruses (Emma is an example).


E4) Can a virus hide in a PC's Upper Memory or in High Memory Area?

Yes, it is possible to construct a virus which will locate itself in
Upper Memory Blocks (UMBs--640K to 1024K) or in the High Memory Area
(HMA--1024K to 1088K). Some viruses (e.g. EDV) do hide in UMBs and at
least one, Goldbug, will use the HMA if it is available.

It might be thought that there is no point in scanning in these areas
for any viruses other than those that 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 code must be executed. Therefore
"infected" non-executable files cannot be sources of further infection.
Such "infections" are usually mistakes, due to bugs in the virus.

Even so, note that it is not always possible to make a sharp distinction
between executable and non-executable files. One person's data can be
another's code 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 PC world are OBJ files, libraries, device
drivers, source files for any compiler or interpreter (including DOS BAT
files and OS/2 CMD files), macro files for some packages like Microsoft
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, OBJ files, device drivers, Microsoft Word document and template
files, and C source code files, although any of the objects mentioned
above theoretically can be used as an infection carrier. PostScript
files can also be used to carry a virus, although no currently known
virus does this.

Aside from the above, however, there is an increasing possibility of
viruses spreading through the sharing of data files. More and more we
see the ease with which software producers give their programs the
ability to embed "objects" of many kinds into document files, and into
fields in databases and spreadsheets. Perhaps the best-known of these
systems are Object Linking and Embedding (OLE) in MS Windows and the
OpenDoc format. As these embedded objects often have the ability to
"display" themselves we see that many files traditionally thought of as
data-only, will increasingly be containers carrying data and executable
code. We are not aware of any virus that specifically targets such
executable "objects", but it is now a trivial task to embed executable
files into some kinds of document files so they will be run when the
icon representing them is clicked in the finished document. There is
nothing to prevent infected executables being embedded in this way, and
thus for viruses to be spread through the distribution of "data files".


E6) Can viruses spread from one type of computer to another?

The simple answer is that no currently known viruses can do this.
Although some 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 boot sector. The Stoned virus contains instructions
for the 80x86 family of CPUs that the 680x0 CPU family (used in the
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-
platform sharing of software means that any such virus would be unlikely
to spread--it would be a poor environment for virus growth.

A related, but different, issue is that of viruses running under
operating system emulators on machines other than those for which the
operating system was originally designed. This is covered in some
detail elsewhere in the FAQ sheet (see C12).


E7) Are mainframe computers susceptible to computer viruses?

Yes. Numerous experiments have shown that computer viruses spread very
quickly and effectively on mainframe systems. To our knowledge,
however, no non-research computer virus has been seen on mainframe
systems. (Despite often being described as such, the widely reported
Internet Worm of November 1988 was not a computer virus by most
definitions, although it had some virus-like characteristics.)

Many people think that computer viruses are impossible on mainframe
computers, because their operating systems provide means of protection
(e.g., memory protection, access control, etc.) that cannot by bypassed
by a program, unlike the operating systems of most personal computers.
Unfortunately, this belief is false. As demonstrated by Fred Cohen in
1984, access controls are unable to prevent computer viruses--they can
only slow down the speed with which viruses spread. If there is a
transitive path of information flow from one account to another on a
mainframe computer, then a virus can spread from one account to the
other, without having to bypass any protections.

Consider the following example. The attacker (A) has an account on a
machine and wants to attack it with a virus. In order to do this, A
writes a virus and releases it. Due to the protection provided by the
operating system, the virus can only infect the files writable by A. On
a typical system, those would be only the files owned by A.

However, A is not alone on the system. A works with B on some joint
projects. At some time, B might want to check how far A has progressed
in her/his part of the project. This might involve running one of the
programs that A has written--programs that are now all infected with A's
virus.

On a sytem with protection based on discretionary access controls (e.g.,
Unix, VMS, and most other popular OSes), the program that is being
executed usually runs with the privileges of the user who is executing
it--not with those of the program's owner. (In the few instances where
this is not the case, it presents a different kind of security threat,
unrelated to viruses.) That is, when B runs A's infected program, the
virus in it will run with B's privileges and will be able to infect all
programs writable by B.

At some later time, A and B's boss, C, might want to check whether they
have completed that joint project. Even if the boss has reasons to
suspect A (e.g., as a disgruntled employee), s/he is likely to trust B
and execute one of her/his programs. This results in the virus running
with C's privileges (which are likely to be significantly greater than
those of A and B) and infecting all programs writable by C. Quite
possibly, these programs will include many owned by other employees,
thus creating many more distribution chains that nobody suspects.

The virus may interfere somehow with C's normal work, which causes C
(who is probably not very knowledgeable about such things as computer
security and viruses) to ask the system administrator, D, for help. If
D executes one of C's infected programs (and s/he is much more likely to
trust a respectable person like C--who is quite probably D's boss as
well--than any of C's employees), this will cause the virus that A wrote
a long time ago to run with system administrator privileges and do
whatever it wants with the system--infect other users' files, attack
other systems, etc.

A trivial improvement of the above scenario (in terms of speeding up the
virus' spread) would be for the attacker to place the virus in some kind
of Trojan Horse--for example, in an attractive game or utility--placed
in a publicly accessible area.

Why, then, are there so many fewer viruses for mainframe computers than
for personal ones? The answer to this question is complex. First,
writing a well-made mainframe virus--one that does not cause problems
and is likely to remain unnoticed--is not a trivial task. It requires a
lot of knowledge about the operating system. This knowledge is not
commonly available and the typical youngster who is likely to hack a
quick-and-dirty PC virus is unlikely to possess it or be in a position
to learn it. People who possess this knowledge are likely to use it in
more constructive, satisfying, and profitable ways. Second, the culture
of software exchange in the mainframe world differs considerably from
that of the PC world--we don't see many VMS users running around with a
bootable tape of the latest game... Third, very often it is easier to
attack a mainframe computer by using some security hole or a Trojan
Horse, instead of by using a virus.

So, computer viruses for mainframe computers are definitely possible and
several already exist (see question F1). Also, some IBM PC viruses can
infect any IBM PC compatible machine, even if it runs a "real" OS like
Unix. For more information, refer to questions D6 and E7.

Forms of malware other than computer viruses--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
Trojan Horses. There are two reasons for this:

1. Since a virus is self-propogating, the number of users to
which it can spread (and cause damage) can be much greater
than in the case of a Trojan;

2. It's almost impossible to trace the source of a virus since
(generally) 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 (IP =
129.170.16.4) as pub/security/mallogic.ps.


E8) Some people say that disinfecting is a bad idea. Is that true?

Disinfection is completely "safe" only if the disinfecting process
completely restores the non-infected state of the object. That is, not
only must the virus be removed from the object, but the original length
must be restored exactly, as well as any system attributes (such as time
and date of last modification, fields in the header, etc). Sometimes it
is necessary to be sure that the object is placed on the same sectors of
the disk that it occupied prior to infection (this is particularly
important for some system areas and some files from programs which use
certain kinds of self-checking or copy protection).

None of the currently available disinfecting programs do all this. For
instance, because of the bugs that exist in many viruses and because
some infection processes involve overwriting (part of) the objects of
infection, some of the information about the original object may be
irrevocably destroyed. Sometimes it is not even possible 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, Ripper), so that it is not even possible to tell which
objects have been corrupted.

Therefore, it is usually better to replace infected objects with clean
backups, provided you are certain that your backups are uninfected (see
D10), or from the original media. You should try to disinfect files
only if they contain some valuable data that cannot be restored from
backups or recompiled from their original source.


E9) Can I avoid viruses by avoiding shareware, free software or games?

No. There are many documented instances in which even commercial
"shrink wrapped" 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 and diskettes.
Merely 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.


E10) Can I contract a virus on my PC by performing a "DIR" of an
infected floppy disk?

Assuming the PC you are using is virus free before you perform the DIR
command, then the answer is "No".

When you perform a DIR, the contents of the boot sector of the diskette
are loaded into a buffer for use in determining disk layout etc, and
certain antivirus 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 antivirus packages to produce a message
like "xyz virus found in memory...". 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. 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 (see G8) and scan
your hard-drive and find no virus, then you know that the false positive
was caused by an infected boot-sector loaded into a buffer, and the
diskette should be 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 (see C8 also). Please note, however, that running
DIR on a diskette can result in the infection of a clean diskette if the
PC is already infected.

Despite our categorical "No" answer above, there is a small risk that a
virus infection could be transferred from a floppy through a DIR
listing. If you use an ANSI console driver that allows key remapping,
it is possible that a specially prepared diskette could reprogram your
keyboard so that pressing a particular key caused an infected program on
the diskette to run the next time the reprogrammed key was pressed. The
risk of such an attack is very low and can easily be negated following
the general advice for preventing ANSI bombs (see B14).

Mac users with system software prior to version 7.0 should be aware of a
greater threat in their environment. Various system resources (which
can contain executable code) are loaded from the automatic access to a
diskette that is part of the system building its desktop view of the
diskette's contents. When such a resource is required, the most
recently loaded one will be used. Thus, if a diskette with a virus-
infected resource in the Desktop file is in your Mac's drive, and an
uninfected copy of that resource has not subsequently loaded from
elsewhere, the next time that resource is required the infected copy
will be executed, along with the virus. This kind of attack was removed
with the introduction of version 7.0 (and later) of the system software,
which handles such things quite differently. A common Mac virus, WDEF,
uses this infection path, as do a few others.

Early versions of AmigaDOS are susceptible to a threat similar to the
Mac WDEF virus--on inserting a diskette into the drive, the operating
system runs the Disk Validator from the diskette. At least one Amiga
virus, Saddam, attaches itself to Disk Validator to help it spread.
Version 2.0 of AmigaDOS eliminated the threat of this type of attack by
removing the need for the Disk Validator.


E11) 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 generally is 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.
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) although
you should be concerned with what type of files are being copied to
avoid introducing other problems.


E12) 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 address disk sectors directly cannot function under OS/2 because the
operating system prevents this activity.


E13) 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 separate 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.

Also, bear in mind that generally 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.


E14) 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 existing viruses will damage Windows
applications if they try to infect them as normal (i.e. DOS) EXE files.
The damaged applications will stop working and this will alert the user
that something is wrong.

Virus-resistant however, 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 box". All non-
resident COM infectors will be able to run and infect too. Aside from
DOS viruses, MS Windows users can also contract several currently known
Windows-specific viruses, which are able to infect Windows applications
properly (i.e., they are 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.


E15) Can I get a virus from reading e-mail, BBS message forums or
USENET News?

In general terms, the answer is no. E-mail messages and postings on
BBSes and News are text data and will not be executed as programs.
Computer viruses are programs, and must be executed to do anything, so
the simple act of reading online messages doesn't pose a threat of
catching a computer virus.

There are a few provisos to be made. If your computer uses ANSI screen
and keyboard controls, you may be susceptible to an ANSI bomb (see B14).
An ANSI bomb may, merely by being placed in text read on the screen,
temporarily redefine keys on the keyboard to perform various functions.
It is, however, very unlikely that you will ever see an ANSI bomb in
e-mail, or that it could do significant damage while you are reading
mail.

Another possibility is that mail can be used to send programs. To do
this program files have to be encoded into a special form so the binary
(8-bit) program files are not corrupted by transfer over the text-only
(7-bit) e-mail transport medium. Probably the commonest of these
encoding schemes is uuencoding, though there are several others. If you
receive an encoded program, you normally have to use a decoding program
or special option in your e-mail program to extract it and decode it
before it can be run. Once you have extracted the program though, you
should then treat it as you would any other program whose source you do
not know, and test it before you run it.

A third possibility is with the newer, highly-automated online systems.
Some of these attempt to make online access much easier for the user by
automating such features as file transfer and program updates. At least
one commercial online service is known to have the capability of sending
new programs to the user and to invoke those programs while the user is
still online. While there is no reason to assume that any service that
does this *will* infect you, any time things are going on that you are
not being told about, you are at greater risk.


E16) Can a virus "hide" in a GIF or JPEG file?

The simple answer is "no". The complete answer is more complex.

GIF and JPEG (.JPG) files contain compressed graphical information.
Every now and then, rumors arise that is possible to infect those files
with a virus in such a way, that it will spread when you display one of
these images. This is technically impossible--no part of the GIF or
JPEG format contains code that is executed by the viewer program.

It *is* possible to use the least significant bit of the color
information for each pixel in GIF files to store additional information,
without visibly altering the quality of the picture contained in the
file. This is called "steganography" and is sometimes used to transmit
secretly encrypted messages. Since a virus is nothing more than
information, it is possible to "encode" it into a GIF file and transmit
it this way. However, the recipients must be aware that the GIF file
contains such hidden information and take some deliberate steps to
extract it--it cannot happen against their will.