C1 Technical Report 001: Technical Report, Computer Viruses: Prevention, Detection, and Treatment, 12 March 1990
497e593a2fc854fcbd7aab1ad6ba2645a56dff287bf6ce5710bd51c5faa31e8e<head>
<title>Computer Viruses: Prevention, Detection, and Treatment</title>
</head>
<body>
<pre>
C1 Technical Report 001
Library No.: S232,522
6 June 1989
COMPUTER VIRUSES:
PREVENTION, DETECTION, AND TREATMENT
by
Mario Tinto
This publication contains technical observations, opinions, and evidence
prepared for informal exchange among individuals involved with computer
security. The information contained herein represents the views of the
author and is not to be construed as representing an official position of
the National Computer Security Center.
Reviewed by: ________________________________
BLAINE W. BURNHAM
Chief, Criteria and Technical Guidelines
Division
Released by: ________________________________
ELIOT SOHMER
Chief, Office of Computer Security
Evaluations,
Publications and Support
TABLE OF CONTENTS
Executive Summary 1
I. Introduction: The Symptoms 1
II. Treatment and Prevention 3
A. Technical Measures 3
1. Trusted Computing Base 3
2. Access Controls 4
a. Discretionary Access Control (DAC) 4
b. Mandatory Access Control (MAC) 5
3. Audit Trails 6
4. Architecture 7
5. Least Privilege/Role Enforcement 8
6. Identification and Authentication 9
B. Procedural and Administrative Measures 9
1. Passwords and Password Management 10
2. Configuration Control 11
3. Operational Procedures 11
4. Facility Management 11
5. User Awareness 12
6. System Evaluations 13
C. Synopsis of Countermeasures 13
III. Summary 15
APPENDIX 17
I. The Issue 17
II. The Analysis 17
a. Infection 17
b. Effects of the Virus 19
References 20
COMPUTER VIRUSES:
PREVENTION, DETECTION, AND TREATMENT
Executive Summary
There has been, of late, considerable interest in the topic of computer
viruses. The debate has been especially brisk since the so-called
"Internet Virus" of November 1988. At one extreme are those who declare
that viruses are an essentially new phenomenon, against which we are
powerless. At the other end of the spectrum are those who treat viruses
as more of a semantics problem than a technical one, claiming that the
problems they pose have already been solved under different terminology.
Where then is reality? This paper makes the case that the situation, while
certainly not ideal, is not nearly as bleak as some of the alarmists would
claim, and that existing technology and security-oriented procedures are
extensible to the virus threat. Further, these are largely captured in
the DoD Trusted Computer System Evaluation Criteria (TCSEC). However,
while the available techniques are relevant, they supply only partial
solutions; perfect and universal countermeasures against all possible
virus scenarios do not exist. If we are to determine whether or not such
are possible, much less develop them, further R&D activity is required.
I. Introduction: The Symptoms
Viruses are a form of the classical Trojan horse attacks and are
characterized by their ability to reproduce and spread. However, like all
Trojan horses, they first must be "imported" and executed by an authorized
user; the attacker typically dupes an unsuspecting individual into
accepting and executing the virus. The malicious code may be buried in
what are presented to be otherwise useful utilities (e.g., spreadsheets,
text editors), which then operate with the user's own authoritzations to
cause harm. The offending code may be present in a code segment the user
"touches," which then attaches itself to the user's program, without the
user ever realizing that he is importing a virus. For instance, a virus
may be implanted in system library utilities (e.g., sort/merge routines,
mathematics packages) and servers.
While a virus (or Trojan Horse) is normally considered to be limited to
the authorizations of the user who is executing the code, the virus can
clearly exploit any flaws in the system that would allow the user to enter
privileged state (although such attacks are more correctly seen as
traditional penetration attacks). If the user who executes the infected
code has system privileges (e.g., a system administrator), then the virus
will be able to do still more severe damage, depending upon the specific
privileges available to it.
The critical point is that viruses depend upon their ability to exploit
the legitimate capabilities of authorized users. In order to be
successful, a virus must replicate and infect other programs without
detection.
II. Treatment and Prevention
As with their biological namesakes, computer viruses come in a variety of
types; their missions can be modification or theft of data, or denial of
service. Their methods of attack will be as numerous and varied as the
weaknesses manifest in systems. Thus, perfect and universal solutions are
not likely; there will be no single solution developed capable of
preventing any and all virus attacks. Such a solution is certainly not
currently available. However, that is not to say that we are powerless to
combat viruses, contain their effects, or limit their capability to do
damage. The defenses against viruses are both technical and procedural.
More specifically, the principles and mechanisms provided in the TCSEC,
especially at class B2 and above, provide a variety of valid defenses
against a large class of malicious code and, when applied effectively, can
severely limit both the scope of the attack and the extent of the damage.
A. Technical Measures
1. Trusted Computing Base
The TCSEC has, as a central theme, the extremely strong notion of a
Trusted Computing Base, or TCB (i.e., the implementation of the Reference
Monitor concept). In essence, the TCB is the central policy enforcement
mechanism for the computer system, mediating the actions of all system
users and user processes. Among the important characteristics of the TCB
is that it be always invoked (i.e., unbypassable, mediates each and every
access) and self-protecting (i.e., cannot be modified by user code). The
consequence of requiring architectures that provide such mechanisms is to
limit the ability of hostile code to subvert the TCB. Beginning at the C1
level of trust, fundamental protection mechanisms are required that
provide protection of the system programs and data from unprivileged
users. Many existing systems (e.g., PCs running DOS) lack even these
basic protections required at C1, thus allowing a virus executed by any
user to infect any part of the system, even those most basic to system
operation and integrity. Commencing with the B2 level of trust, we expect
that there will be no fundamental design flaws that allow the security
mechanisms to be circumvented. Thus, in the absence of penetration paths,
a virus would be limited to attacking users on an individual basis. This
means that the rate at which it could propagate would be reduced, as would
the damage it could inflict.
It can be argued that a virus capable of infecting each and every user in
the system (one that was present in the text editor, for instance) would
be reasonably effective at accomplishing some missions (e.g., denial of
service). Thus, the value of an intact TCB in the face of an otherwise
completely infected user population is moot. However, it is still true
that a strong and self-protecting TCB, at a minimum, forces a virus to
infect users one at a time. It can also prevent some forms of attack (see
2.b, Mandatory Access Controls, below), and assure the existence and
protection of the audit data by which viruses may be detected and traced.
In fact, a strong TCB represents the central protection mechanism that a
virus must overcome in order to infect the text editor in the first place.
2. Access Controls
Among the fundamental principles that provide the foundation to the TCSEC
is that of policy enforcement, the need for the computer system to enforce
an access control, or sharing, policy. For both technical and historical
reasons, the principle of policy enforcement translates in the TCSEC into
access control mechanisms. Specifically, these are:
a. Discretionary Access Control (DAC)
Discretionary Access Control provides the mechanisms that enforce
user-defined sharing, also known in some communities as "need-to-know."
Beginning at C1, the TCSEC requires that it be possible for the owner or
manager of each data file to specify which users may access his data, and
in what modes (e.g., Read, Modify, Append). Clearly, such a mechanism
provides control over both acquisition and modification of data by Trojan
horses and viruses. In order for the malicious code to carry out its
mission, it would have to be executed by someone who already possessed
valid permissions against the data being targeted. If that user is not
the owner, then the capability of the attack code to do harm would be
limited by the allowed permissions (e.g., if the user who was being
attacked had "READ-ONLY" access, the attack code could copy the data, but
could not modify or erase it). While discretionary access control
mechanisms provide relatively weak protections, they do constitute a
hurdle that a virus must overcome, and can slow the rate at which the
virus propagates.
b. Mandatory Access Control (MAC)
Mandatory Access Control provides those mechanisms that enforce corporate
policy dealing with the sharing of data. Examples of such polices would
be: "only members of the payroll staff may read or change payroll data,"
and "classified data may only be accessed by those having the appropriate
clearances." Beginning at the B1 level, the TCSEC requires computer
systems to be capable of enforcing MAC as well as DAC. That is, the
system must be able to enforce those more formal rules dealing with
either, or both, levels of sensitivity (e.g., DoD classification scheme)
and categories of information (e.g., payroll, medical, R&D, corporate
planning). Thus, the ability of a user to access and manipulate data is
based upon the comparison of the attributes of users (e.g., "member of
payroll department," "member of R&D staff," "management," or "clearance
level") with the attributes of the data to be accessed (e.g., payroll
data, R&D data, classification level). Because it is required that the
TCB control and protect these attribute designators (or, "labels"), they
constitute a "hard barrier" for a virus, effectively limiting the scope of
what it may do; in a properly designed and implemented system a virus
would be unable to effect any changes to the labels. This means, for
instance, that a virus that is being executed by someone in the PAYROLL
department would be limited to doing damage strictly within the set of
data that is labelled accordingly. It would have the potential to modify
or destroy PAYROLL data, but not access R&D or MEDICAL data.
Additionally, a virus could not change any labels, which means that it is
unable to prevent PAYROLL data from being passed to anyone who is not a
member of the payroll staff. Likewise, a virus could not cause "SECRET"
data to be downgraded. In short, MAC is an extremely strong mechanism,
which prevents any process, including a virus, from making properly
labeled information available to users who are not authorized for the
information. Systems that achieve TCSEC levels of B2 or greater
essentially guarantee that information will not be "compromised," i.e., no
malicious code can violate the restrictions implied by the labels.
It needs to be noted that the way in which mandatory controls are
typically used is to prevent compromise, which is to say that the emphasis
is on preventing "high" data from being written into a "low" file. This
does not, in itself, prohibit viruses from propagating, either via a "low"
user writing into a "high" file, or a "high" user importing software from
a "low" file. However, it should be noted further that the mandatory
controls provide the opportunity for implementing similar controls for
writing (or importation) as for reading. Such controls are usually seen
as implementing mandatory integrity policies, such that the ability to
modify files is based upon a set of integrity labels, analogous to the
classification labels used to regulate the reading of data. Some systems
exist (e.g., Honeywell SCOMP) that have implemented such mechanisms.
3. Audit Trails
The collection of audit data is a traditional security mechanism that
provides a trace of user actions such that security events can be traced
to the actions of a specific individual. The TCSEC requires, commencing
at class C2, that the TCB "...be able to create, maintain, and protect
from modification or unauthorized access or destruction an audit trail of
accesses to the objects it protects." Because an effective virus depends
upon its ability to infect other programs and carry out its mission
without detection, audit data provides the basis not only for detecting
viral activity, but also for determining which users have been infected
(i.e., by identifying which user is responsible for the events in
question). Clearly, the collection of data is merely the foundation for
detection. To fully implement a sound program, audit reduction and
analysis tools are also required. These are also provided for in the
TCSEC. Considerable advancement in this arena is reflected by the
recently developed intrusion detection systems; sophisticated real-time
audit analysis and event-reporting systems, some based on artificial
intelligence (or, "AI") techniques. These typically provide extensive
capability for detecting a variety of anomalous behavior, and thus can be
"tuned" for known or suspected viral patterns. While the available
systems are still largely developmental, the early results are quite
promising.
4. Architecture
While it is certainly important to identify the correct set of security
features that are needed in a system, it is equally important to provide
the assurances that the features work as intended, are continually
present, and are uncircumventable. Such assurances are provided by the
underlying architecture, namely, the hardware support for the features,
and the hardware and software design. The TCSEC stresses the importance
of architecture and adequate hardware support for the security mechanisms.
Even at the lowest level of trust defined by the TCSEC (i.e., C1)
fundamental protection mechanisms are required that provide protection of
the systems programs and data from unprivileged users. Such protection
is usually implemented by multistate hardware. Starting with B2, the
TCSEC places strong emphasis upon design, design analysis, and
architectural features that provide for isolation of user programs from
each other as well as isolation of system programs from user programs.
Such mechanisms not only prevent viruses from casually infecting system
programs (e.g., the TCB), but also make it more difficult for the virus to
spread from user to user.
As an example of the gain to be realized by the right choice of system
architecture, type-enforcement architectures are worthy of special note.
These systems provide the potential for extremely fine-grained control of
executing code, such that a virus would be incapable of performing any
action that is not explicitly allowed by the type-enforcement mechanism.
And, because all access to data and resources is via a common, central
mechanism (i.e., the type manager), protection need only be focused on the
code authorized to manipulate the data and resources, rather than
attempting to protect all user programs. By way of illustration, such
systems could quite easily enforce the following policy, or set of access
rules, which a bank might wish to enforce:
* Tellers may make changes only to those accounts for which
they are authorized.
* They may only make changes to specific fields (e.g., may
not change the account number, depositor name).
* They may only make the changes authorized between the
hours of 9:00 a.m. and 5:00 p.m., Monday through Friday.
* Transactions that exceed $1,000 require the authorization
of a supervisor, while transactions that exceed $5,000 require the
authorization of the bank manager.
The capabilities of a virus that attached itself to a teller's process in
such a system would be, mildly speaking, somewhat circumscribed.
5. Least Privilege/Role Enforcement
A virus that is executed by a user with privilege (i.e., a user that is
permitted by the system to circumvent some part or all of the system's
security policy) provides an enormous threat to the entire system,
because, in assuming the legitimate user's identity, it would be able to
circumvent the normal controls that protect other users' programs and
data. In many systems, the virus would also be able to circumvent the
controls that protect the system itself from modification.
Least Privilege is a familiar concept in the computer security community,
and deals with limiting damage through the enforcement of separation of
duties. It refers to the principle that users and processes should
operate with no more privileges than those needed to perform the duties of
the role they are currently assuming. That is, a user who may take on
more than one role or identity (e.g., administrator and unprivileged user,
Project A and Project B), should only be given the authorizations needed
at the moment, rather than all the privileges he can assume for any and
all roles that may be assumed. In contrast, many current systems support
only a single, all-powerful system administrator (note especially, the
UNIX role of "superuser"). Beginning at the B2 level, trusted systems
limit the capabilities of privileged users to those capabilities necessary
to accomplish the prescribed task. Beginning at the B3 level, privileged
users cannot, in their privileged roles, execute any non-TCB code. The
consequence is that, in such a system, a virus could not infect a
privileged user's programs, and thus could not exercise his privileges.
In addition, at B3 and higher, privileged functions that may modify any
security-critical system data or programs require the use of "trusted
path" (i.e., require an explicit, unforgeable, action from the privileged
user) in order to prevent these actions from being performed without the
explicit knowledge and cooperation of the privileged user. This means
that no virus could affect security critical data or programs
surreptitiously, since it could not cause any modifications without the
privileged user becoming aware of the requested actions, thus making the
virus visible.
6. Identification and Authentication
Identification and authentication ensures that only authorized users have
any access to the system or information contained on the system. It also
forms the basis for all other access control mechanisms, providing the
necessary user identification data needed to make decisions on requested
user actions. While passwords are the oldest and perhaps the most
familiar form of personal identifiers used to authenticate users to
computer systems, also available today are biometric techniques and "smart
card" devices.
B. Procedural and Administrative Measures
While technical measures are necessary for controlling what code segments
a process may access, what actions it may take, and the conditions under
which it can operate (i.e., what goes on inside the computer), total
system security also involves effective site security procedures and
system management. This is particularly true because poor procedures can
negate the positive effects of some of the technical controls. As an
example, audit data collected by the system, and the availability of even
the most sophisticated audit analysis tools are of little value if the
audit logs are never reviewed, nor action ever taken as a result of
questionable activity.
The following should in no way be seen as an exhaustive list of procedures
and management practices effective in addressing the virus threat.
Rather, it is intended to be merely illustrative of the manner in which
procedural controls are complementary of technical capability.
1. Passwords and Password Management
Historically, passwords have been among the first targets on which an
attacker would focus attention. They have traditionally been an easy
target with high payoff potential. Because a person's password is often
the key to all his data and authorizations, they are analogous to a safe
combination. By extension, attacking the password file is akin to
targeting the safe that holds the combinations to all the other safes in
the building. Thus, good password management and practices can go a long
way toward limiting virus attacks. A virus counts on its ability to
infect other programs. Thus, either the target must import the virus and
execute it as his own (i.e., with his own privileges and authorizations),
or the virus must be able to "become" the user to be infected by invoking
his password. (It might be noted, in passing, that the November 1988
Internet virus contained extensive password attacks). If the virus cannot
successfully log in as an arbitrary user (e.g., by stealing or guessing
valid passwords), then it is limited to attempting to fool users into
executing the virus code. The trivial ease with which user passwords can
be guessed and entire password files can often be attacked is usually
nothing short of shocking. Truly effective countermeasures to such
attacks are easy to implement and relatively inexpensive. They often
amount to not much more than sensible management.
2. Configuration Control
A virus represents code that was not intended to be part of a program or
the system. Thus, procedures for maintaining valid and known system
configurations, for validating and approving shared code (e.g., software
library routines), and for distributing approved programs and media (e.g.,
diskettes) can provide further obstacles to viral infestation.
3. Operational Procedures
While there may be some commonality across computer sites, it is also true
that each site will offer its own unique set of problems. Thus,
operational procedures typically need to be tailored to fit the needs of
the particular environment, and defenses against viruses will need to be
designed into the procedures that govern the day-to-day operation of the
site. As an example, recovery from a known or suspected virus attack
might require a clean copy of the system. This, in turn, implies
procedures for verifying the source and correctness of the backup copy,
protecting it from modification until it is to be installed, and for
installing it safely. Likewise, management policies and procedures
dealing with the importation of code can also provide a measure of
resistance to viruses. The establishment of the policy will tend to
heighten awareness of the danger of bringing unknown software into the
work environment, while effective procedures for controlling the
importation of software will make it more difficult for a virus to be
introduced.
4. Facility Management
While a computer system may provide a variety of security-related
mechanisms, they must be used and, more importantly, used correctly, if
any measure of protection is to be achieved. Large, complex systems offer
a special challenge, in that there are typically a variety of
configuration options, and can support a large number or users, which may
be grouped into different "communities" and classes, each with unique
attributes, security restrictions and privileges, and with a different
view of the system. This translates into a particularly difficult job for
the system security administrator; it is imperative that he get everything
right simultaneously. There will be many opportunities to configure the
system such that needed security features are not active, or that the
choice of options invalidates the action of a security feature that was
activated. The second case is probably worse, because the security
administrator believes that he has activated a security feature when, in
fact, he has inadvertently caused the desired protection mechanism to be
rendered ineffective. In short, the desired security characteristics of
the system, while achievable, can easily be lost in the complex detail of
configuring and maintaining an operational environment. Thus, it is
critical that there be support for the system administrators such that
they can make effective use of the available security features of, and
configure and provide life-cycle support for, the level of policy
enforcement needed. Toward this end, the TCSEC, at all levels, demands
that the vendor provide the purchaser of the product a "Trusted Facility
Manual," a document that describes, in a single volume or chapter, all the
security mechanisms supported by the system, and provides guidance on how
to use them. It is a document aimed explicitly at the system security
administrator, and as such, it provides the information necessary to fully
understand system security mechanisms, how to use them properly, and the
potential harm of poor implementation and configuration choices (e.g.,
insufficient auditing).
5. User Awareness
Virtually every shared-resource system available today provides facilities
for users to specify some level of protection for their data. These may
be in the form of User/Group/World mechanisms, Access Control Lists
(ACLs), or other features that allow users to specify how, and with whom,
information is to be shared. However, in order to be effective, the
features must first be used, and they must also be used properly. This
clearly means that the users need to be cognizant of the protection
features that are provided to them, and understand how they operate. Here
also, the TCSEC provides support for this level of user awareness in that
it requires that the vendor provide a separate document (i.e., the
Security Features User's Guide), explicitly aimed at system users, which
apprises them of the security mechanisms that are available to them.
While, as noted earlier, most user-specifiable protection mechanisms are
not proof against determined hostile attack (at least, not in most current
implementations), such protection features do provide a barrier that a
virus must overcome; it is clearly easier to steal or damage files that
are not protected than those that are. It is certainly easier for a virus
to escape detection if there exist no system-enforced prohibitions against
the actions it is attempting to carry out.
6. System Evaluations
It is standard practice, at least within the DoD and Intelligence
communities, to have systems undergo an accreditation process, a formal
and reasonably well-defined process for determining the acceptability of
systems. The critical facet of the process is centered about the
"certification," which involves the assessment of the system capabilities
as measured against the original requirements definition (e.g., the RFP,
system specifications), and typically also takes into account any system
vulnerabilities that have been discovered. The certification process is a
technical assessment of the system, and thus subjects the system to some
level of technical scrutiny. Thus, any flaws, either in system design or
in implementation detail, are more likely to be discovered. This is a
direct benefit of the current evaluation process directed toward the
evaluation of products against the TCSEC. The evaluation process will, in
addition to assuring that the TCSEC requirements are satisfied, tend to
discover and correct poor design, poor implementation choices and, in some
cases, will discover and correct penetration paths. Clearly, processes
that find and correct errors and eliminate penetration paths will tend to
raise the cost to the attacker.
C. Synopsis of Countermeasures
As discussed earlier, the mission of a virus can be classified as one or
more of the standard threats to information security, namely, unauthorized
modification, unauthorized disclosure, and denial of service. Technical
as well as procedural and administrative countermeasures exist that
address these threats, and thus will, in general, limit the success of
malicious code attempting to carry out such attacks.
a. Identification and authentication, discretionary access controls,
process isolation, and auditing are relevant countermeasures for the virus
whose mission is to destroy or modify user data. Likewise, TCB
protection, least privilege, trusted path, and auditing will also serve as
valuable countermeasures against the virus whose mission is to destroy or
modify system programs and data structures.
b. Identification and authentication, mandatory access controls, and
discretionary access controls provide effective countermeasures against
viruses whose mission is to cause unauthorized disclosure of information.
c. Because infection requires that the virus be able to modify or replace
some existing program, all of the technology and procedural
countermeasures that are designed to prevent unauthorized modification of
programs will make it harder for a virus to attach itself to legal user
processes.
d. The current state of the art in computer security provides only very
limited countermeasures against denial of service. Identification and
authentication mechanisms ensure that only authorized users have access to
system resources, while auditing allows the system administrator to
determine to what extent particular users use or abuse system resources.
These controls thus ensure that a virus can attack only those system
resources that the infected user is allowed to use, as well as keeping a
record of utilization that may make virus detection easier.
III. Summary
Clearly, as stated above, there are no universal cures; no single set of
procedures and technical measures guaranteed to stop any and all possible
virus attacks. However, this is not different from any other everyday
security situation. Specific mechanisms tend to be designed to combat
specific dangers, in the same way that vaccines are developed to combat
specific diseases. Thus, preventive measures are intended to raise the
cost of attacks, or to make it less likely that a specific class of attack
will be successful. Similarly for viruses. While viruses can exploit
any and all flaws in our computer systems and networks, they also tend to
be classes of attacks with which we are already familiar. Thus, while
there is valid concern for our vulnerability to virus attacks, a
dispassionate analysis shows that our previous experience in computer
security is relevant - the protective measures and technology we have
developed are directly applicable, and provide a good baseline for making
headway against these attacks. In addition, good environmental controls
are critical; while technical measures are necessary for controlling what
data and resources a user process may access, what actions it may take,
and the conditions under which it can operate (i.e., what goes on inside
the computer), total system security also involves effective procedures
and system management.
On the one hand, it may be argued that viruses present no new technical
challenges. The attacks they carry out are the attacks that have been
postulated virtually since the advent of time-sharing. However, the
intellectual process is such that one determines a threat, or attack
scenario, and then develops specific countermeasures. Thus, the classical
approach has led us to consider attacks and develop responses on an
individual basis. A virus not only propagates, but may also carry out any
or all known attacks, thus potentially presenting us with a universal set
of attacks in one set of hostile code. However, what is truly
revolutionary about viruses is that they change the way in which we will
have to view the processing and communications support available to us, in
the same way that "letter bombs" would cause us to radically change the
way we viewed the postal system, i.e., from beneficial and useful to
hostile and potentially dangerous. Where we have previously put great
confidence in our computing resources ("If the computer said it, it must
be correct"), we will now have to consider those resources as potentially
hostile.
Viruses also will cause us to change our view of the very intellectual
environment - the sharing of software can no longer be as casual as it was
once was. Perhaps this should not be surprising. The attacks that were
originally postulated and designed against (e.g., penetrations, Trojan
horses, trapdoors) were predicated on a relatively uncomplicated computing
environment. The communications explosion now confronts us with a
considerably more complex, richly interconnected computing and
communications environment. In this environment, viruses are the concern.
This means that, while our previous experience is extensible to the new
threats, R&D is still needed. While there is considerable debate over
whether or not viruses present a completely new set of problems, there is
certainly no disagreement concerning our abilities to combat them; most
will concede that, at best, today we have only partial solutions. Perfect
solutions may be possible, but a better understanding of the root
technical issues, development of theory, and testing of countermeasures is
required before we can know for certain.
In short, viruses and other forms of malicious code are seen as an
extension of classical computer security threats into the current
computing and communications environment. The capabilities we have
already developed to combat the threats of yesterday apply perfectly well
against viruses, but are not perfect solutions. If we are to develop
still better solutions, R&D in this area is critical.
APPENDIX
Analysis of Internet Virus
and the Evaluation Process
I. The Issue
Among the first questions asked within the NCSC immediately following the
November Internet Virus attack was, "Could the attack have been prevented,
or at least ameliorated, by the product evaluation process?" It is
instructive to determine the impact the TCSEC requirements and the current
evaluation process would have had on the virus and the flaws it was able
to exploit.
The following assumes that the reader is familiar with the details of the
specific attacks, and no effort is made to describe or otherwise elaborate
on the technical details of the virus.
II. The Analysis
The question to be answered is, "What effect would trust technology and/or
product evaluation have had on the effectiveness of the virus?" The
responses fall into two main areas: methods of attack (i.e., which flaws
or features were exploited), and the effects of the attack.
a. Infection
The virus used three methods to infect other systems: 1) a subtle bug in
the "finger" daemon software, 2) the "debug" feature of the "sendmail"
program, and 3) the ability of a user to determine other users' passwords.
The bug in the "finger" daemon (or, fingerd) software would likely not be
caught in a C1-B1 level evaluation. There is a moderate chance that it
would have been found in a B2-A1 evaluation. If discovered in any
evaluation, a fix would not have been required by the NCSC as the problem
would not affect the system's ability to enforce the security policy; it
does not appear in the TCB, but rather in user space. Most vendors would,
however, fix the bug simply to make the system more robust.
At the same time, it is important to note that this attack was successful
largely because other routines, which made use of fingerd, did not perform
the bounds checks required to catch the error being exploited. A system
being designed against the TCSEC would be sensitive to the need for
complete parameter checking, at least for security-critical or otherwise
privileged codes. Additionally, the evaluation process, at any level,
would likely identify fingerd as code being used by privileged programs,
thus raising the probability that the flaw would either be found or
obviated. This is clearly the case for systems at B2 and beyond; while
the flaw that allowed the virus to attack users might still appear
(depending on the implementation choices made), the B2 requirements are
such that privileged processes would not be dependent on any unevaluated
code.
The debug feature of sendmail had a moderate chance of being discovered in
a C1-B1 evaluation. The feature would almost certainly have been
discovered in a B2-A1 evaluation. When discovered, the team would only
have been able to force the vendor to document the feature, as its
presence would not affect the system's ability to enforce the security
policy.
Here also, it is fair to point out that in a product that was designed to
conform with TCSEC requirements, sendmail might well have been seen as
integral to the TCB (i.e., a security-critical process). As such, it
would have been more closely scrutinized and, beginning at B2, been
subjected to penetration testing. To the extent, however, that sendmail
is strictly within user space (i.e., not within the TCB boundary), the
evaluation process is not likely to turn up flaws such as was exploited by
the virus.
The ability of a user to generate other users' passwords as a result of
being able to read the password file (albeit encrypted) would have been
detected in any evaluation, and the vendor would have been forced to
correct the problem. It is important to note that the virus contained an
extensive capability to guess user passwords. While it is not clear to
what extent the virus actually resorted to this attack, inexpensive and
well-known password management procedures would have a major impact on
password attacks, and thus would considerably impair the propagation rate
of any virus that depended on them.
b. Effects of the Virus
The primary effect of the virus was the consumption of processor time and
memory to the point that nonvirus processes were unable to do any useful
work. For the systems in question any valid user could have produced the
same effect because the system enforces few useful limits on resource
utilization. The current state of the art in trust technology provides no
better than partial solutions for dealing with the issues of inequitable
use of system resources. B2-A1 evaluations will address so-called "denial
of service" problems, but the presence of problems of this type will not
adversely affect the rating. That is, evaluators will look for, and
report on, attacks that can monopolize system resources or "crash" the
system. However, since no objective way yet exists to measure these
effects, they do not influence the rating. Instead, it is left to the
accreditation authority to determine the impact in his environment, and to
implement any necessary countermeasures (e.g., quota management routines,
additional auditing).
References
1. Continuing Education Institute, "Software-Oriented Computer
Architecture," Course notes, 1984.
2. Department of Defense, Department of Defense Trusted Computer System
Evaluation Criteria (DoD 5200.28-STD), December 1985.
3. Gasser, M., Building a Secure Computer System, Van Nostrand Reinhold,
1988.
4. Gligor, V. D., "Architectural Implications of Abstract Data Type
Implementations," Proceedings of the International Symposium on Computer
Architecture, Philadelphia, PA, May 1977.
5. Lunt T., "Automated Audit Trail Analysis and Intrusion Detection: A
Survey," Proceedings of the 11th National Computer Security Conference,
October 1988.
6. Spafford, E. H., "The Internet Worm Program: An Analysis," Purdue
Technical Report, CSD-TR-823, November 28, 1988.
</pre>
</body>
</html>
© 2022 Packet Storm. All rights reserved.
%7Cutmcsr%3D(direct)%7Cutmcmd%3D(none)){kind=small}
Follow us on Twitter
Follow us on Facebook
Subscribe to an RSS Feed