Security in computer systems is important so as to ensure reliable operation and to protect the integrity of stored information. Faults in the implementation of critical components can be exploited to breach security and penetrate a system. These faults must be identified, detected, and corrected to ensure reliability and safeguard against denial of service, unauthorized modification of data, or disclosure of information. We define a classification of security faults in the Unix operating system. We state the criteria used to categorize the faults and present examples of the different fault types. We present the design and implementation details of a prototype database to store vulnerability information collected from different sources. The data is organized according to our fault categories. The information in the database can be applied in static audit analysis of systems, intrusion detection, and fault detection. We also identify and describe software testing methods that should be effective in detecting different faults in our classification scheme.

Abstract not found

ix 0.1 An Overview of Software Testing Methods # # # # # # # # # # # # # # # 2 0.2 Provable Security and Formal Methods # # # # # # # # # # # # # # # # # 9 0.3 Security Testing # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # 10 0.4 Applications of Fault Categories # # # # # # # # # # # # # # # # # # # # # 11 0.5 Organization of the Thesis # # # # # # # # # # # # # # # # # # # # # # # # 12 1. RELATED WORK # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # 14 1.1 Protection Analysis Project # # # # # # # # # # # # # # # # # # # # # # # 14 1.2 RISOS Project # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # 19 1.3 Flaw Hypothesis Methodology # # # # # # # # # # # # # # # # # # # # # # 21 1.4 Case Study# Penetration Analysis of the Michigan Terminal System # 23 1.5 Software Fault Studies # # # # # # # # # # # # # # # # # # # # # # # # # # 25 1.5.1 Fault Categories # # # # # # # # # # # # # # # # # # # # # # # # # # 27 1.6 Errors of T E X # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # 31 1.7 A Taxonomy of Computer Program Security Flaws # # # # # # # # # # 32 1.8 Comparison of Security Fault Classi#cation Schemes # # # # # # # # # # 33 2. A TAXONOMY OF SECURITY FAULTS IN THE UNIX OPERATING SYSTEM # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # 35 2.1 A Taxonomy of Security Faults # # # # # # # # # # # # # # # # # # # # # 36 2.2 Con#guration Errors # # # # # # # # # # # # # # # # # # # # # # # # # # # 40 2.2.1 Examples # # # # # # # # # # # # # # # # # # # # # # # # # # # # # 40 2.3 Synchronization Errors # # # # # # # # # # # # # # # # # # # # # # # # # # 41 2.3.1 Example # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # 41...

The majority of attacks made upon modern computers have been successful due to the exploitation of the same errors and weaknesses that have plagued computer systems for the last thirty years. Because the industry has not learned from these mistakes, new protocols and systems are not designed with the aspect of security in mind; and security that is present is typically added as an afterthought. What makes these systems so vulnerable is that the security design process is based upon assumptions that have been made in the past; assumptions which now have become obsolete or irrelevant. In addition, fundamental errors in the design and implementation of systems repeatedly occur, which lead to failures. This

Almost thirty years ago a vulnerability assessment of Multics identified significant vulnerabilities, despite the fact that Multics was more secure than other contemporary (and current) computer systems. Considerably more important than any of the individual design and implementation flaws was the demonstration of subversion of the protection mechanism using malicious software (e.g., trap doors and Trojan horses). A series of enhancements were suggested that enabled Multics to serve in a relatively benign environment. These included addition of “Mandatory Access Controls ” and these enhancements were greatly enabled by the fact the Multics was designed from the start for security. However, the bottom-line conclusion was that “restructuring is essential ” around a verifiable “security kernel ” before using Multics (or any other system) in an open environment (as in today’s Internet) with the existence of well-motivated professional attackers employing subversion. The lessons learned from the vulnerability assessment are highly applicable today as governments and industry strive (unsuccessfully) to “secure ” today’s weaker operating systems through add-ons, “hardening”, and intrusion detection schemes. 1

project, which is producing an openly distributed worked example of how high assurance trusted computing components can be built. The TCX project encompasses four related activities: Creation of a prototype framework for rapid high assurance system development; Development of a reference-implementation trusted computing component; Evaluation of the component for high assurance; and Open dissemination of results related to the first three activities. The project’s open development methodology will provide widespread availability of key high assurance enabling technologies and ensure transfer of knowledge and capabilities for trusted computing to the next generation of developers, evaluators and educators. I.

As adversaries develop Information Warfare capabilities, the threat of information system subversion presents a significant risk. System subversion will be defined and characterized as a warfare tool. Through recent security incidents, it is shown that means, motive, and opportunity exist for subversion, that this threat is real, and that it represents a significant vulnerability. Mitigation of the subversion threat touches the most fundamental aspect of the security problem: proving the absence of a malicious artifice. A constructive system engineering technique to mitigate the subversion threat is identified. Keywords: Subversion, Secure Systems, Assurance

Approved for public release; distribution is unlimited

This thesis was completed in cooperation with the Institute for Information Superiority and Innovation. Approved for public release; distribution is unlimitedTHIS PAGE INTENTIONALLY LEFT BLANKREPORT DOCUMENTATION PAGE Form Approved OMB No. 0704-0188 Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instruction, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden, to Washington