Ghannam Al-Dossary
Proceedings of International Carnahan Conference on Security Technology, 1989. Zurich, Switzerland
October 1989
Download PDF (763.04Kb) (You need to be registered on forum)A computer virus can be a vicious and insidious form of code. It has the ability to replicate itserf, to attach itself to other code, to spread through a computer system or network, and often to initiate a harmful series of instructions when a "trigger" point is reached. Viruses can havea major impact on productivity because of the steadily increasing dependence of industrial, business, and government functions on the availability and integrity of data processing systems. Although mainframe computers have been the target of virus attacks less often than microcomputers up until now, there is no room for complacency when the stakes are so high. The novelty, the technical nature, and the tendency to romanticize this phenomenon, have resulted in a "blackbox" syndrome ("I don't know what's going on in there.") and a feeling of overwhelming impotence in the business community.
The risk of viruses can be reduced. One approach is to examine the constituent parts from which a virus is composed, and to design a comprehensive defense which reckons with each of these parts. The protection chain will only be as strong as its weakest link. The author of this paper suggests a classification scheme which is useful in understanding the components of a virus and useful methods for maintaining the integrity of a computer system.
This paper outlines basic prevention, detection, and correction techniques which are available today to reduce the threat of damages caused by viruses. These include software "vaccines" or filters; encryption; access control software (e.g. RACF, ACF2, and Top Secret); "test-to-production" control procedures; back-up and recovery procedures; personnel selection and review controls; and physical access control.
The concepts presented in this paper conform to the "Trusted Computer System Evaluation Criteria" developed by the United States Computer Security Center and use eramples from major published virus incidents to illustrate the price of control weaknesses. The paper concludes that no working computer system is impregnable but that much can be done by industry to make most computer systems less inviting to attacks from viruses.
A bibliography is included for further study.
A virus is a parasitic form of computer code which has the particular characteristic of being able to reproduce itself. Not only may it produce exact copies of itself which multiply exponentially through a system [1] but in some cases it may produce an evolved copy of itself which is able to adapt to the conditions which it encounters in a particular environment.[2] Although the vast majority of virus attacks reported to date [3] have been against personal computers, the threat against mainframe computers is continuing and limited publicity should not be an excuse for complacency. The original research on viruses was conducted on mainframe computers [2] and it was demonstrated that viruses are easily created on any commercially available operating system including MVS, VM, VMS, and Unix. The published incidents of mainframe virus attacks show that the creation of a virus may even be accidental rather than intentional [4] when systems are poorly designed.
The virus concept exploits one of the most fundamental qualities of general purpose computing systems: the leveraging effect of making more information available to more people. A lever is a powerful tool in moving a desired object toward a specific goal. However, a very small or subtle shift in the location of the fulcrum (caused, for instance, by the introduction of a virus to a computer program) can cause the desired object to move rapidly away from the goal. The goal of computing is to provide information. A virus can deny the availability of information processing services or can distort the information itself. (Special function viruses can also theoretically increase information availability [2] but that is not included in the subject of this paper.)
The same computer hardware may be used to meet an wide variety of disparate computing needs. Software, like an idea, can often be shared, copied, and used over and over again in thousands of machines with millions of repetitions without dissipating or reducing the power or effectiveness of the original application. A virus may exploit both the known hardware characteristics of a particular system and the shareability of software. It has been theoretically demonstrated that virus contamination cannot be contained without interfering with the shareability of software. [2] Total isolationism is the only complete cure for viruses but a significant risk reduction is possible through a limited compromise in software shareability. [5]
Viruses exploit the Von Neumann computer architecture which is common in almost all business computing systems today. This architecture treats stored software as data which can be dynamically modified to meet varying requirements. This is true of both operating system and applications programs. Viruses take advantage of this ability of executable programs to be changed, to introduce new purposes which maybe at variance with the purposes of the owner of the computer system or application.
A stored (and potentially modified) program may remain dormant as a file for a significant period of time before it is executed and any changes are detected. This delay allows the infection to spread throughout the computer system and to any other system receiving output from the first system. The original technical analysis of viruses conceived of a very sophisticated strain of virus which would be active across operating systems. (Telecommunications have made significant advancements since that time.) The conclusion: "If a computer virus of this type spread through the computers of the world, it would likely stop the majority of computer use for a significant period of time, and wreak havoc on modern government, financial, business, and academic institutions." [2]
The code in a virus may be divided into two parts. The first part is the reproductive or survival mechanism which copies the code and attaches it to target programs. The second part is the purpose or hidden intention of the virus. This second part has two subsections. The first is the trigger which activates or initiates the purpose. The trigger may be based on a date/time; the discovery of a particular program or account number; a count of the number of interrupts or calls; the extent of infection (e.g. the number of times the virus has copied itself); or any other discreet condition or combination of conditions which the author may conceive. The other subsection is the code which produces the result. This may take the form of a warning ("Got'cha!"); a cute picture on the screen; modified data; destruction of data (e.g. the erasure of a disk or tape); the activation of some other program; or any other action which code may normally accomplish.
Based on these building blocks, known viruses may be classified according to the following categories which are useful in detection/prevention strategies.
The GCAM virus will attach itself to any program or executable filew hich promises to help perpetuate the existence of the virus. (Some "vaccines" search only certain types of files or the front of a program in ferreting out a virus [6] but the virus may be located at the end or anywhere in the middle.) Early experimenters were able to create functional GCAM mainframe viruses with under 100 bytes of code. Poorly designed GCAM viruses often draw attention to themselves by altering the program's overall length [7]; reinfecting the same program multiple times [8]; or altering the "date-of-last-modification" associated with the program. However, all of these clues can be easily camouflaged by more effective design. The date can often be restored to its former value after the infection has taken place. A subtle "signature" can identify infected programs to prevent reinfection. The length of the program can be maintained by condensing inefficient code, overwriting non-critical code, or by calling subroutines stored in other areas.
The SCAM virus seeks out specific categories (or one category) of an application or system program for its habitat. Therefore the spread of infection is much slower,but it is also much more difficult to detect. In certain types of programs, a well disguised virus may even be impossible to detect by anyother means than a byte-by-byte comparison to a copy of the program which is known to be uncontaminated. This approach is certainly difficult if the program is dynamic and there are multiple active versions available. SCAM viruses often exploit known "bugs" or defects in particular programs. These defects can provide a point of entry, a camouflage mechanism, or access to powerful utilities. The author of a SCAM virus must, of course, be intimately familiar with the target program.
The GTAR virus has been the most common type reported by the news media. This is probably because it is easiest to code and the most dramatic or sensational in its result. When the "trigger" is initiated, a whole disk is reformatted or a tape overwritten. The GTAR virus seeks attention but is not too particular about its audience. It does not generally discriminate between target disk drives, target terminals, or target files. Any target which it can reach is good enough. Because the type of command swhich it is likelyto use can be generalized, the GTAR virus is more easily recognized and neutralized than the STAR virus.
The STAR virus is specific in its target and purpose. Therefore, it requires more sophistication and application-specific knowledge in designing its trigger. A STAR virus may attempt to initiate a financial instrument when an account number is located, or change coordinates in a military application when a particular weapons system is discovered. Even after the virus has executed its purpose, its presence may not be disclosed. Data may be changed and the virus may even self-destruct, leaving no traces. This type of virus does not result so much in denial of service (as with the GTAR virus) but in perversion of the purpose of the services.
These categories may result in the following combinations: GCAM-GTAR, GCAM-STAR, SCAM-GTAR, and SCAM-STAR. Each has direct application and impact on the detection and prevention tools which are used to counteract their effects.
The only known method of completely securing a computer system against viruses is total isolation. That would remove the functionality of most business computers. However, good management and security practices can greatly reduce the risk and provide an effective defense against most viruses. The broad concepts presented here do not go into technical details but references are provided for further study. These concepts are more comparable to driving a car than to expounding on the mysteries of the internal combustion engine. These practices include:
and
The purpose of a virus filter is to recognize a particular type (or types) of virus to prevent it (or them) from entering into a system, and to prevent reproduction. Vaccines attempt to identify viruses which are already present in the system; to eliminate them, if possible; and to prevent reproduction. The means of accomplishing these ends are many and varied. A Swedish company called Secure Transmission AB has developed a set of programs called "T-Cell" which they say "several major Swedish manufacturer's have incorporated into their mainframe systems." [9] One of their obvious precautions was to try to protect the T-cell programs themselves from becoming infected by strictly limiting access to those programs. Every data file and program in the system is protected by a "seal" which is difficult to reproduce. If the seal is altered, the system assumes an unauthorized intrusion. Standard "safe" copies of operating system software and utilities are maintained for comparison to operational versions and for recovery, if necessary. Many different strategies are employed by other vendors. None of these vaccines has been used long enough to measure their operational effectiveness. For maximum protection they should be incorporated with access control software such as ACF2.
The most useful MVS operating system virus detection tool known to the author is CA-Examine. This set of programs has compiled an extensive knowledgebase of the internal structure of MVS in order to analyze key system libraries and memory resident modules. It is capable of detecting superzaps, corezaps, modreps, and other system modifications. Using expert system techniques, these programs conduct an analysis of operating system parameters to identify abnormalities and unauthorized changes. It provides interactive followup which allows the user to decide which problems deserve the most attention. CA-Examine is not an automatic panacea and is not of much use to the MVS-novice but can be very effective in detecting viruses in MVS in the hands of a knowledgeable user.
By their nature, filters and vaccines concentrate on GCAM and GTAR viruses. They are only useful against SCAM or STAR viruses after a specific virus is known and analyzed. This is similar to closing the barn door after the horses have escaped.
IBM, Corporation installed a "filter" to prevent viruses after an inadvertent virus brought down their international VNET network and left 100,000 users in 80 countries without telecommunications in December of 1987. The problem began when a law student in Germany (not a professional programmer) sent a friendly holiday message to an associate. The greeting also included a command to copy the recipient's mail distribution list and send the same messageto everyone on the list. Each new recipient's mail distribution list was copied and the message multiplied. Within hours VNET collapsed under the weight of too many messages. [10]
Encryption appears to be a virus' worst enemy. However, the care and feeding of the encryption package can be expensive. This technique, for the present, is usually reserved for highly critical systems. Pozzo and Gray[11] have contributed the most extensive discussion of the tradeoffs of encryption protection against viruses to date. They argue that the most effective plan is to encrypt all executables within a system. (An "executable" is any software which can be understood and initiated by the operating system or other software.) If the author of the virus cannot get to the executable before it is encrypted or cannot break the encryption algorithm, the virus can never be executed. Even if the virus does get to a particular executable before it is encrypted, the virus will not be able to spread to another executable, and a virus which does not reproduce is not a virus (which does not mean that is is not irritating).
A less expensive approach is to append an encrypted signature block to the plain-text executable ("plain-text" to the programmer who understands the language.) The signature block would be the result of applying a strong one-way encryption function (e.g. a cryptographic checksum) to the entire executable plus a password from the authorizer and a time stamp. The entire signature block would then be encrypted. Before execution, a public key would be used to decipher the block and the checksum would be recomputed. This process is trivial compared to encrypting the entire executable but still expensive enough to require careful analysis before the investment is made. A third and still weaker approach is to use encrypted signature blocks for only critical or highly used programs. Pozzo and Gray also examine the tradeoffs between public key and private key designs.
The most effective general purpose virus prevention technique is access control software such as ACF2, RACF, or Top Secret. (In the author's experience, ACF2 is the most cost-effective of these three.) There are many other reasons for installing access control software, but virus prevention is a fortuitous side effect. Because this software restricts access to critical files (programs), modifications cannot be made unless the virus has already attached itself to a program with high level access. This points out the necessity of constructing useful rule sets across the system. Access control software will not protect against poor rule-writing nor against users with high level privileges such as the security administrator, system auditor, or system programmers. These users must be competent and trusted in order to preserve the integrity of the system.
"Test-to-production" software control procedures limit the introduction of new software to the operating environment and restrict access to high level programs where viruses are likely to be effective. These procedures include software testing, verification, quality assurance review, and written authorization before implementation. Usually production programs are only executed from controlled libraries and those libraries are carefully restricted. Providing a separate but controlled development environment keeps viruses out of the production system. These procedures apply to software modifications and enhancements as well as to completely new software. The ability to track and keep a historical record of software introduction is critical to the integrity of the whole system. The purpose and nature of any changes should be recorded along with the authorization. Software purchased from outside vendors should go through the testing procedure just like the internally developed software. Contracts with software vendors should include provision for liability in the case any undetected virus is latent in the vendor's product. No modification or enhancement should ever by made directly to base code. This rule may delay an urgent "fix" but it will save even greater delays from "fixes" which don't work or contain unauthorized side effects. High-privilege system users should check each other's work. Systems programmers' work should be randomly (or constantly) reviewed by the Auditors and Computer Security Personnel.
If a virus is discovered and there is no reliable method of deleting it, or if a file has been erased by the virus, often the only solution is to reload a clean copy of the original program or data. For most large data processing centers, monthly, weekly, daily, or in some cases even hourly backups are standard procedure. There are many sound reasons for backing up software and data; protection against viruses is a secondary benefit. However, it is also necessary; without backup, recovery from a virus attack might be impossible.
The backup copies also provides a standard to compare against operational versions in the case that a modification is suspected but not proved. Of course, the system must be virus-free at the time of the recovery or the backup copy will also become infected. The process of insuring that the system is virus-free may cost time and effort, but the alternative is even more costly. Also if it is not known how long the virus has been in the system, a particular backup copy may already be infected. In that case, an earlier generation must be recalled.
Some people create viruses. Other people prevent or reduce the risk of viruses. Untrusted data processing personnel can be a system's worst enemy. Viruses have been possible for over twenty years. The U.S. Military has been in contact with live viruses for over ten years [12], but only recently have viruses become a significant problem to the general public. The "popularity" (as well as the population) of viruses seems to be closely correlated to the negative feelings of certain individuals against computer owners or users. Careful screening of employee candidates can help to prevent many problems before they develop. Many difficulties can be prevented by clearly defined termination procedures, including cancellation of computer privileges before other termination processing begins.
Physical access controls are an effective virus prevention technique to the extent that "safe" users can be identified and allowed to complete assigned work. Perimeter access controls reduce the number of potential virus perpetrators. Keeping computer terminals in locked or closely supervised rooms has proved to be a cost-effective technique for many companies. Physical access controls applies to input devices (terminals, keyboards, and disk/tape drives) and to the data itself (which may be stored on disks, tapes, or other media.) Shredding unneeded output and systems manuals can also reduce exposure. Many virus authors have begun their efforts by pulling a discarded computer manual out of a trash bin. A corporation's trash may be a virus author's treasure.
These protection efforts (vaccines/filters, encryption, access control software, test-to-production controls, backup and recovery plans, personnel selection and review, and physical access controls) are not independent measures but part of an interlocking protection chain. Some are more important than others in some situations, but none of them should be ignored or eliminated from consideration without evaluating the risks. By way of analogy, underwater mines might be a necessary safeguard against a potential naval attack, but that does not eliminate the need for radar against an unanticipated air attack. Virus perpetrators are looking for the easiest entry point to a system. The protection chain is only as strong as its weakest link.
The virus problem was identified in 1983: "Virus attacks are easy to develop in a very short time, can be designed to leave few if any traces in most current systems, are effective against the average modern security policies for multi-level usage and require only a minimal effort to implement. [2] The answer to the problem is better than "average" (in historical terms) security controls. Basic management and security policies can greatly reduce the exposure and provide cost-effective protection for corporations and government agencies who take the effort to implement them.