Steve White, David Chess, Chengi Kuo
January 1989
Research Report (RC 14405)
This research report is provided without restriction;
we encourage its redistribution.
Copies may be requested from:
IBM Thomas J. Watson Research Center
Distribution Services F-11 Stormytown
Post Office Box 218
Yorktown Heights, New York 10598
(This report will be available from this address up to
one year after the IBM publication date (up to Jan 1990))
This online version differs from the hardcopy report only
in pagination, and in using *asterisks* for emphasis. It
is formatted to print at 66 lines per page, and 80 or so
characters per line (including a 10 character margin on
either side).
We discuss computer viruses and related problems. Our intent is to help both executive and technical managers understand the problems that viruses pose, and to suggest practical steps they can take to help protect their computing systems.
While this document has been widely reviewed, and many helpful suggestions have been incorporated, the authors are entirely responsible for its present content. It does not represent the opinions, policies, or recommendations of IBM or any other organization.
Computer viruses present a relatively new kind of security problem in computing systems. The purpose of this section is to acquaint the senior management of an organization with the nature of the problem. It also outlines some of the steps that can be taken to reduce the organization's risk from computer viruses and other, similar, problems.
Traditional computer security measures are helpful, but new measures are needed to deal with the problems effectively. The computer security management of the organization will play a key role in reducing the risk. But education and ongoing participation of the users are also vital.
A computer virus is one kind of threat to the security and integrity of computer systems. Like other threats, a computer virus can cause the loss or alteration of programs or data, and can compromise their confidentiality. Unlike many other threats, a computer virus can spread from program to program, and from system to system, without direct human intervention.
The essential component of a virus is a set of instructions which, when executed, spreads itself to other, previously unaffected, programs or files. A typical computer virus performs two functions. First, it copies itself into previously-uninfected programs or files. Second, (perhaps after a specific number of executions, or on a specific date) it executes whatever other instructions the virus author included in it. Depending on the motives of the virus author, these instructions can do anything at all, including displaying a message, erasing files or subtly altering stored data. In some cases, a virus may contain no intentionally harmful or disruptive instructions at all. Instead, it may cause damage by replicating itself and taking up scarce resources, such as disk space, CPU time, or network connections.
There are several problems similar to computer viruses. They too have colorful names: worms, bacteria, rabbits, and so on. Definitions of them are given in the glossary. Each shares the property of replicating itself within the computing system. This is the property on which we will focus, using viruses as an example. There are also a variety of security issues other than viruses. Here, we will deal only with viruses and related problems, since new measures are required to deal with them effectively.
Let us examine a particular sequence of events, by which a virus could enter an organization and spread within it. Suppose that the organization hires an outside person to come in and perform some work. Part of that person's work involves working on one of the organization's personal computers. The person brings in a few programs to aid in this work, such as a favorite text editor.
Without the person having realized it, the text editor may be infected with a virus. Using that editor on one of the organization's machines causes the virus to spread from the editor to one of the programs stored on the organization's machine, perhaps to a spreadsheet program. The virus has now entered the organization.
Even when the outside person leaves, the virus remains on the machine that it infected, in the spreadsheet program. When an employee uses that spreadsheet subsequently, the virus can spread to another program, perhaps to a directory listing program that the employee keeps on the same floppy disk as the spreadsheet data files. The listing program is then infected, and the infection can be spread to other computers to which this floppy disk is taken. If the employee's personal computer is connected to the organization's network, the employee may send the listing program to another user over the network. In either case, the virus can spread to more users, and more machines, via floppy disks or networks. Each copy of the virus can make multiple copies of itself, and can infect any program to which it has access. As a result, the virus may be able to spread throughout the organization in a relatively short time.
Each of the infected programs in each of the infected machines can execute whatever other instructions the virus author intended. If these instructions are harmful or disruptive, the pervasiveness of the virus may cause the harm to be widespread.
Traditional security measures have attempted to limit the number of security incidents to an acceptable level. A single incident of lost files in a year may be an acceptable loss, for instance. While this is important, it only addresses part of the problem of viruses. Since a single virus may be able to spread throughout an organization, the damage that it could cause may be much greater than what could be caused by any individual computer user.
Limiting the number of initial viral infections of an organization is important, but it is often not feasible to prevent them entirely. As a result, it is important to be able to deal with them when they occur.
Most actual viruses discovered to date have either been relatively benign, or spread rather slowly. The actual damage that they have caused has been limited accordingly. In some cases, though, thousands of machines have been affected. Viruses can easily be created which are much less benign. Their potential damage is indeed large. Organizations should evaluate their vulnerability to this new threat, and take actions to limit their risks.
Once an organization makes a commitment to deal with the problems of computer viruses, there are specific areas which should receive attention. The purpose of this section is to acquaint technical management with the problems and to indicate the actions that can be taken to limit the risks posed by viruses.
There are many ways in which a system can become infected with a virus. Any time a program is run which can alter one or more other programs, there is the possibility of viral infection. Any time a user executes a program which is written by anyone else, compiled by a compiler, or linked with run time libraries, all the resources to which that program has access are in the hands of every person who contributed to that program, that compiler, or those libraries.
The initial introduction of an infected program can occur through a large variety of channels, including:
See the appendix for an example of sources and locations of possible infection for one operating system.
There are many kinds of threats to security. Threats traceable to dial-in systems are greatly reduced with the use of call-back systems. Simple threats created by disgruntled employees can often be traced to the person responsible. One important thing that makes the virus different from all the rest is its untraceability. Except in rare cases, the only way a virus' author becomes known is if the author admits to ownership. As a result, an author can create a virus with reasonable certainty that he will not be discovered. This allows great latitude in the design of the destructive portion of the virus.
The only perfect ways to protect against viral infection are isolation and reduced functionality. A computer system cannot be infected if it runs only one fixed program, and cannot have new programs either loaded or created on it. But this is clearly not very useful in many circumstances. So there is almost always some exposure. As with other security concerns, it is a matter of weighing benefits, practicality, and potential risks, and then taking cost-effective action to help control those risks.
Viruses exhibit elements of many other security threats. (See the Glossary for a summary of some of these threats.) There are important differences, though. Dr. Fred Cohen, who has done much of the original research on computer viruses, defines a virus as:
a program that can "infect" other programs by modifying them to include a possibly evolved copy of itself. (See reference (1).)
But a virus is more than the part that replicates itself. There is usually also a potentially damaging portion. This portion could be a "time bomb" (on November 11th, display a political message), a "logic bomb" (when it sees a certain write to disk, it also corrupts the file structure), or anything else the virus author can design. The variety of possible effects is part of the reason why the notion of a virus is so confusing to many people. The term "virus" is sometimes misused to refer to anything undesirable that can happen to a computer. This is incorrect. The thing that makes viruses and related threats different from other problems is that they spread.
Good security policies depend on the knowledge and cooperation of the users. This is just as true of security against viruses as it is of policies about password management. Users should be aware of the dangers that exist, should know what to do if they suspect they have found a security problem. In particular, they should know whom to call if they have questions or suspicions, and should know what to do, and what not to do, to minimize security risks. Users should be encouraged to feel that security measures are things that they want to do for their own benefit, rather than things that are required for no rational reason.
A strategy to detect and contain viruses is described below. An important part of that strategy is for users to know whom to call if they see a system problem that may be the result of a virus. Someone should always be available to work with the user in determining if a problem exists, and to report the problem to a central source of information if it is serious. This central source must have the ability to inform the necessary people of the problem quickly and reliably, and to set in motion the process of containing and solving the problem. More detailed suggestions for this mechanism will be given below, but each stage depends on education. It is important to educate the end users, the first-level support people, and management involved at all levels, since they must take the necessary actions quickly when a viral infection is detected.
Even without the threat of viruses, good backups are an important part of system management. When a program or a data file is lost, a good set of backups can save many days or months of work. The potential harm caused by computer viruses only increases the need for backups.
Although they are necessary for recovery, backups can also present a place for a virus to hide. When a virus attack has been stopped, and the virus removed from all software on the system, the obvious way to recover altered or lost files is by restoring them from backups. Great care must be taken not to reintroduce the virus into the system in the process!
All backups should be inspected to ensure that the virus is not present in any file on any backup. Until a backup has been certified "clean," it should not be used, unless certain files on it are not recoverable through other means. Even in this case, it is necessary to be very careful to restore only objects which the virus did not infect or otherwise change. The behavior of the virus should be well understood before any restoration from backup is attempted.
Viruses can spread from one user to another on a single system, and from one system to another. A virus can enter a company either by being written within the company, or by being brought in from the outside. Although a virus cannot be written accidentally, a virus may be brought in from the outside either intentionally or unintentionally. Viruses can enter a company because a program is brought in from outside which is infected, even though the person who brings it in does not know it.
Because sharing of programs between people is so commonplace, it is difficult to prevent an initial infection from "outside." An employee may take a program home to use it for business purposes on his or her home computer, where it becomes infected. When the program is returned to the workplace, the infection can spread to the workplace. Similarly, an outside person can bring a set of programs into a company in order to perform work desired by the company. If these programs are infected, and they are executed on the company's systems, these systems may also become infected.
There are two major ways to prevent infection in the first place, and to limit the spread of an existing infection: isolating systems, and limiting their function.
Since viruses spread to new users and systems only when information is shared or communicated, you can prevent viruses from spreading by isolating users and systems. Systems that are connected to other systems by a network can spread a virus across that network. Isolating systems from the network will prevent their being infected by that network. If a company maintains connections with other companies (or universities, or other institutions) by a network, a virus may be able to enter the company through that network. By isolating the company from such external networks, it cannot be infected by these networks.
This is a reasonable policy to follow when possible, especially for those systems which contain especially sensitive programs and data. It is impractical in many cases, though. Networks are valuable components of a computing system. The easy sharing of programs and data that they make possible can add substantially to the productivity of a company. You should be aware, however, that this sharing also increases the risk of viral infection to these systems. This is especially true if the network security measures have not been designed with viruses and related threats in mind.
Your organization may wish to limit the kinds of access to systems afforded to those outside the organization. In many cases, users of external systems may be less motivated to be benevolent to your systems than internal users are. This may make it worthwhile to limit the ability of external users to transmit executable files, or have full interactive access, to internal systems.
Similarly, movement of programs between personal computers on floppy disks can result in one system infecting another. If an employee's home computer is infected, for instance, bringing a program (or even a bootable disk) from home to work could result in the work computer becoming infected. You may want to have a policy that employees should not bring programs or bootable disks between work and home. Or, you may want to have a policy that employees should use virus-detection tools on their home computers as well as their work computers.
Since viruses must be able to infect other executable objects in order to spread, you can help prevent viruses from spreading by eliminating this ability from a computing system. This can be done in some circumstances by restricting the ability to add or change programs on a system.
If general-purpose programming must be done on a system, as is the case with development systems, it is not possible to prevent users from creating or adding new programs. On these systems, it is not possible to prevent the introduction of viruses under every possible condition.
Many companies have computing systems, including workstations and personal computers, that are not used for general-purpose programming. A bank, for instance, may use personal computers as teller stations, to handle a fixed set of teller transactions. Since the tellers need not program these systems, it may be possible to strictly limit the introduction of new programs and thus greatly limit the introduction of viruses onto them.
This is a prudent policy. Whenever practical, limit the ability of users to add or change programs on the systems they use. This ability should be restricted to authorized personnel, and these personnel should use every means available to them to check any new programs for viruses before they are installed in the limited-function systems. As long as no new programs are introduced, no new viruses can be introduced onto these systems.
Remember, though, that the trend in personal workstations has been toward the empowerment of the individual user, including giving the user the ability to create programs to suit his or her own needs. Thus, it may not be practical and competitive in the long run to impose restrictions on many systems. The risk of viral infection must be weighed against the benefits of providing power and flexibility to the individual user.
Software repositories are places in which programs reside which may be used by a number of people. These may be disks on a mainframe, which can be accessed from a number of different users' accounts. They may also be disks on a local area network file server, from which many users get common programs.
These repositories can pose more of a risk in the spread of viruses than most "private" program storage locations. If a commonly-accessed program becomes infected, such as a text editor used by an entire department, the entire department can become infected very quickly. So, extra care is required to prevent infection of repositories.
A policy can be put into place that requires each program added to a repository to be checked thoroughly for possible infection. It is helpful, for instance, to use tools to ensure that it is not infected with any of the already-known viruses.
In cases in which users who access the repository deal with especially sensitive programs and data, it may be prudent to enforce even more stringent policies. Programs to be added may be tested first on isolated systems, to see if they show any signs of infecting other programs. Or, a repository team may inspect the source code of the program for viral code. If no viral code is found, the repository team can compile the program on an isolated system that has been certified to be free of viruses. In such a case, the only object code allowed on the repository would come directly from the team's compilation on its isolated system.
Repositories can also be helpful in detecting and controlling viruses. Consider the situation in which most users run a significant amount of the software that they execute from a central server to which they do not have write access, rather than from individual writeable disks. Since the users do not regularly update this software, viruses will not be able to spread as quickly between these users. If a program on a central repository becomes infected, it may be comparatively simple to replace it with an uninfected version (or remove it entirely). It may be more difficult to screen all programs on hundreds of individual systems. It may also be easier to audit the usage of, and updates to, a single software repository, as opposed to a large number of individual systems.
There are a variety of other areas in many organizations which could spread viruses rapidly, and hence which should be carefully controlled. Internal software distribution centers, for instance, could spread a virus widely if they were infected. Similarly, a software lending library, if infected, may transmit a virus to many other users before it is detected. Walk-in demo rooms and educational centers are also potential problems. In general, any place from which software is widely distributed, and which has uncontrolled software importation, needs special attention.
Production systems are those systems which are used to prepare internally-developed programs for distribution either within a company, or for sale to external customers. If these systems were infected with a virus, the virus could spread to programs used widely within the company, or to programs used by the company's customers. In the former case, this could spread the virus widely throughout the company. In the latter case, it could damage the reputation of the company with its customers. There has been documented cases of companies accidentally shipping virus-infected program products to customers.
Since the infection of production systems could have serious consequences, you should be especially careful about protecting them. The key to this is the institution of stringent change control policies on production systems.
They should be strongly isolated from non-production systems, so that only known, authorized files can be put onto the system. Each file should be checked for infection, to whatever extent possible. Installing object code on these systems should be avoided whenever possible. Rather, source code should be installed, and compiled locally with a trusted compiler. Where the impact of a viral infection would be particularly large, it may be important to inspect the source code before it is compiled, to avoid the introduction of a virus through the source code. If object code must be installed, its origin should be verified beforehand. For instance, object code for a personal computer could be installed only from an original, write-protected distribution disk, which has been found to be free of viruses.
In addition, virus-checking programs (see below) should be run frequently on production systems. On a multitasking system, it may be possible to run a virus detector continuously in the background. Further, a policy can be instituted which ensures that a virus detector will be executed at least once between the time that new files are installed on the system, and the time that any files are exported from the system.
With the possible exception of isolation, all of the methods outlined above for preventing viral infections are only somewhat reliable. Viruses can still reach some systems despite the implementation of preventative measures. Indeed, no perfect defense exists that still allows programming, and sharing of executable information. There is no "one time fix," as there is for many other computer security problems. This is a hole that cannot be plugged completely. Defenses will have to be improved with time to deal with new classes of viruses. Because of this, virus detection is an important component of system security.
The two most important resources available for the detection of viruses are watchful users and watchful programs. The best approaches to virus detection include both. The users should be aware of the possibility of viruses, just as they are aware of the need for backups, and to know what kinds of things to watch for. System programs and utilities should be available to help the users, and the computer center staff, to take advantage of this awareness.
If users are aware of the kinds of visible things that are known to happen in systems that are virus-infected, these users can serve as an important line of defense. Users should know that odd behavior in a computer system may be a symptom of penetration by a virus, and they should know to whom such odd behavior should be reported.
On the other hand, it is a fact that odd behavior is usually not caused by viral penetration. Software bugs, user errors, and hardware failures are much more common. It is important to avoid unfounded rumors of viral infections, as dealing with such "false alarms" can be costly. An actual infection, however, may require rapid action. So the group to which users report oddities must have the skill to determine which reports are almost certainly due to one of these more common causes, and which merit closer investigation for possible viral infection. One obvious choice for such a group is within the computing center or "help desk," since the computing center staff probably already has a good idea of what sorts of oddities are "business as usual."
This section lists specific oddities that are known to occur in workstations infected with particular viruses that have already occurred. Some of the things in these examples only occur once the virus is in place, and is triggered to perform its particular function. Others occur while the virus is still spreading. Some things users should know to watch for include:
It is important to remember, though, that future viruses may do none of these things. Users should be alert to oddities in general and should have a place to report them, as recommended above.
Viruses in multi-user computer systems share some of the typical behaviors of viruses in single-user workstations. In particular, lengths or time stamps of executable files may change, programs may load or execute more slowly, unusual errors (especially relating to disk-writes) may occur, files may vanish or proliferate, and odd things may appear on displays. If the virus is attempting to spread between users, users may also notice "outgoing mail" that they did not intend to send, "links" to other user's information that they did not intentionally establish, and similar phenomena.
Generally, the same comments apply in this environment as in the single-user workstation environment. Future viruses may do none of these things, and users should be sensitive to suspicious oddities in general, and have a place to which to report them.
Users are not the only line of defense in the detection of viruses. It is comparatively simple to create programs that will detect the presence and the spread of the simpler classes of viruses. Such programs can go a long way in "raising the bar" against computer viruses.
One effective approach to detecting simple viruses involves notifying the user of changes to the contents of executable objects (program files, "boot records" on magnetic media, and so forth). Users can be provided with a program to be run once a day which will examine the executable objects to be checked, and compare their characteristics with those found the last time the program was run. (This could be run at the same time as the backup program, for instance.) The user can then be presented with a list of objects that have changed. If things have changed that should not have, the user can contact the appropriate people to investigate. If certain objects that should seldom or never change (such as the operating system files themselves) are different, the user can be specially warned, and urged to contact the appropriate people.
Often, a central system programming group has control over a large multi-user computing system. That group can execute this sort of program periodically, to check for changes to common operating system utilities, and to the operating system itself. Because viruses can often spread to privileged users, they are quite capable of infecting even those parts of the system that require the highest authority to access.
The frequency with which virus detectors should be used depends upon the rate at which executables are transmitted, and the value of the information assets on the systems. Workstations that are not connected to networks can exchange information via floppy disks. The known computer viruses that propagate by way of floppy disks do so relatively slowly. It may take days, or weeks, or even months for such a virus to propagate across a large organization. In this case, running virus detectors once a day, or once a week, may be sufficient. For systems connected to networks, especially large-scale networks, the situation is much different. Experience has shown network viruses to be capable of spreading very rapidly across the network. In some cases, replicating programs have spread across nationwide networks in a matter of hours or days. In these cases, it may be important to run virus detectors hourly or daily.
Below is an outline of one possible implementation of a virus detecting program. It is for illustration only; many different structures would do the job as well or better.
This method is by no means foolproof. A sophisticated virus could do a variety of things. It could change an executable object without altering the time, date, length, or CRC code. It could only alter objects that had been legitimately changed recently. It could act directly on the database itself and thus escape detection. More sophisticated versions of the program outlined here can provide significantly more foolproof detection. It is advantageous to have many different virus detectors in place at the same time. That way, a virus that can evade one detector may be caught by another. Nevertheless, user awareness, and procedures for recovery in the event of an infection that is not detected until too late, are both still vital.
(1) For PC-DOS, this would typically include the boot record on a floppy diskette, and the master and partition boot records on hard disks. For multi-user operating systems, this might include "shared system images," or "IPL datasets" or equivalent objects.
Software viruses are able to spread because information flows so quickly in the modern world. That same information flow can help in the detection of viruses. Newspapers, magazines, journals, and network discussion groups have carried significant amounts of material dealing with computer viruses and other forms of malicious software. These sources of information can be valuable in maintaining awareness of what hazards exist, and what measures are available to detect or prevent specific viruses. This kind of information can be invaluable to the people in your organization charged with investigating suspicious events reported by users, and deciding which ones to follow up on. On the other hand, these channels also carry a certain amount of inevitable misinformation, and care should be taken not to react to, or spread, rumors that seem to have no likely basis in fact.
Having procedures in place to detect viral infection is very important. By itself, however, it is of little use. The individual who makes the first detection must have a procedure to follow to verify the problem and to make sure that appropriate action occurs. If the information supplied in the detection phase is allowed to "fall between the cracks," even for a relatively short time, the benefit of detection can easily be lost.
Computer viruses generally spread exponentially. If a virus has infected only one system in a network on Monday, and spread to four by Tuesday, sixteen systems could easily be infected by Wednesday, and over five hundred by Friday. (These numbers are just samples, of course, but they give an idea of the potential speed of spread. See reference (1) for some experiments in which much faster spread was observed.)
Because viruses can spread so fast, it is very important to detect them as early as possible after the first infection. The surest way of doing this is to have every vulnerable user run the best available virus-detection software as often as feasible. This solution may be too expensive and time-consuming for most environments.
In most groups of users, it is possible to identify a number of "star" users who do a disproportionately large amount of information-exchange, who generally run new software before most people do, and who are the first to try out new things in general. In multi-user systems, some of these people often have special authorities and privileges. When a virus reaches one of these people, it can spread very rapidly to the rest of the community. In making cost/benefit decisions about which users should spend the most time or effort on virus-detection, these are the people to concentrate on.
When a virus is detected, every moment spent deciding what to do next may give the virus another chance to spread. It is vital, therefore, to have action plans in place before an infection occurs. Such plans should include, for instance:
Some suggestions for recovery are given in the next section.
Once a virus has been detected and identified, and measures have been taken to stop it from spreading further, it is necessary to recover from the infection, and get back to business as usual. The main objective of this activity is to provide each affected user with a normal, uninfected computing environment. For individual workstations, this means ensuring that no infected objects remain on the workstation. For more complex environments, it means ensuring that no infected objects remain anywhere on the system where they might inadvertently be executed.
The basic recovery activities are:
It is of critical importance during these activities to avoid re-introducing the virus into the system. This could be done, for instance, by restoring an infected executable file from a backup tape.
An obvious but incorrect approach to removing the infection from a system is simply to restore the infected objects from backups. This is not a wise thing to do, however, since the backups themselves may be infected. If the virus first entered the system sufficiently long ago, infected objects may well have been backed up in infected form.
Once the virus has been well understood, in terms of what types of objects it spreads itself to, three different categories of objects may be considered for restoration:
Once a virus has been studied, you can write or obtain programs to help remove that particular virus. One type of these programs checks for the presence of the virus in a executable objects. Another type tries to remove the infection by restoring the object to its previous uninfected form. "Checking" programs can be extremely valuable during the recovery process, to ensure that files that are being restored after infection or damage by the virus are now "clean." "Removal" programs are somewhat less useful, and should usually only be used when there is no other practical way to obtain an uninfected version of the object. Removing a virus from an executable object can be a complex and difficult process, and even a well-written program may fail to restore the object correctly.
Once recovery is complete, and all known infected and damaged objects have been restored to uninfected and correct states, it is necessary to remain watchful for some time. A system that has recently been infected by a certain virus runs an increased risk of re-infection by that same virus. The re-infection can occur through some obscure, infected object that was missed in the recovery process. It can also occur from the same outside source as the original infection. This is especially true if the original source of infection is not known.
Vigilance in the use of general virus-detection programs, like those described above, continues to be important. In addition, it will often be possible to obtain or write programs designed to detect the specific virus from which the system has just recovered. Specific virus-detection programs of this kind are particularly useful at this time. The same users who use the general virus-detection programs, and any users who would be specifically vulnerable to the virus just recovered from, can be given such programs to run. This increases the probability of detection, should an infection recur. The programs might also be incorporated into the backup system for a time, to scan files being backed up for infection, and even into appropriate places in networks and file-sharing systems. Because such checks will introduce extra overhead, there will be a trade-off between performance and added security in considering how long to leave them in place.
Computer viruses can pose a threat to the security of programs and data on computing systems. We have suggested several means of limiting this threat. They are summarized below.
Computer viruses and the like are relatively new phenomena. The terms used to describe them do not have definitions that are universally agreed upon. In this glossary, we give definitions that try to clarify the differences between the various concepts. These terms may be used differently elsewhere.
This section is intended to give an example of the places in a typical computer system where a virus might enter. It is intended for a reader with some knowledge of the workings of PC-DOS, although it may be instructive to others as well. PC-DOS was chosen for convenience; many computer systems have similar vulnerabilities.
Consider the process that is required for you to run a single program. What is happening? Which parts do you not bother checking since you have seen it a million times?
For example, you turn on the power switch and then ...
This list is not meant to be all-inclusive nor thorough. It is meant to be a spark to start education. Let us continue by examining each of these cases. (Where found, the symbol "(!)" is used to designate a potential point of attack for viruses.)
Before we investigate the different cases above, we examine the steps that occur when you first flip the power switch of your IBM PC to the ON position.
Power is given to the system. A section of code known as POST (Power On Self Test) residing in ROM (Read Only Memory) starts running. It checks memory, devices, peripherals, and then transfers control to any "properly signatured" ROMs found in the I/O channels. Assuming those pieces run smoothly, control returns to POST. When POST completes, it searches for a diskette in the diskette drive. If unsuccessful, it tries to boot off a hard file. And finally, if neither works, it starts running the BASIC interpreter which is found in its ROM.
The first place where programs are read into system RAM (Random Access Memory) is the hard file or diskette boot up process. Until then, all the code that is run has come from ROM. Since these ROMs are from trusted sources, we must assume that they have not been created with viruses installed. ROMs, by their nature, can only be written by special equipment, not found in your PC. Thus to tamper with them, they must be removed and/or replaced without your knowledge. For the purposes of this discussion, we will assume that this has not happened.
When the computer boots off the hard file, it relies on code which has been placed in two areas on the hard file. The first location is the master boot record(!). The master boot record contains code and information to designate which "system boot record"(!) to read and run. This is the "active partition." There are potentially many system boot records, one for each partition, while there is only one master boot record.
Boot records on a fixed disk vary. But usually, up to a whole track is reserved. This is a large amount of space, most of which is not normally used. The large empty space provides a potential area for viruses to hide.
For a floppy disk, the boot record is a properly "signatured" sector at head 0 track 0 sector 1 of the disk(!). If the machine finds a proper signature, it takes the bytes stored in that sector and begins executing them. This code is usually very short. Usually, one of the first things it does is to tell the machine where to get other sectors to form a complete boot up program.
Viruses can hide parts of themselves on either hard or floppy disks, in sectors that they mark as "bad."(!) These sectors would require special commands to be read. This prevents the code from being accidentally overwritten. They also provide an obvious sign, should you be looking for them (CHKDSK will report bad sectors).
The purpose of the boot records is to load the operating system. This is done by loading files with the names IBMBIO.COM(!), IBMDOS.COM(!), and COMMAND.COM(!). These files contain the operating system.
After the operating system is loaded, it becomes the integral portion of all system activities. This includes activities such as reading and writing files(!), allocating memory(!), and allocating all other system resources(!). Few applications exist that do not use the operating system to take advantage of the system resources. Thus, some viruses change COMMAND.COM or intercept attempts to request a system resource.
The purpose of such action would be two-fold. The first purpose is to place the virus in a common code path, so that it is executed frequently so that it may have ample opportunity to spread. The second is to cause damage, intercepting the proper request and altering the request.
What code runs when you run a program? (!) (The following list is not meant to be complete. It is to show you that any link could be a potential point of attack for a virus. Since the virus' purpose is to be executed frequently, it would find itself executed frequently enough if it resided in any of the following areas.)
All these things happen and more, each time you run a program.
Every time you boot your system, CONFIG.SYS(!) and AUTOEXEC.BAT(!) tell the system to load many files and options before you can start working on the computer. If a virus decided to attach an extra line of instruction to one of these files, it would result in the program being loaded each day. When was the last time you looked at CONFIG.SYS? AUTOEXEC.BAT? Do you remember the reason for the existence of each line in the two files?
When you compile a program, you use several programs. One is the compiler itself (!). If the compiler is infected with a virus, the virus may spread to other, unrelated programs. But it could also spread to the program being compiled.
When a compiled program is linked to form an executable program, it is common to link in programs from libraries(!). These library programs provide standard operating system interfaces, perform input and output, and so on. If one or more of the library programs are infected with a virus, then every program which is linked with it will be infected.
[Back to index] [Comments (0)]