Vulnerabilities Analysis
Research Goal
The objective of this project is to propose and test a new classification scheme for vulnerabilities based on the conditions that must exist for the vulnerability to be exploitable. (These conditions are called characteristics of the vulnerability.) The key is the statement of the characteristics. If the characteristics are defined in a manner that enables one to design a procedure, methodology, or tool to detect the presence of that characteristic, then one can determine whether all characteristics necessary for a particular vulnerability to arise are present.
The specific goal of the project is to validate several hypotheses. The key hypothesis is that the intersection of the sets of characteristics for multiple vulnerabilities is not empty, so two or more vulnerabilities may share a common characteristics. Assuming the statement of characteristics for each vulnerability is minimal, then ensuring the common characteristics does not hold eliminates both vulnerabilities.
Approach
To validate this hypothesis, the project proposes to examine multiple vulnerabilities in open-source systems (so that others can validate the work), develop a language to express the characteristics unambiguously, and either experimentally verify or provide counterexamples to:
• Every vulnerability has a unique, sound set of characteristics that is of minimal size;
• Vulnerabilities share characteristics; and
• For a large enough set of vulnerabilities, the number of characteristics is less than the number of vulnerabilities.
The intellectual merit of this activity lies in deepening our understanding of why vulnerabilities occur in systems, how to detect them, and how to prevent them. Currently, vulnerabilities in existing systems are found in a relatively ad hoc manner, in which analysts look for several generic classes of flaws (such as buffer overruns and race conditions). However, these methods and tools ignore the impact of the environment. For example, a “race condition” in a program is not exploitable if only trusted users can access the relevant file. A failure to check bounds during input will not lead to execution of uploaded code if the data being input cannot be executed. It could, however, lead to other attacks based on changing data. The proposed classification scheme would allow analysts to distinguish between these cases, and develop tools to find vulnerabilities based on their characteristics. The project also ties vulnerability analysis to formal methods, because the characteristics being discussed are the preconditions in the formal verification of systems and programs. The goal, in those terms, is to ensure that the postcondition (conformance to a stated security policy) holds after execution.
One other aspect of this work is its application to existing systems. Research on security traditionally accepts that systems are flawed, and tries to ameliorate those flaws through the use of wrappers, sandboxing, and other ways to isolate untrusted code. This project looks at the existing system to see how to strengthen it without adding additional layers.
The broader impacts resulting from this activity will be a way to eliminate previously unknown vulnerabilities by ensuring the characteristics they share do not hold. The vulnerability need not be known at the time. If this project is successful, vendors and analysts would be better able to test existing systems for vulnerabilities, ameliorating the crisis in the security of existing systems. Finally, the characteristics would provide a repository of programming practices and
maintenance and operation procedures that could cause problems, and students could use this to learn to avoid such problems.
Funding
This material is based upon work supported by the National Science Foundation under Grant No. 0311723.
Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation.
Contact person:
Matt Bishop
bishop@cs.ucdavis.edu
last modified 6/11/04