Towards a "Periodic Table" of Bugs

Abstract:

High-confidence systems must not be vulnerable to attacks that impact the security, reliability, or availability of the system as a whole. That is, they must have no software weaknesses (bugs) that could result in a vulnerability. A vulnerability is "a weakness in system security requirements, design, implementation, or operation that could be accidentally triggered or intentionally exploited and result in a security failure." [1] The Common Weakness Enumeration (CWE) [2] is a collection of known software weakness types described in plain English with demonstrative examples, relations to other CWEs, and some formal definitions. It is a considerable community effort, but many of the descriptions are inaccurate, incomplete, inconsistent, or ambiguous. We discuss our vision of precisely defining software bugs: wholesale restructuring of CWEs, incorporating Software Fault Patterns (SFPs) and Semantic Templates, and formalizing them. This will enable automatic generation of software testing components and tools, software analysis tools that always find these weaknesses, formal proofs of systems properties, assuring absence of particular vulnerabilities, and mitigating vulnerabilities by filtering out exploiting attacks. Accurate and precise definitions of software weaknesses, along with their causes and consequences, are essential for constructing formal proofs of presence or absence of such weaknesses in a program.

We picked three CWEs that we thought would be representative and would help expose the inherent opportunities and challenges: CWE-307 Improper Restriction of Excessive Authentication Attempts; CWE-119 Improper Restriction of Operations within the Bounds of a Memory Buffer, and CWE-78 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection'). The three selected CWEs are quite different from each other in aspects from source code footprints to ways of exploitation.

We propose new definitions for these three. Our definitions are substantially more precise and accurate than the current CWE descriptions. For instance, the current description summary of CWE-307 includes failure to prevent "multiple failed authentication attempts within a short time frame". However, that description does not provide precise meanings for "multiple" and "short". Our new definition recognizes that CWE-307 actually represents a set of weaknesses, each of which satisfies particular institution-specific definitions of "multiple" and "short". Next, the description summary of CWE-119 is "The software performs operations on a memory buffer, but it can read from or write to a memory location that is outside the intended boundary of the buffer". However, "read from or write to a memory location" is not tied to the buffer. Our definition clarifies that access is through the same buffer to which the intended boundary pertains. Our definition also accurately, precisely, and concisely describes violation of memory safety. Finally, the description summary of CWE-78 is based on the software "using externally influenced input", and incorrectly neutralizing "special elements that could modify the intended OS command". "Using input", "intended command", and "correctly neutralizing" are imprecise. We precisely define "using input" and "intended command". We do not include "correctly neutralizing", because it simply means that intended OS command cannot be modified.

We also explain some of our work toward formalizing definitions [3] and restructuring and unifying CWEs, SFPs, and Semantic Templates, including causes and consequences.

[1] Stoneburner, G. et al., "Engineering Principles for Information Systems Security (A Baseline for Achieving Security)", Revision A, NIST Special Publication 800-27 Rev A, June 2004.

[2] The MITRE Corporation, CWE, Common Weakness Enumeration, http://cwe.mitre.org/

[3] Wu, Y., Bojanova, I., Yesha, Y., "Reconstruction of Common Weakness Enumeration", IEEE Software Technology Conference (STC), 2014.

Biography:

Dr. Black has nearly 20 years of industrial experience in areas such as developing software for IC design and verification, assuring software quality, and managing business data processing. He is now a Computer Scientist for the National Institute of Standards and Technology (NIST) in the Systems and Software Division of the Information Technology Laboratory. He leads the Software Quality Group.

Dr. Black earned a B.S. in Physics and Mathematics in 1973 and a Ph.D. at Brigham Young University in 1998. Black has organized several workshops dealing with static analysis and has published in the areas of static analysis, software testing, software configuration control, networks and queuing analysis, formal methods, software verification, quantum computing, and computer forensics. He is a member of ACM, IEEE, and the IEEE Computer Society