Matt Bishop
Department of Computer ScienceUniversity of California at Davis
One Shields Ave.Davis, CA 95616-8562
Abstract
This note presents a new model for classifying vulnerabilities in computer systems.The model is structurally different than earlier models, It decomposes vulnerabilitiesinto small parts, called \"primitive conditions.\" Our hypothesis is that by examiningsystems for these conditions, we can detect vulnerabilities. By preventing theseconditions from holding, we can prevent vulnerabilities from occurring, even if wedo not know that the vulnerability exists. A formal basis for this model is presented.An informal, experimental method of validation for non- secure systems isdescribed. If the model accurately describes existing systems, it guides thedevelopment of tools to analyze systems for vulnerabilities.
1. Introduction and Problem Statement
Errors in computer systems and programs are called bugs. Many studies have analyzed the originsof bugs, how to decrease the number of bugs in a system, and how to test for (informally verify)and prove (formally verify) the lack of bugs in a program. Tools such as bounds-checkingcompilers, dynamic debuggers, and profilers let programmers check for specific bugs in theprogram. Methodologies such as stepwise refinement breaks the process of design andimplementation into a set of steps that simplify the refinement of the problem to a solution. Buteven with all these techniques and technologies, bugs still exist.
Bugs that enable users to violate the site security policy are called vulnerabilities or security holes(or holes for short). Vulnerabilities seem to be omnipresent. In every system fielded, programmingerrors, configuration errors, and operation errors have allowed unauthorized users to enter systems,or authorized users to take unauthorized actions. Efforts to eliminate the flaws have failedmiserably; indeed, sometimes attempts to patch a vulnerability have increased the danger. Further,designers and implementers rarely learn from the mistakes of others, in part because these securityholes are so rarely documented in the open literature.
Security holes arise from inconsistencies or errors in design, in implementation, in operation, and inmaintenance. Inconsistencies occur when the requirements of the security policy (an axiomaticdefinition of the term \"secure,\" developed from external factors that do not concern us here) arephrased poorly, misunderstood, or not interpreted consistently. For example, suppose a policystates that \"electronic mail will be confidential.\" Does this mean that the sender’s address and therecipient’s address are to be confidential? The designer of the transport mechanism may assume so,and expect the user agent to encode the sender and recipient names. But the designer of the useragent may expect the transport layer to encode the sender’s address and recipient’s address afterpulling out the source and destination addresses. The failure to protect these addresses may violatethe security policy, causing a vulnerability.
The theme of vulnerabilities analysis is to devise a classification, or set of classifications, that enablethe analyst to abstract the information desired from a set of vulnerabilities. This information may bea set of signatures, for intrusion detection; a set of environment conditions necessary for an attackerto exploit the vulnerability; a set of coding characteristics to aid in the scanning of code; or otherdata. The specific data used to classify vulnerabilities depends upon the specific goals of theclassification. This explains why multiple classification schemes are extant. Each serves the needsof the community or communities to which its classifier belongs.
The problem of interest is to discover these vulnerabilities before attackers can exploit them. Weseek a classification scheme with the following properties:
1. Similar vulnerabilities are classified similarly. For example, all vulnerabilities arising from race
conditions should be grouped together. However, we do not require that they be distinct fromother vulnerabilities. For example, a vulnerability involving a race condition may requireuntrusted users having specific access permissions on files or directories. Hence it should alsobe grouped with a condition for improper or dangerous file access permissions.
2. Classification should be primitive. Determining whether a vulnerability falls into a class requires
a “yes” or “no” answer. This means each class has exactly one property. For example, thequestion “does the vulnerability arise from a coding fault or an environental fault” isambiguous; the answer could be either, or both. For our scheme, this question would be twodistinct questions: “does a coding fault contribute to the vulnerability” and “does anenvironmental fault contribute to the vulnerability.” Both can be answered “yes” or “no” andthere is no ambiguity to the answers.
3. Classification terms should be well-defined. For example, does a “coding fault” arise from an
improperly configured environment? One can argue that the program should have checked theenvironment, and therefore an “environmental fault” is simply an alternate manifestation of a“coding fault.” So, the term “coding fault” is not a valid classification term.
4. Classification should be based on the code, environment, or other technical details. This means
that the social cause of the vulnerability (malicious or simply erroneous, for example) are notvalid classes. This requirement eliminates the speculation about motives for the hole. Whilevalid for some classification systems, this information can be very difficult to establish and willnot help us discover new vulnerabilities.
5. Vulnerabilities may fall into multiple classes. Because a vulnerability can rarely be characterized
in exactly one way, a realistic classification scheme must take the multiple characteristicscausing vulnerabilities into account. This allows some structural redundency in that differentvulnerabilities may lie in the same class; but as indicated in 1, above, we expect (and indeeddesire) this overlap.The remainder of the paper is organized as follows. The next section reviews earlier vulnerabilityclassification schemes, gives examples of vulnerabilities, and demonstrates they do not meet ourrequirements. We then consider a scheme for analyzing the implementation of a system with aproveably secure design. The fourth section analyzes this scheme to determine whether the result isapplicable to systems that do not have a proveably secure design. We discuss experiments, andpresent several examples of the requisite analysis. We then discuss how to develop tools to detectvulnerabilities, or to prevent their exploitation (or both). We conclude with some open researchissues and a summary.
The next section reviews the goals and characteristics of previous classification schemes, andexplains why they are inadequate for our needs.
2. Prior Work
In the 1970s, two major studies classified security flaws. One, the RISOS study [1], focused onflaws in operating systems; the other, the Program Analysis (PA) study [2], included both operating
systems and programs. Interestingly enough, the classification schemes both presented weresimilar, in that the classes of flaws could be mapped to one another. Since then, other studies havebased their classification schemes upon these results [3, 4]. However, the RISOS and PA schemesdo not take the level of abstraction or point of view into account. Further, their classes are broadlydefined, and non-primitive and overlapping (by the above requirements).
Aslam’s recent study [5], as extended by Krsul [6], approached classification slightly differently,through software fault analysis. A decision procedure determines into which class a soft ware faultis placed. Even so, it suffers from flaws similar to those of the PA and RISOS studies.
This section contains a review of the PA, RISOS, and Aslam classification schema. We then showthat two security flaws may be classified in multiple ways under all of these schemes.2.1. RISOS
The RISOS (Research Into Secure Operating Systems) study defines seven classes of securityflaws:
1.Incomplete parameter validation – failing to check that a parameter used as an array index is in
the range of the array;
2.Inconsistent parameter validation – if a routine allowing shared access to files accepts blanks in
a file name, but no other file manipulation routine (such as a routine to revoke shared access)will accept them;3.Implicit sharing of privileged/confidential data – sending information by modulating the load
average of the system;
4.Asynchronous validation/Inadequate serialization – checking a file for access permission and
opening it non-atomically, thereby allowing another process to change the binding of the nameto the data between the check and the open;
5.Inadequate identification/authentication/authorization – running a system program identifiedonly by name, and having a different program with the same name executed;6.Violable prohibition/limit – being able to manipulate data outside one’s protection domain; and7.Exploitable logic error – preventing a program from opening a critical file, causing the program
to execute an error routine that gives the user unauthorized rights.Some ambiguity between the classes indicates that one vulnerability may have multipleclassifications; for example, if one passes a pointer to an address in supervisor space to a kernelroutine which then changes it, the tuple of the flaw is 1 (incomplete parameter validation) and 6(violable prohibition/limit). This is a symptom of the problem with using these classes as ataxonomy.2.2. PA
Neumann’s presentation [4] of this study organizes the nine classes of flaws to show theconnections between the major classes and subclasses of flaws:1.Improper protection (initialization and enforcement)
a.improper choice of initial protection domain – “incorrect initial assignment of security orintegrity level at system initialization or generation; a security critical function manipulatingcritical data directly accessible to the user”;
b.improper isolation of implementation detail – allowing users to bypass operating systemcontrols and write to absolute input/output addresses; direct manipulation of a “hidden”data structure such as a directory file being written to as if it were a regular file; drawinginferences from paging activity
c.improper change – the “time-of-check to time-of-use” flaw; changing a parameterunexpectedly;
d.improper naming – allowing two different objects to have the same name, resulting inconfusion over which is referenced;e.improper deallocation or deletion – leaving old data in memory deallocated by one processand reallocated to another process, enabling the second process to access the informationused by the first; failing to end a session properly2.Improper validation – not checking critical conditions and parameters, leading to a process’
addressing memory not in its memory space by referencing through an out-of-bounds pointervalue; allowing type clashes; overflows3.Improper synchronization;
a.improper indivisibility – interrupting atomic operations (e.g. locking); cache inconsistencyb.improper sequencing – allowing actions in an incorrect order (e.g. reading during writing)4.Improper choice of operand or operation – using unfair scheduling algorithms that block certain
processes or users from running; using the wrong function or wrong arguments.
The problem with this classification is the breadth of the categories. Like the PA classification,vulnerabilities may fall into multiple classes, and the same vulnerability falls into different classesdepending on the level of abstraction at which the analysis is conducted.
2.3. Aslam's model and Krsul's work
This taxonomy wad developed to organize vulnerability data being stored in a database.Consequently it is far more detailed than the other two, but it focuses specifically on UNIX faults atthe implementation level:
1.Operational fault (configuration error)
1a.Object installed with incorrect permissions1b.Utility installed in the wrong place
1c.Utility installed with incorrect setup parameters2.Environment fault3.Coding fault
3a.Condition validation error
3a1.Failure to handle exceptions3a2.Input validation error
3a2a.Field value correlation error
3a2b.Syntax error
3a2c.Type & number of input fields3a2d.Missing input3a2e.Extraneous input3a3.Origin validation error
3a4.Access rights validation error3a5.
Boundary condition error
3b.Synchronization error
3b1.Improper or inadequate serialization error3b2.Race condition error
The classification scheme of this study is more precise than those of the PA and RISOS studies. Itprovides more depth for classifying implementation-level flaws (“faults” in the language of thisstudy). This appears to meet our requirements at the implementation level; the scheme clearly lacksthe high-level categories to classify design errors. In fact, it suffers from a more severe problem.2.4. Problems with using these models
To motivate our discussion of problems, consider a buffer overflow attack.
The Internet worm of 1988 [7] publicized this flaw, but it continues to recur, most recently inimplementations of browsers for the World Wide Web and some versions of the SMTP agentsendmail. The finger protocol obtains information about the users of a remote system. The clientprogram, called finger, contacts a server, called fingerd, on the remote system, and sends a name ofat most 512 characters. The server reads the name, and returns the relevant information.
But the server does not check the length of the name that finger sends, and because the storagespace for the name is allocated on the stack, directly above the return address for the I/O routine.The attacker writes a small program (in machine code) to obtain a command interpreter, and pads itto 512 bytes. He or she then sets the next 24 bytes to return to the input buffer instead of to therightful caller (the main routine, in this case). The entire 536 byte buffer is sent to the daemon. Thefirst 512 bytes go in the input storage array, and the excess 24 bytes overwrite the stack locations inwhich the caller’s return address and status word are stored. The input routine returns to the code tospawn the command interpreter. The attacker now has access to the system.
gets localvariablesother returnstate inforeturn addressof mainparameter togetsinput buffermain localvariablesgets localvariablesother returnstate infoaddress ofinput bufferprogram toinvoke shellprogram toinvoke shellmain localvariablesaftermessageThis flaw depends upon the interaction of two processes: the trusted process (fingerd) and a secondprocess (the attacker). For the fingerd flaw, the attacker writes a name which is too long. Further,the processes use operating system services to communicate. So, three processes are involved: theflawed process, the attacker process, and the operating system service routines. The view of the flawwhen considered from the perspective of any of these may differ from the view when consideredfrom the perspective of the other two. For example, from the point of view of the flawed process, theflaw may be an incomplete validation of a parameter, because the process does not adequately checkthe parameter it passes to the operating system via a system call. From the point of view of theoperating system, however, the flaw may be a violable prohibition/limit, because the parameter mayrefer to an address outside the process’ space. Which classification is appropriate?
Levels of abstraction muddy this issue more. At the lowest level, the flaw may be (say) aninconsistent parameter validation, because successive system calls do not check that the argumentrefers to the same object. At a higher level, this may be characterized as a race condition, or
asynchronous-validation/inadequate-serialization problem. At an even higher level, it may be seen asan exploitable logic error, because a resource (object) can be deleted while in use.
The levels of abstraction are defined differently for every system, and this contributes to theambiguity. (For example, the THE system has 6 [8]; PSOS has 15 [9].) In what follows, the“higher” the level, the more abstract it is, without implying precisely where in the abstractionhierarchy either level occurs. Only the relationship, not the distance, of the levels is important in thiscontext.
With respect to the fingerd process and the PA taxonomy, the buffer overflow flaw is clearly a type2 flaw, as the problem is not checking parameters, leading to addressing memory not in its memoryspace by referencing through an out-of-bounds pointer value. However, with respect to the attackerprocess (the finger program), the flaw is of type 4, because an operand (the data written onto theconnection) is improper (specifically, too long, and arguably not what fingerd is to be given). Andfrom the operating system’s point of view, the flaw is a type 1b flaw, because the user is allowed towrite directly into what should be in the process’ space (the return address), and execute whatshould be treated as data only. Note this last is also an architectural problem.
Moving still higher in the layers of abstraction, the storage space of the return address is a variableor an object. From the operating system point of view, this makes the flaw be type 1c, because aparameter – specifically, the return address – changes unexpectedly. From the fingerd point of view,though, the more abstract issue is the execution of data (the input); this is improper validation,specifically not validating the type of the instructions being executed. So the flaw is a type 2 flaw.At the highest level, the system is changing a security-related value in memory, and is executing datathat should not be executable. Hence this isw again a type 1a flaw. But this is not a validcharacterization at the implementation level, because the architectural design of the system requiresthe return address to be stored on the stack, just as the input buffer is allocated on the stack; and asthe hardware supporting the UNIX operating system does not have per-word protection (instead, itis per page or per segment), the system requires that the process be able to write to, and read from,its stack.
With respect to the fingerd process using the RISOS taxonomy, the buffer overflow flaw is clearlya type 1 flaw, as the problem is not checking parameters, allowing the buffer to overflow. However,with respect to the finger process, the flaw is of type 6, because the limit on input data to be sent canbe ignored (violated). And from the operating system’s point of view, the flaw is a type 5 flaw,because the user is allowed to write directly to what should be in the process’ space (the returnaddress), and execute what should be treated as data only.
Moving still higher, the storage space of the return address is a variable or an object. From theoperating system point of view, this makes the flaw be type 4, because a parameter – specifically, thereturn address – changes unexpectedly. From the fingerd point of view, though, the more abstractissue is the execution of data (the input); this is improper validation, specifically not validating thetype of the instructions being executed. So the flaw is a type 5 flaw.
At the highest level, this is again a type 5 flaw, because the system is changing a security-relatedvalue in memory, and is executing data that should not be executable. Again, due to the nature ofthe protection model of the UNIX operating system, this would not be a valid characterization at theimplementation level.
Finally, under Aslam’s taxonomy, the flaw is in class 3a5 from the point of view of the attackingprogram (boundary condition error, as the limit on input data can be ignored), in class 3a5 from thepoint of view of the xterm program (boundary condition error, as the process writes beyond a validaddress boundary), and class 2 from the point of view of the operating system (environment fault,as the error occurs when the program is executed on a specific machine, specifically a stack-basedmachine). As an aside, absent the explicit decision procedure, the flaw could also have been placedin class 3a4, access rights validation error, as the code executed in the input buffer should be data
only; and the return address is outside the process’ protection domain, yet is altered by it. So again,this taxonomy satisfies the decision procedure criteria, but not the uniqueness one.
The RISOS classifications are somewhat more consistent among the levels of abstraction, since theimproper authorization classification runs through the layers of abstraction. However, point of viewplays a role here, as that classification applies to the operating system’s point of view at two levels,and to the process view between them. This, again, vitiates the usefulness of the classificationscheme for our purposes.
4.4. Summary of Problems with Previous Work
The flaw classification is not consistent among different levels of abstraction. Ideally, the flawshould be classified the same at all levels (possibly with more refinement at lower levels). Thisproblem is ameliorated somewhat by the overlap of the flaw classifications, because as one refinesthe flaws, the flaws may shift class. But the classes themselves should be distinct; they are not,leading to this problem.
The point of view is also a problem. The point of view should not affect the class into which theflaw falls; but as the examples show, it clearly does. So, can we use this as a tool for classification –that is, classify flaws based on the triple of the classes that they fall under? The problem is theclasses are not partitions; they overlap, and so it is often not clear which class should be used for acomponent of the triple.
In short, the two examples demonstrate why the PA, RISOS, and Aslam classifications do not meetour need for taxonomies: they meet neither the uniqueness nor the well-defined decision procedurerequirement.
3. Relationship of Vulnerabilities to Specifications
A formal top-level specification (or FTLS) is a mathematical description of a computer system. Itstates specific conditions that the system design and implementation must meet. Ideally, thesespecifications are shown to be consistent with (a mathematical statement of) the security policy thatthe system is to enforce. Systems such as PSOS, KSOS, and Gemini adopted this approach. TheDoD Trusted Computer System Evaluation Criteria requires a formal design proved to conform to aFTLS.
Assuming the proofs are correct, the security of such systems breaks down at the level of codeverification. Proving that the implementation of the system is correct and conforms to the design(implying, at least by transitivity, that the implementation correctly conforms to the FTLS) isbeyond our current capabilities. Were it not, the most straightforward approach would be to expressthe constraints of the FTLS as mathematical invariants, and verify mathematically that theimplementation did not invalidate the invariants at any time.
An informal version of this last step uses formal testing. Property-based testing checks to see that aprogram does not violate a given set of specifications [10-12]. What follows is akin to this process,but assumes that specifications are not initially available.
4. Vulnerability Analysis
Given that existing systems do not have FTLS, the above is an exercise in verifying systems with aproveably secure design. Very few systems meet this criteria. This section discusses thegeneralization of the technique to the much larger class of systems that are not proveably secure, orideed even secure.
We should note that a general procedure to locate all vulnerabilities in arbitrary systems is anundecidable problem, by Rice’s Theorem. So, we must focus on specific system details.
4.1. Informal approaches
The FTLS describes the security constraints of the system. Systems without a FTLS have a securitypolicy, which may either be formal (written and specific) or informal (unwritten or ambiguous). Ineither case, certain rules emerge from the policy as security constraints. For example:• A user must be authenticated to a new identity before changing to that identity.• Data entered into a buffer may not be written beyond the end of the buffer.• The user bishop may alter passwords of other users as well as her own.
The first two are part of an implicit security policy, because they are general to many sites. The thirdis an example of a site-specific policy rule that identifies a single user as special.
System vulnerabilities violate some set of these rules. In the formal methods, we mathematicallydetermine what these rules are (from the FTLS) and determine formally if a program violates them.In this informal method, we determine what these rules are from the (explicit or implicit) securitypolicy and determine experimentally if a program violates them. Unfortunately, many aspects of thesystem’s requirements are implicit, such as the first two of the above three rules.
Our procedure is to identify the implicit and explicit rules that make up a system security policy.From this, we can derive a set of characteristics that identify properties of non-secure programs —specifically, vulnerabilities. We include conditions needed for these properties to result in a securitybreach.
An alternate view is that vulnerabilities arise as a combination of specific conditions of theenvironment and specific properties of the program. That is, characteristics can be deduced from thevulnerabilities themselves.This is akin to deducing the security policy of a system from an oraclethat states whether actions are “secure” or “non-secure.” It is however far more realistic than anattempt to deduce the implicit security policy from the way a system works. Most people will agreeon what violates security. But they will disagree on whether an abstract statement of “secure,” or alist of requirements for something to be considered “secure,” is correct.
Definition: A characteristic of a vulnerability is a condition that must hold for the vulnerability toexist.
We represent each vulnerability by its set of characteristics, called the characteristic set. Weclassify vulnerabilities by the characteristics in their sets. This meets our first criterion, becausesimilar vulnerabilities will be classified similarly due to the characteristics under consideration beingin both their characteristic sets. It also meets our fifth criterion, as a single vulmerability may fallinto multiple classes. The remaining criteria require a definition of the specific characteristics.
Definition: A set of characteristics is sound if the characteristics are independent; that is, given anysubset of the set of characteristics, none of the elements in the complement can be derived from thesubset.
For our purposes, we require that a characteristic set be sound. This simplifies classification andlead to minimal-sized characteristic sets.
Definition: A set of characteristics C is complete with respect to a system CS if the characteristicsets of all vulnerabilities of a system CS are composed of elements of C.
Finally, the characteristic set associated with the vulnerability that contains as few characteristics aspossible is minimal.
Hypothesis. Every vulnerability has a unique, sound characteristic set of minimal size.Call this set the basic characteristic set of the vulnerability.
4.2. Prevention of vulnerabilities, exploiting vulnerabilities
Let CS be a system with some set of vulnerabilites V = { v1, …, vn }. Let C = { c1, …, ck } be acomplete set of characteristics with respect to CS. Thus, each vulnerabilitiy vi’s characteristic set is aselection from the elements of C.
Let two vulnerabilities va and vb have basic characteristic sets C(va) and C(vb), respectively. If C(va)∩ C(vb) ≠ ∅, both vulnerabilities have a common characteristic. As they are elements of basiccharacteristic sets, if this property fails to hold, vulnerabilities va and vb will both be unexploitablebecause the conditions to exploit them do not exist.
Determining the similarity of vulnerabilities now becomes an exercise in set intersection. Considertwo vulnerabilities, and define distance as follows:
Definition: Two vulnerabilities va and vb are n units apart if | C(va) ∩ C(vb) | = n.
This suggests a procedure to locate vulnerabilities: look for characteristics. When detected, thecondition described by the characteristic must be negated. Then not only the single vulnerabilityunder consideration, but all vulnerabilities with the same characteristic, are non-exploitable.We expand on this approach in the next section. First, we review our hypothesis and what we wantto show.4.3. Hypotheses
The hypotheses we wish to test are as follows:
• We can determine the basic characteristic set for any vulnerability.
This will give us a set of characteristic conditions that cause the vulnerability to be exploitable.
• We can determine a set of characteristics for a set of vulnerabilities
f we can, then we can generate characteristics by examining known vulnerabilities for a system.I
We can then use these characteristics to examine the system for more vulnerabilities, andproceed iteratively.
• The size of a complete set of characteristics for a system is smaller than the set of
vulnerabilities.Intuition suggests that this is obvious, as the set of vulnerabilities is similar to the power set ofthe set of characteristics. However, not every combination of characteristics creates avulnerability. Does this mean that a very few characteristics create a large number ofvulnerabilities? Further, by defining characteristics appropriately, we may create a template for alarge set of characteristics; an example of this will be given in the next section. In this case,analysis of a system for any characteristic matching the template may uncover many differentinstances of the template characteristic.
• Each characteristic suggests a tool to analyze the system or system programs to determine if the
condition exists.
If true, the implication is that a set of tools can be designed to look for, and close, vulnerabilities,even before thoise vulnerabilities are known to exist! This hypothesis suggests that thecharacteristics must be quite detailed (to enable automated or manual search).
5.Using the Hypothesis
Assuming our hypotheses are correct, we can use the analysis to eliminate vulnerabilities. Wesimply look for situations in which the characteristic conditions hold, and negate them. Somereflections on this follow.
Consider the issue of level of abstraction. One low-level characteristic might be “the PATHvariable is not reset when spawning a subcommand.” This can be checked easily and automatically.At a slightly higher level, the characteristic might read “the environment in which the subcommandwill execute is not reset to a safe value before spawning the subcommand.” This is broader, yet alsosusceptible to mechanical checking. At an even higher level, “The protection domain of asubprocess is not properly initialized” is a design flaw, yet clearly suibsumes the previous two.Thus, levels of abstraction are absorbed into the characteristics. (The next section contains moreexamples of this.) The characteristics are inclusive of lower-level characteristics, so there is a clearcontainment relationship. We hypothesize this relationship holds for complete sets ofcharacteristics at different levels of abstraction. If so, this solves the first problem with the previousclassification schemes.
Point of view is a bit trickier. Currently, we believe it must be an attribute of the characteristic. Inessence, every vulnerability will then have 3 different characteristic sets, one for each of the threepoints of view. However, this area clearly needs more study.
6. Examples
In what follows, we present three vulnerabilities and discuss their breakdown. Throughout, weassume a UNIX system environment.6.1. Data and Stack Buffer Overflows
The fingerd attack discussed earlier is an example of this. The breakdown is as follows:C1.Failure to check bounds when copying data into a buffer.C2.C3.C4.C1’.C2’.C3’.C4’.
Failure to prevent the user from altering the return address.
Failure to check that the input data was of the correct form (user name or network address).Failure to check the type of the words being executed (data loaded, not instructions).If the attacker cannot overflow the bounds, the control flow will continue in the text(instruction) space and not shift to the loaded data.
If the return address cannot be altered, then even if the input overflows the bounds, thecontrol flow will resume at the correct place.
As neither a user name nor a network address is a valid sequence of machine instructions onmost UNIX systems, this would cause a program crash and not a security breach.
If the system cannot execute data, the return into the stack will cause a fault. (Some vendorehave implemented this negation, so data on the stack cannot be executed. However, data inthe heap can be, leaving them vulnerable to attack.)
Invalidating any of these conditions prevents an attacker from exploiting this vulnerability:
The sensitivity of characteristics to hosts is clear from C3 and C4. On some systems, ASCII textwould be valid instructions; on these systems, condition C3 always holds. Thus, conditions C1, C2,and C4 would be relevant. On some systems, C4 is negated, so an attack like fingerd would notsucceed. But some vendoirs approximate the negation of C4 by determining type from the locationof the words in memory. Words on the stack are data and may not be executed. Words elsewheremay be instructions and so can be executed. If the words are data words not in the stack, then C4holds.
Race conditions involving UNIX file accesses
The program xterm is a program that emulates a terminal under the X11 window system. Forreasons not relevant to this discussion, it must run as the omnipotent user root on UNIX systems. Itenables the user to log all input and output to a file. If the file does not exist, xterm creates the logfile and makes it owned by the user; if the file already exists, xterm checks that the user can write toit before opening the file. As any root process can write to any file on the system, the extra check isnecessary to prevent a user from having xterm append log output to (say) the system password file,and gain privileges by altering that file.
Suppose the user wishes to log to an existing file. The following code fragment opens the file forwriting:
if (access(“/usr/tom/X”, W_OK) == 0){
fd = open(“/usr/tom/X”, O_WRONLY|O_APPEND);
/etcpasswdpasswd data
usrXtom
etcpasswdpasswd data/
usrXtom
X dataX dataaccess(“/usr/tom/X”, W_OK)Figure 1a.
open(“/usr/tom/X”, O_WRITE)Figure 1b.
The semantics of the UNIX operating system cause the name of the file to be loosely bound to thedata object it represents, and the binding is asserted each time the name is used. If the data objectcorresponding to /usr/tom/X changes after the access but before the open, the open will not open tothe file checked by access. So during that interval an attacker deletes the file and links a system file(such as the password file) to the name of the deleted file. Then xterm appends logging output tothe password file. At this point, the user can create a root account without a password and gain rootprivileges.
The race condition has the following conditions:C1.Within the process must be an interval between the checking of a condition based upon a
file name and an opening of that file using the file name and based on the file satisfying thecondition.
C2.An attacker can alter the binding of the file object to the name.Characteristic C1 is very specific to file accesses. A more general version of this characteristic is todelimit the “window” of opportunity by any check on the file’s attributes and by any action takenupon the file and based upon the prior check. However, generalizing C2 requires looking at generalobjects, not just file objects, or altering bindings to properties in addition to names. The specificityof C1, and its less specific version, demonstrate the levels of abstraction.
As with buffer overflows, the race condition is not exploitable if either characteristic does not hold.See Bishop and Dilger’s paper [13] for a detailed discussion of race conditions arising from fileaccesses.
6.3. Internet address spoofing
Initiating a TCP connection has three steps, as illustrated [14]. Host A sends a SYN to host B; theSYN contains a sequence number X. Host B responds with SYN/ACK, supplying its own sequencenumber Y and incrementing A’s sequence number. Host A ends the handshake with an ACKcontaining the sequence number Y+1. IP spoofing refers to a host N sending B the TCP initiationsequence packets, but with A’s IP address as source address. B must ensure that A ignores, ornever receives, the second message for if A does receive it, A will send an RST packet and theconnection will be reset.
The characteristics of this attack are:C1.C2.
The sequence number from the victim is predictable.
The victim will never receive a reply packet from the purported peer.
Given these characteristics, the host N can impersonate the purported peer A. B’s SYN/ACK willnever be received, and N can predict what Y will be. Hence B will think it is communicating with A.If C1 is false, then N can prevent A from receiving traffic from B, but N will simply have to guesswhat Y is. If C2 is false, then the first reply packet that B receives from A will interrupt theconnection and cause a state transition that will terminate the (one-way) connection between N andB.
Note that C2 is quite general. In the best known instance of this attack [15], the attacker flooded theports of the purported peer to prevent it from receiving the SYN/ACK packet from the victim. As anillustration of point of view, from the point of view of the purported victim, the vulnerability is:C3.Too many incoming messages can block access to all ports for some finite time interval.However, from the attacker’s point of view, this is subsumed in C2.
6.4. Summary
These three examples demonstrate the characteristics of three well-known vulnerabilities. These alsodemonstrate aspects of the characteristics and of techniques that can derive from them. We nowconsider how to implement tools based upon these mechanisms.
7.Tool Development
Central to any classification scheme is to what use it will be put. Our goal was to develop aclassification scheme that could lead to tool development. Given the analysis leading to thecharacteristics composing the vulnerabilities, one need only build tools to look for thecharacteristics.
In this aspect the layers of abstraction become relevant. If the tools are to be automated, and runwith little guidance, then the characteristics must be very precise and well-defined. If the tools are tobe run with much human intervention and analysis, the characteristics may be much broader. Forexample, the characteristic “An attacker can alter the binding of the file object to the name ‘ (§6.2,characteristic C2) is simple to check by a recursive scan of permissions of the UNIX file system;but the characteristic “Too many incoming messages can block access to all ports for some finitetime interval” (§6.3, C3) is more difficult. Although one can automate a check for finite resources,analyzing the time-out strategy is considerably more difficult.
8. Conclusions
The research questions of this discussion are:
• Does every vulnerability have a unique, sound characteristic set of minimal size?
• Does every system have a complete set of characteristics small enough to make scanning for
them, as opposed to vulnerabilities, advantageous (quicker, more effective, etc)?• How do we determine the basic characteristic set for any vulnerability?
The development questions are:
• How effective are tools that look for characteristics at locating previously unknown
vulnerabilities?• How general can we make the characteristics that the tools look for and still require minimal
human intervention?
9. References
1.
Abbott, R.P., et al., Security Analysis and Enhancements of Computer Operating Systems, .1976, Institute for Computer Sciences and Technology, National Bureau of Standards:Gaithersburg, MD.
Bisbey, R. and D. Hollingsworth, Protection Analysis Project Final Report, . 1978,Information Sciences Institute, University of Southern California: Marina Del Rey, CA.Landwehr, C.E., et al., A Taxonomy of Computer Program Security Flaws. ComputingSurveys, 1994. 26(3): p. 211-255.
Neumann, P.G. Computer System Security Evaluation. in National Computer Conference.1978.
Aslam, T., A Taxonomy of Security Faults in the UNIX Operating System, in Department ofComputer Sciences. 1995, Purdue University: West Lafayette, IN 47097.
Krsul, I., Software Vulnerability Analysis, in Department of Computer Sciences. 1998,Purdue University: West Lafayette, IN 47097. p. 171.
Seeley, D. A Tour of the Worm. in Winter USENIX Technical Conference. 1989: USENIXAssociation.
Djikstra, E., The Structure of the THE Multiprogramming System. Communications of theACM, 1968. 11(5): p. 341-346.
Neumann, P., et al., A Provably Secure Operating System, . 1975, Stanford ResearchInstitute: Menlo Park, CA 94025. p. 327.
Ko, C., G. Fink, and K. Levitt. Automated Detection of Vulnerabilities in PrivilegedPrograms by Execution Monitoring. in Tenth Annual Computer Security ApplicationsConference. 1994.
Fink, G. and K. Levitt. Property-Based Testing of Privileged Programs. in Tenth AnnualComputer Security Applications Conference. 1994.
Fink, G., Discovering Security and Safety Flaws Using Property Based Testing, inDepartment of Computer Science. 1996, University of California: Davis, CA 95616-8562.Bishop, M. and M. Dilger, Checking for Race Conditions in File Accesses. ComputingSystems, 1996. 9(2): p. 131-152.
2.3.4.5.6.7.8.9.10.
11.12.13.
14.
Heberlein, T. and M. Bishop. Attack Class: Address Spoofing. in Nineteenth NationalInformation Systems Security Conference. 1996. Baltimore, MD.
15.Shimomure, T. and J. Markoff, Takedown: The Pursuit and Capture of Kevin Mitnick,
America's Most Wanted Computer Outlaw--By the Man Who Did It. 1996, New York, NY:Warner Books.
因篇幅问题不能全部显示，请点此查看更多更全内容