NIST SP 800-231: Bug Framework (BF): Formalizing Cybersecurity Weaknesses and Vulnerabilities

NIST Special Publicaton 800 NIST SP 800-231

Bugs Framework (BF) Formalizing Cybersecurity Weaknesses and Vulnerabilites

Irena Bojanova

This publicaton is available free of charge from: htps://doi.org/10.6028/NIST.SP.800-231

NIST Special Publicaton 800 NIST SP 800-231

Bugs Framework (BF) Formalizing Cybersecurity Weaknesses and Vulnerabilites

Irena Bojanova Sofware and Systems Division Informaton Technology Laboratory

This publicaton is available free of charge from: htps://doi.org/10.6028/NIST.SP.800-231

July 2024

U.S. Department of Commerce Gina M. Raimondo, Secretary Natonal Insttute of Standards and Technology Laurie E. Locascio, NIST Director and Under Secretary of Commerce for Standards and Technology

Certain equipment, instruments, sofware, or materials, commercial or non-commercial, are identfied in this paper in order to specify the experimental procedure adequately. Such identficaton does not imply recommendaton or endorsement of any product or service by NIST, nor does it imply that the materials or equipment identfied are necessarily the best available for the purpose. There may be references in this publicaton to other publicatons currently under development by NIST in accordance with its assigned statutory responsibilites. The informaton in this publicaton, including concepts and methodologies, may be used by federal agencies even before the completon of such companion publicatons. Thus, untl each publicaton is completed, current requirements, guidelines, and procedures, where they exist, remain operatve. For planning and transiton purposes, federal agencies may wish to closely follow the development of these new publicatons by NIST. Organizatons are encouraged to review all draf publicatons during public comment periods and provide feedback to NIST. Many NIST cybersecurity publicatons, other than the ones noted above, are available at htps://csrc.nist.gov/publicatons. Authority This publicaton has been developed by NIST in accordance with its statutory responsibilites under the Federal Informaton Security Modernizaton Act (FISMA) of 2014, 44 U.S.C. § 3551 et seq., Public Law (P.L.) 113-283. NIST is responsible for developing informaton security standards and guidelines, including minimum requirements for federal informaton systems, but such standards and guidelines shall not apply to natonal security systems without the express approval of appropriate federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130. Nothing in this publicaton should be taken to contradict the standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce under statutory authority. Nor should these guidelines be interpreted as altering or superseding the existng authorites of the Secretary of Commerce, Director of the OMB, or any other federal official. This publicaton may be used by nongovernmental organizatons on a voluntary basis and is not subject to copyright in the United States. Atributon would, however, be appreciated by NIST. NIST Technical Series Policies Copyright, Use, and Licensing Statements NIST Technical Series Publicaton Identfier Syntax Publicaton History Approved by the NIST Editorial Review Board on 2024-05-16 How to cite this NIST Technical Series Publicaton: Bojanova I (2024) Bugs Framework (BF): Formalizing Cybersecurity Weaknesses and Vulnerabilites. (Natonal Insttute of Standards and Technology, Gaithersburg, MD), NIST Special Publicaton (SP), NIST SP 800-231. htps://doi.org/10.6028/NIST.SP.800-231 NIST Author ORCID iD 0000-0002-3198-7026 Contact Informaton bf@nist.gov

NIST SP 800-231 July 2024

Abstract The Bugs Framework (BF) is a classificaton of security bugs and related faults that features a formal language for the unambiguous specificaton of sofware and hardware security weaknesses and vulnerabilites. BF bugs models, multdimensional weakness and failure taxonomies, and vulnerability models define the lexis, syntax, and semantcs of the BF formal language and form the basis for the definiton of secure coding principles. The BF formalism supports a deeper understanding of vulnerabilites as chains of weaknesses that adhere to strict causaton, propagaton, and compositon rules. It enables the generaton of comprehensively labeled weakness and vulnerability datasets and multdimensional vulnerability classificatons. It also enables the development of new algorithms for code analysis and the use of AI models and formal methods to identfy bugs and detect, analyze, prioritze, and resolve or mitgate vulnerabilites. Keywords bug classificaton; bug identficaton; sofware/hardware weakness taxonomy; vulnerability detecton; safe coding; formal language; specificaton generaton; weakness dataset; vulnerability dataset; vulnerability classificaton; sofware bug; firmware bug; hardware defect; hardware logic bug; bug triaging; sofware error; sofware fault; sofware weakness; hardware weakness; sofware vulnerability; hardware vulnerability; exploit; security failure; secure coding; vulnerability resoluton; vulnerability mitgaton; labeled dataset; generaton tool; graph generaton; AI models; formal methods; CVE; CWE; NVD; KEV. Reports on Computer Systems Technology The Informaton Technology Laboratory (ITL) at the Natonal Insttute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the Naton’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementatons, and technical analyses to advance the development and productve use of informaton technology. ITL’s responsibilites include the development of management, administratve, technical, and physical standards and guidelines for the cost-effectve security and privacy of other than natonal security-related informaton in federal informaton systems. The Special Publicaton 800series reports on ITL’s research, guidelines, and outreach efforts in informaton system security, and its collaboratve actvites with industry, government, and academic organizatons. Audience The intended audience includes security researchers, sofware and hardware developers, informaton technology (IT) managers, and IT executves. i

NIST SP 800-231 July 2024

Table of Contents 1. Introducton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

2. Current State of the Art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

3. Bugs Framework Formalism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

3.1.

BF Operaton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

3.2. BF Bug, Fault, and Weakness . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

3.3. BF Vulnerability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

3.4. BF Bug Identficaton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

4. BF Security Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

5. BF Bugs Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

5.1.

BF Input/Output Check ( INP) Bugs Model . . . . . . . . . . . . . . . . . . .

16

5.2. BF Memory ( MEM) Bugs Model . . . . . . . . . . . . . . . . . . . . . . . . .

17

5.3. BF Data Type ( DAT) Bugs Model . . . . . . . . . . . . . . . . . . . . . . . . .

18

6. BF Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.1. BF Weakness Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.2. BF Failure Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

6.3. BF Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

7. BF Vulnerability Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

7.1.

BF Vulnerability State Model . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

7.2. BF Vulnerability Specificaton Model . . . . . . . . . . . . . . . . . . . . . . .

35

8. BF Formal Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39

8.1. BF Lexis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 8.2. BF Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

8.3. BF Semantcs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 9. BF Secure Coding Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.1.

Input/Output Check Safety . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47 47

9.2. Memory Safety . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 9.3. Data Type Safety . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 10. BF Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52

10.1. BFCWE Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52

10.2. BFCVE Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53

ii

10.3. BF GUI Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

55

11. BF Datasets and Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

59

11.1. BFCWE Dataset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

59

11.2. BFCVE Dataset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 11.3. BF Vulnerability Classificatons . . . . . . . . . . . . . . . . . . . . . . . . . .

63

11.4. BF Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

65

12. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

67

List of Figures Fig. 1. Fig. 2. Fig. 3. Fig. 4. Fig. 5. Fig. 6. Fig. 7. Fig. 8. Fig. 9. Fig. 10. Fig. 11. Fig. 12. Fig. 13. Fig. 14. Fig. 15. Fig. 16. Fig. 17. Fig. 18. Fig. 19. Fig. 20. Fig. 21. Fig. 22. Fig. 23. Fig. 24. Fig. 25. Fig. 26. Fig. 27. Fig. 28. Fig. 29. Fig. 30.

7 BF operaton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BF security weakness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 BF weakness states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 BF security vulnerability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 BF BadAlloc patern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 BF backward bug identficaton . . . . . . . . . . . . . . . . . . . . . . . . . . 13 BF security concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 BF Input/Output Check ( INP) Bugs Model . . . . . . . . . . . . . . . . . . . 16 BF Memory ( MEM) Bugs Model . . . . . . . . . . . . . . . . . . . . . . . . . 17 BF Data Type ( DAT) Bugs Model . . . . . . . . . . . . . . . . . . . . . . . . . 19 BF Data Validaton (DVL) class . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 BF Memory Use (MUS) class . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 BF Type Conversion (TCV) class . . . . . . . . . . . . . . . . . . . . . . . . . . 23 BF taxonomy in XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 BF class methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 BF Vulnerability State model . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 BF states of Heartbleed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 C code of heartbeat() and naive memcpy() . . . . . . . . . . . . . . . . . 33 Heartbleed fix in Heartbeat . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 BF Vulnerability Specificaton Model . . . . . . . . . . . . . . . . . . . . . . . 36 BF specificaton of Heartbleed . . . . . . . . . . . . . . . . . . . . . . . . . . 37 BF secure coding principles methodology . . . . . . . . . . . . . . . . . . . . 51 BF specificatons of CWE-125 . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Generated BF weakness chains for Heartbleed . . . . . . . . . . . . . . . . . 55 BF GUI tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 BF Heartbleed in XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 CWEs by BF class types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 CVEs by BF class types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 NVD-GitHub-BF query for MEM CVEs . . . . . . . . . . . . . . . . . . . . . . 62 BF Vulnerability Classificaton Model . . . . . . . . . . . . . . . . . . . . . . . 64 iii

NIST SP 800-231 July 2024

1. Introducton The Bugs Framework (BF) [1] is a classificaton of security bugs and related faults with multdimensional weakness and failure taxonomies that features a formal language for the unambiguous specificaton of security weaknesses and vulnerabilites. The goal of BF is to help beter understand and detect sofware, firmware, or hardware security weaknesses and vulnerabilites, as well as to resolve or mitgate them. Both cybersecurity experts and automated systems need precise descriptons of the publicly disclosed vulnerabilites and the weakness types related to them. Automated analysis via formal methods requires formal definitons of the weakness and vulnerability concepts. The automated analysis via artficial intelligence (AI) models requires comprehensively labeled weakness and vulnerability datasets. The BF organizes bugs by the operatons of orthogonal sofware, firmware, or hardware executon phases; faults by their input operands; and errors by their output results. An error either propagates to a fault or is final and enables a security failure. Bugs and faults are causes of security weaknesses, and errors and final errors are their consequences. A bug is a code or specificaton defect. A fault is a name, data, type, address, or size error. A BF weakness class is a taxonomic category of a weakness type that relates to a distnct executon phase defined by a set of operatons and their input operands and output results. It defines finite sets of ⟨cause, operaton⟩→consequence causal relatons, operaton and operand atributes, and code sites. Causes are bugs or faults, and consequences are errors or final errors. A weakness is an instance of a BF class with one cause, one operaton, and one consequence that is expressed as a ⟨bug, operaton⟩→error, ⟨fault, operaton⟩→error, ⟨bug, operaton⟩→final error, or ⟨fault, operaton⟩→final error triple and specific operaton and operand atributes and sites. A vulnerability is a chain of weaknesses linked by causality via a consequence↷cause propagaton that eventually enables a security failure. It starts with a bug or hardware-induced fault, propagates through errors that become faults, and ends with a final error that introduces an exploit vector toward a failure. The first weakness relates to the root cause of the vulnerability, and the last relates to its sink. BF bugs models, weakness and failure taxonomies, and vulnerability models define the BF formal language lexis, syntax, and causal semantcs. The BF bugs models define the sets of operatons for related executon phases and the proper flow between these operatons. The BF weakness taxonomies comprise structured, orthogonal, multdimensional, and context-free BF weakness classes. The BF failure taxonomy comprises corresponding BF failure classes. The BF vulnerability models define state and specificaton views of a vulnerability, possibly converged and chained with other vulnerabilites. The BF formal language is generated by the BF lef-to-right lefmost derivaton one-symbol lookahead (LL(1)) atribute context-free grammar (ACFG) based on the BF taxonomies and models. 1

NIST SP 800-231 July 2024

Analogous to the periodic table, the BF weakness taxonomies allow for the identification or prediction of as yet unencountered security weakness types, which would allow for the prediction of new kinds of vulnerabilities. The BF taxonomies and models also form the basis for defining secure coding principles, such as input/output check safety (e.g., injection safety), memory safety (e.g., buffer overflow safety or use-after-free safety), and data type safety (e.g., floating point safety or subtype confusion safety). While the BF formal language is descriptive of weaknesses and vulnerabilities, the BF secure coding principles are prescriptive against them — they prevent bugs and faults that compromise code safety. The BF formalism supports a deeper understanding of vulnerabilities as chains of weaknesses that adhere to strict causation, propagation, and composition rules and allows for backward bug identification from a failure. It enables a new range of research and development efforts for the creation of comprehensively labeled weakness and vulnerability datasets and the generation of formal vulnerability specifications and multidimensional vulnerability classifications. The BF also supports the development of new static or dynamic analysis and simulation or emulation algorithms [2], as well as AI models and capabilities to identify bugs and detect vulnerabilities. Given the formal specification of code and the BF definitions of weakness and vulnerability, formal methods could also be applied to detect vulnerabilities. The next steps would be to prioritize and resolve or mitigate each of these vulnerabilities (i.e., fix the bug or a fault) to secure critical infrastructure and supply chains. The datasets of weakness and vulnerability BF specifications formally augment the Common Weakness Enumeration (CWE) [3], the Common Vulnerabilities and Exposures (CVE) [4], and the National Vulnerability Database (NVD) [5]. However, the BF has the expressive power to clearly describe any other security weaknesses and vulnerabilities. This NIST Special Publication (SP) provides a detailed overview of the Bugs Framework (BF) systematic approach and methodologies for classifying bugs and faults by orthogonal execution phases, formally specifying weaknesses and vulnerabilities, defining secure coding principles, generating comprehensively labeled weakness and vulnerability datasets and vulnerability classifications, and developing BF-based algorithms and systems. Further details will be available in the following forthcoming NIST SPs: • SP 800-231A, Bugs Framework: Security Concepts • SP 800-231B, Bugs Framework: Bugs Models • SPs 800-231Cx, Bugs Framework: yyy Taxonomy, where yyy is a BF class type • SP 800-231D, Bugs Framework: Vulnerability Models • SP 800-231E, Bugs Framework: Formal Language • SP 800-231F, Bugs Framework: Secure Coding Principles • SP 800-231G, Bugs Framework: Tools and APIs • SP 800-231H, Bugs Framework: Datasets and Classifications • SP 800-231I, Bugs Framework: Systems 2

NIST SP 800-231 July 2024

2. Current State of the Art The current state of the art in describing security weaknesses and vulnerabilites are the CWE [3] and CVE [4]. The current state of the art in labeling security weaknesses and vulnerabilites is the NVD [5], which assigns to a CVE the CWE weakness type that most closely matches the vulnerability. The Known Exploited Vulnerabilites (KEV) catalog [6] is also closely related to the CVE. The CWE and CVE are widely used. The CWE is a community-developed list of sofware and hardware weakness types. It was developed to address “the issue of categorizing sofware weaknesses” and establish “acceptable definitons and descriptons of these common weaknesses” and recently added ”support for hardware weaknesses” [7]. Each CWE entry is assigned a CWE-x ID (identfier), where x is one to four digits. It provides a weaknesstype descripton, an extended descripton, modes of introducton, possible mitgatons, detecton methods, and demonstratve examples. The CVE is a catalog of publicly disclosed security vulnerabilites. It was initated to address the problem of having “no common naming conventon and no common enumeraton of the vulnerabilites in disparate databases” [8, 9]. Each CVE entry is assigned a CVE-yyyyx ID, where yyyy is the year of disclosure and x is a unique sequental number. Each CVE entry provides a vulnerability descripton, references to reports, and possibly links to proof of concept and code.

The CWE and CVE adopted a one-dimensional list (i.e., enumeraton) approach to organizing the entries by unique IDs with natural language descriptons. The CWE added tree-based pillar, class, base, variant, and compound abstractons. Both repositories are regu-larly refined, and new weakness types, vulnerabilites, and related content are added [7]. The NVD maps CVE entries to CWE entries and assigns Common Vulnerability Scoring Sys-tem (CVSS) [10, 11] severity scores. The KEV catalog organizes publicly exploited CVEs pri-oritzed for remediaton, although they are not necessarily the most severe. However, the CWE hierarchical structure implies that the weakness types are interdepen-dent and may be too broad, not orthogonal, and ambiguous. Many of the CWE and CVE descriptons are not sufficient, accurate, or precise enough [12–15]; have unclear causal-ity [16–18]; and include programming language and domain-specific notons. The CWE has gaps and overlaps in coverage [16–18], and while some gaps are being identfied, new overlaps may be created [19]. Many CVEs do not describe the entre chain of weaknesses underlying the vulnerability. Some list the final error at the sink as the root cause instead of the bug or hardware-induced fault that starts the chain. Focusing on the final error helps identfy mitgaton techniques, but the actual root cause must be known and fixed to resolve the vulnerability. In the case of CVEs that overlap by root cause [20], fixing that one root cause would resolve all of them. These CWE and CVE challenges propagate to the NVD and KEV and may lead to imprecise or wrong CWE-to-CVE assignments by NVD. 3

NIST SP 800-231 July 2024

Additonally, the CWE and CVE do not exhibit strict methodologies for tracking the weaknesses underlying a vulnerability, systematc comprehensive vulnerability labeling, or backward root cause identficaton from a security failure. There are no tools to aid the creaton and visualizaton of weakness and vulnerability descriptons (see Table 1). Table 1. CWE, CVE, and NVD challenges Repository Challenges CWE CVE NVD

Imprecise Descriptons ✓ ✓ ✓

Unclear Causality ✓ ✓ ✓

Gaps

Overlaps

✓

✓ ✓ ✓

Wrong CWE Assignments

✓

No Tracking ✓ ✓ ✓

No Descripton Tools ✓ ✓ ✓

The imprecise descriptons and lack of explainability make CWEs and CVEs difficult to use in modern cybersecurity research [21]. For example, the descripton of CWE-502 mixes the notons of validaton (syntax check) and verificaton (semantcs check), for which BF defines two distnct weakness classes [16]. The descriptons of some CWEs reveal possible causing weaknesses and even chains of weaknesses, which could be helpful but may also imply that these are the only possible causing weaknesses. They also introduce terms that are unrelated to the main weakness and may mislead experts and automated analysis about the single weakness that the CWE is meant to describe. Augmentng the CWE and CVE natural language descriptons with unambiguous formal specificatons that adhere to within and between weaknesses causaton rules will make them more suitable for algorithms and as comprehensively labeled datasets for training AI models [22]. Unclear causality in CVEs leads to incorrect CWE assignments. For example, in the case of CVE-2018-5907, the lack of input validaton leads to integer overflow and then buffer overflow [16]. However, the NVD labels it with CWE-190: Integer Overflow or Wraparound, even though the root cause is CWE-20: Improper Input Validaton. The entre chain is CWE20→CWE-190→CWE-119, and the last one is “Improper Restricton of Operatons within the Bounds of a Memory Buffer.” CVE-2014-0160 Heartbleed [23] lists the final error at the sink — buffer over-read — as the root cause, while it is missing input verificaton that leads to pointer repositon over the upper bound and then to buffer over-read. For lack of a beter match, NVD assigns the broader CWE-125, which covers both under-lower-bound and over-upper-bound reads from a buffer. CVEs that have the same root cause are also difficult to identfy. For example, the CVE2016-7523 and CVE-2016-7524, CVE-2016-7518 and CVE-2017-6500, and CVE-2019-13295 and CVE-2019-13297 couples each have the same bug with the last couple patched in two versions of the product via two different commits [20]. As the chains are incomplete for many CVEs, there is no way to go backward from the failure to reveal the root cause. The BF addresses the challenges with the CWE and CVE descriptons via its orthogonal, multdimensional, and context-free classificaton structure. The BF weakness and vulnerability specificatons provide formal augmentaton to the CWE, CVE, and NVD entries. 4

NIST SP 800-231 July 2024

3. Bugs Framework Formalism The BF is a structured multdimensional classificaton of security bugs and related faults as causes for the operatons of distnct executon phases over their operands to result in errors and final errors as consequences. Its approach is different from the exhaustve IDbased list approach exhibited by enumeratons. The BF weakness classes are organized by orthogonal sets of operatons, so a BF class is identfiable by any of its operatons. They allow for the expression of a weakness as a ⟨cause, operaton⟩→consequence triple with operaton and operand atributes and a vulnerability as a chain of underlying weaknesses. A BF weakness class is a taxonomic representaton of a weakness type defined by finite sets of operatons, causes, consequences, atributes, and sites. It is associated with the operatons of a distnct phase of sofware, firmware, or hardware executon, where weaknesses of this type could happen, as well as their input operands and output results. A BF operaton is the minimal input-process-output code that can produce or propagate improper data. A cause is a bug in the operaton or a fault of an input operand. A consequence is an erroneous output result from the operaton over the operands. The error propagates to a fault or is a final error that enables a failure. Consequently, a BF operaton is the minimal input-process-output code that can produce an error from a bug or fault, where the error propagates to another fault or is final (i.e., it is a final error). The atributes describe the operatons and operands with details on what, how, and where it went wrong. They help understand the severity of the bug or fault causing the weakness. For example, pointer overbounds faults on the stack are more severe than those on the heap because buffer overflows on the stack, although easier to exploit, are more severe than those on the heap. The sites point to syntactc places in code that should be checked for bugs or faults that cause such weaknesses. The BF specificaton of a weakness is based on one taxonomic BF class; it is an instance of that BF class with one cause, one operaton, one consequence, and their atributes. The operaton binds the causaton within a weakness as a ⟨cause, operaton⟩→consequence relaton. For example, the deallocaton via a dangling pointer leading to a final error known as double free is a weakness that is expressed formally via BF as ⟨Dangling Pointer, Deallocate⟩→ Double Deallocate. The BF specificaton of a vulnerability is a chain of such instances and their consequence↷cause between weakness propagatons. The BF is a formal system that comprises: • Strict definitons of bug, fault, error, final error, weakness, vulnerability, exploit vector, and failure in the context of cybersecurity to elucidate causaton and propagaton rules • Bugs models that define distnct executon phases with orthogonal sets of operatons in which specific bugs and faults could occur and the proper flow of operatons

5

NIST SP 800-231 July 2024

• Structured, multdimensional, orthogonal, and context-free weakness taxonomies as weakness class types and a failure taxonomy as a failure class type • A vulnerability state model as a chain of improper-state (operaton, operand1 , . . . , operandn ) tuples with a bug in the operaton or a fault of an operand that enables a failure • A vulnerability specificaton model as a chain of ⟨cause, operaton⟩→consequence instances of BF weakness classes that ends with an instance of a BF failure class • A formal language for the unambiguous causal specificaton of security weaknesses and vulnerabilites • Secure coding principles, such as input/output check safety, memory safety, and data type safety • Tools that facilitate the generaton of CWE2BF and CVE2BF mappings and formal weakness and vulnerability specificatons and their graphical representatons • Comprehensively labeled weakness and vulnerability datasets • Multdimensional vulnerability classificatons by common propertes and similarites based on the BF taxonomies and secure coding principles The BF taxonomies are structured, orthogonal, multdimensional, and context-free. Structured means that a weakness is expressed as a ⟨cause, operaton⟩→consequence triple with a precise causal relaton. The transiton from a weakness is expressed as an error↷fault or final error↷exploit vector propagaton. These ensure clear causality within a weakness, between weaknesses, and for an exploit toward a failure. Orthogonal means that the intersecton of the sets of operatons of any two BF classes is the empty set. It ensures that the BF weakness types do not overlap in coverage. Multdimensional means that weaknesses are organized not only by their operatons but also by their causes, consequences, and operaton and operand atributes. It ensures the BF’s expressive power. Context-free means an operaton cannot have different meanings depending on the language or domain. It ensures that the BF is applicable for code in any programming language and for any platorm or applicaton technology. The BF formal language (see Sec. 8) is generated by the BF LL(1) ACFG, whose lexis, syntax, and semantcs reflect the BF weakness taxonomies and bugs and vulnerability models that utlize the strict BF concept definitons for security bug, final error, weakness, vulnerability, exploit vector, and failure as well as fault and error. The LL1 CFG is pivotal, as it ensures precise, unambiguous specificatons. The BF bugs models and weakness taxonomies are developed iteratvely according to the BF methodology (see Sec. 6.3) and alongside the BF, BFCWE, and BFCVE tools (see Sec. 10). 6

NIST SP 800-231 July 2024

The BF formalism guarantees precise descriptons with clear causality of weaknesses (including CWE) and vulnerabilites (including CVE) and complete, orthogonal, and contextfree weakness-type coverage. It forms the basis for the formal definiton of secure coding principles, such as memory safety. It also enables the creaton of comprehensively labeled weakness and vulnerability datasets, vulnerability classificatons, and BF-based systems for bug identficaton and vulnerability detecton, analysis, and resoluton or mitgaton. 3.1. BF Operaton A BF operaton is the minimal input-process-output code that can produce or propagate improper data (see Fig. 1). An input operand or output result data is of a specific data type. A data type defines a set or range of data values and the operatons allowed on them. It can be primitve (e.g., char, int, double, string, boolean) or structured (e.g., array, record, class). A data value is stored in a finite region of memory called an object. The boundaries of that memory define the size of the object. The address of the memory must be held by at least one pointer or determined as an offset on the stack. Otherwise, the object would be unreachable. Code (i.e., functons) and data type metadata are also stored in memory and can be referred to by pointers. A functon is an organized, reusable block of code that takes inputs and returns outputs of specific data types. BF Input Operands—Opera�on—Improper Output Model Input BF Operands

Process BF Opera�on

Output Improper Name, Data, Type, Address, Size

Memory Fault

objects, func�ons, type metadata BF, I. Bojanova

Fig. 1. BF operaton Consequently, the possible enttes stored in memory are objects, functons, and types. The possible BF input operands and output results are: name, data (i.e., the data value), type (i.e., the data type), address, and size. A BF operaton then is the minimal inputprocess-output code that can produce or propagate improper name, data, type, address, or size (see the purple terms in Fig. 1). BF operatons could be as simple as dereferencing or repositoning a pointer or as complex as encrypton or authentcaton involving sophistcated algorithms. Other examples include data verificaton, type coercion, and reading or deallocatng an object. Examples of improper output results and input operands are wrong value and wrap-around as data, insufficient size and cast pointer as type, dangling pointer and over-bounds pointer as address, and wrong resolved object and wrong generic functon bound as name. 7

NIST SP 800-231 July 2024

The output result of a BF operaton is always erroneous; for that, either the operaton or an input operand is improper. An operaton is improper if it has a bug, and an operand is improper if it is ill-formed (i.e., it is at fault). The erroneous output propagates to become the improper input of another BF operaton or eventually is final. Consequently, a BF operaton is the minimal input-process-output code that — because of a bug or fault — results in an error that propagates to another fault or is final (i.e., it is a final error). The fault is of a name, data, type, address, or size (see Fig. 1). 3.2. BF Bug, Fault, and Weakness The BF bugs and faults landscape covers the operatons in sofware, firmware, and hardware executon phases at appropriate levels of abstracton. The sofware operatons relate to code in applicatons, libraries, utlites, programming languages, services, and OSs. The firmware operatons relate to code in device drivers, basic input/output systems (BIOS), bootloaders, and microcontrollers, as well as to microcode in central processing units (CPU) and other hardware components that require low-level control and flexibility. The hardware operatons relate to electronic circuit logic, which adheres to the same input-processoutput model as sofware and firmware operatons. A BF security bug is a defect in the code or specificaton (i.e., metadata or algorithm) of sofware, firmware, or hardware circuit logic. A bug could be introduced in an operaton (i.e., the improper operaton) by a programmer, be the result of a design flaw, or be induced by a hardware defect. Hardware defects can result from overheatng, radiaton effects, electromagnetc interference (EMI), electrical noise, voltage variatons, electromagnetc fields, photon injecton, wear and tear, or other physical factors. Examples of code bugs include missing code (i.e., part of an operaton or an entre operaton is missing) or erroneous code (e.g., use of a wrong operator in an operaton). A memory bit flip due to a hardware defect can corrupt a low-level instructon. Examples of specificaton bugs include the use of an under-restrictve safelist for input validaton or a wrong algorithm for encrypton. A bug could also resurface from design flaws, such as an unaccounted-for system configuraton or environment. For example, while an operaton may run perfectly in a 64-bit operatng system (OS) environment, it may exhibit a security bug on a 32-bit platorm. The declaraton of an int instead of uint object would lead to a wraparound from a 32-bit calculaton that would eventually propagate to a buffer overflow. A BF fault1 is a name, data, type, address, or size error (i.e., an improper operand). Name relates to a resolved or bound object, functon, or data type. Data, type, address, and size relate to an object. A fault of an operand (i.e., the improper operand) could result from 1 The IEEE defines fault as “an incorrect step, process, or data definiton in a computer program” [24]. The BF

differentates bug, fault, and error as a code or specificaton defect of a BF operaton, data-related error of an operand, and the result of an operaton with a bug or faulty operand, respectvely (also see Sec. 4).

8

NIST SP 800-231 July 2024

a bug or another fault or be induced by a hardware defect. Only in the case of low-level storage (e.g., cache and CPU registers) is there no type fault. Adding to the examples of improper input operands in Sec. 3.1, other faults include invalid data, wild pointer, wrong type, or missing overridden functon. A wrong value could result from a missing validaton or an erroneous calculaton bug, but also from bit flips or signal disrupton due to overheatng or other physical factors. The BF models a security weakness as an improper executon state and its transiton to another weakness or a failure (see Fig. 2). An improper state is defined as an (operaton, operand1 , . . . , operandn ) tuple with at least one improper element (depicted in Fig. 2 in purple). A transiton is defined by the erroneous output from the operaton over its input operands. An improper operaton or operand is the cause of a security weakness. The erroneous result from the operaton over the operands is the consequence of that weakness and becomes a cause of another weakness or enables a failure. An operaton is improper if it has a bug. An operand is improper if it is ill-formed (i.e., it is at fault). BF Security Weakness Results in Error1 – Improper Operand2j Improper State1 (opera�on1, operand11 , ... operand1i , ... )

Improper State2 (opera�on2, …, operand2j , ... )

Results in Final Error

… Improper Staten (opera�onn, … operandnr , ... )

Failure

BF, I. Bojanova

Improper State – an (opera�on, operand1, …, operandn) tuple with at least one improper element

↷ Transi�on – Erroneous resultfrom the opera�on over the operands Ini�al State

Intermediate State

Final State

Failure

Fig. 2. BF security weakness The inital state (depicted in Fig. 2 in blue) is caused by a bug that, if fixed, will resolve the weakness. An intermediate state (in light purple) is caused by a fault. The final state (in dark purple) results in an undefined or exploitable system behavior (i.e., a final error). For example, in Fig. 2, the improper operaton1 from Improper State1 results in improper operand2i that causes Improper State2 . The last operatonn results in a Final Error that enables a Failure. The possible improper states depending on the cause and consequence of a security weakness are presented in Fig. 3. An improper state is caused by a security bug (i.e., the operaton is improper) or a fault (i.e., an input operand is improper). The consequence of an improper state is an error that propagates to another fault or is a security final error. 9

NIST SP 800-231 July 2024

BF Weakness States Cause

Consequence

Cause

Error

Fault

Bug Improper State1

Consequence Error Improper State2

(opera�on1, operand11 , ... operand1i , ... )

(opera�on2, …, operand2j , ... )

Cause

Consequence

Cause

Bug

Final Error

Fault

Improper State 1 Improper State 2 (opera�on 1, , …, (opera�on 2 operand 11 , ..., ... ) operand nr operand1i , ... )

Consequence Final Error Improper State2 (opera�on2, …, operandnr , ... )

BF, I. Bojanova

Ini�al Bug State

Intermediate (or HW Defect–Induced) Fault State

Final State

Fig. 3. BF weakness states A BF security weakness is a ⟨cause, operaton⟩→consequence relaton triple, which is formally a ⟨bug, operaton⟩→error, ⟨fault, operaton⟩→error, ⟨bug, operaton⟩→final error, or ⟨fault, operaton⟩→final error causal triple of a bug or fault weakness type. A bug informs that the operaton is improper, while a fault informs about an improper operand. Examples of weaknesses include ⟨Missing Code, Sanitze⟩→SQL Injecton, ⟨Wrong Size, Repositon⟩→Overbound Pointer, and ⟨Dangling Pointer, Read⟩→Use Afer Deallocate. In the C programming language, the last final error is known as use afer free. 3.3. BF Vulnerability The BF models a security vulnerability as a chain of improper states that propagate as the error (i.e., the erroneous output) from one state becomes the fault (i.e., the improper input) for the next state untl a final error that can be exploited toward a security failure is reached (see Fig. 4). That is, a vulnerability is a causal chain of weaknesses. The inital state (depicted in blue) is caused by a sofware or firmware bug (i.e., an operaton defect) (see the blue solid arrow), which if fixed will resolve the vulnerability. A vulnerability chain may also start from a hardware defect-induced bug or fault (see the green dashed arrows), which if fixed will resolve that vulnerability. A propagaton state (depicted in light purple) is caused by a fault (i.e., an operand error). The final state (shown in dark purple) results in a final error (i.e., an undefined or exploitable system behavior) and can lead to a failure (i.e., a violaton of a system security requirement). It usually directly relates to a CWE, but there are also CWEs that correspond to inital or propagaton weakness states. An error is the result of an improper state operaton over its operands. It becomes an improper operand — a fault — for the next improper 10

NIST SP 800-231 July 2024

state. A final error is the result of the operaton from the final improper state. It introduces an exploit vector — that is, the pathway for exploitaton — toward a security failure. BF Security Vulnerability Error1 → Fault of Operand2j

SW/FM Bug in Opera�on1

Error2 → Fault of Operand3k

Errornp-1 → Fault of Operandnp

Final Error → Exploit Vector

… Improper State1

or HW Defectinduced Bug

(opera�on1, operand11 , ... operand1i , ... )

Improper State2

Improper Staten

(opera�on2, ... operand2j , ... )

(opera�onn, … operandnp , ... )

or HW Defectinduced Fault

Failure (exploit, vector)

BF, I. Bojanova

Improper State – an ⟨opera�on, operand1, …, operandn⟩ tuple with at least one improper element Ini�al State – caused by a Bug

Final State – introduces an Exploit Vector

Propaga�on State – caused by a Fault

Failure – result of the exploit of the vector supplied by the Final Error

SW – So�ware, FM – Firmware, HW – Hardware

↷ Chaining

Fig. 4. BF security vulnerability For example, in Fig. 4, operaton1 from Improper State1 is improper due to a bug and results in Error1 that propagates to the improper operand2 j , which leads to Improper State2 . The last operatonn with improper operandnp results in a Final Error that propagates to an Exploit Vector to enable a Failure. As errors propagate to faults, the examples of faults also apply to errors. However, an error may be on a higher level of abstracton than a specific fault. For example, an inconsistent value error may propagate to the more specific wrong argument data fault (e.g., see the discussion about Fig. 5) or wrong size fault (e.g., see the discussion about Fig. 17). Examples of final errors include integer overflow, query injecton, buffer overflow, and side communicaton channels. Legitmate and side channels may also be direct exploit vectors without prior causaton. Examples of failures include informaton exposure (IEX) (i.e., confidentality loss), data tampering (TPR) (i.e., integrity loss), denial of service (DOS) (i.e., availability loss), and arbitrary code executon (ACE) (i.e., everything could be lost). The inital bug state is of an improper operaton over proper operands. It is the state with a defect in the operaton. The bug must be fixed to resolve the vulnerability. A fault state is of a proper operaton over an improper operand. It is a state with a defect in an operand that — if fixed — would only mitgate a vulnerability. If the inital state is caused by a hardware defect-induced fault, its fix will resolve the vulnerability. Vulnerabilites may also converge at their final states and chain via faults resultng from exploits. The converged final states enable a security failure, which would not have been

11

NIST SP 800-231 July 2024

harmful if only one were present. The chained faults-only vulnerabilites propagate toward a final security failure. A partcular BF security vulnerability chain may correspond to more than one CVE. For example, BadAlloc is a vulnerability patern that covers more than 25 similar CVEs [25] related to memory allocators, such as malloc() and calloc(). They were found in widely used real-tme operatng systems (RTOS), standard C libraries, IoT device SDKs, and other self-memory management applicatons going as far back as the early ‘90s [26]. The BF causal chain of the BadAlloc vulnerability patern comprises five BF weaknesses [1]: DVR↷TCM↷MMN↷MAD↷MUS (see Fig. 5). The first weakness is at the input data verificaton phase of sofware executon. The memory allocaton implementaton has no proper size verificaton toward the maximum allowed value accountng for how the requested memory size is calculated — that is, a BF Data Verificaton (DVR) weakness [1]. This input becomes a wrong argument for a calculaton that produces a value greater than the maximum integer allowed for the partcular operatng environment (e.g., 232 − 1 for a 32-bit OS) and wraps around the result (i.e., integer overflow error) — that is, a BF Type Computaton (TCM) weakness [1]. BF BadAlloc Pa�ern Missing/Erroneous Code Bug

Inconsistent Value → Wrong Argument

DVR (Verify, Data)

Wrap Around → Wrong Size

TCM (Calculate, Name, Data)

Insufficient Size

MMN (Allocate, Data, Address, Size)

Buffer Overflow Final Error

Overbound Pointer

MAD (Reposi�on, Data, Type, Address, Size)

MUS (Write, Data, Type, Address, Size)

Improper States – an ⟨opera�on, operand1, …, operandn⟩ tuples with at least one improper element:

↷ Chaining

Ini�al State – caused by a Bug

Final State – introduces an Exploit Vector

Propaga�on State – caused by a Fault

Failure – result of the exploit of the vector supplied by the Final Error

DoS

DVR – Data Verifica�on, TCM – Type Computa�on, MMN– Memory Management, MAD – Memory Addressing, MUS – Memory Use DoS – Denial of Service, ACE– Arbitrary Code Execu�on, RCE– Remote Code Execu�on

ACE / RCE BF, I. Bojanova

Fig. 5. BF BadAlloc patern Consequently, a much smaller wrong size is used at allocaton resultng in a memory buffer with an insufficient size — that is, a BF Memory Management (MMN) weakness [1]. This allows a pointer to be repositoned outside the buffer boundary — a BF Memory Addressing (MAD) weakness [1]— and data to be writen there — a BF Memory Use (MUS) weakness [1]. The buffer overflow final error can then be exploited toward a DOS or ACE (specifically, remote code executon [RCE] on a targeted device) failure. CVE-2021-21834 is one partcular vulnerability that strictly follows the BadAlloc patern (see its BF CVE-2021-21834 specificaton at [1]). 12

NIST SP 800-231 July 2024

3.4. BF Bug Identficaton If there is a cybersecurity failure, there should be a way to identfy the root cause (i.e., the security bug) and the chain of triggered improper executon states that enables the failure. Theoretcally, addressing the problem of identfying a security bug would be first to generate the graph of all possible vulnerability chains of weaknesses. Then, search the graph via brute force recursive backtracking with specific constraints to find the set of possible valid paths. Finally, select the only proper path via code analysis. However, the BF formalism ensures predictve recursive-descent parsing that does not require backtracking, as the BF formal language is generated by an LL(1) CFG. Knowing the failure and the possible transitons at executon that adhere to the BF causaton within a weakness as a ⟨cause, operaton⟩→consequence relaton and between weaknesses via a consequence↷cause propagaton (see Sec. 7.2), the bug can be identfied going backward ↶ from the final weakness untl an operaton is improper (see Fig. 6). Fixing the bug within that operaton would resolve the vulnerability. BF Backward Bug Iden�fica�on Iden�fy the Bug

Backward to Improper Opera�on1

Bug Improper State1

Improper Operand2j

(opera�on1, operand11 , ... operand1i , ... )

Backward to Improper Operand2j

Improper State2

Improper Operand3k

…

Backward to Improper Operandnp-1

Backward from the Failure to Improper Operandnp

Improper Operandnp

Final Error

(opera�on2, ... operand2j , ... )

Improper Staten (opera�onn, … operandnp , ... )

Failure (exploit, vector)

BF, I. Bojanova

Improper State – an ⟨opera�on, operand1, …, operandn⟩ tuple with at least one improper element Ini�al State – caused by a Bug

Final State – results in an Exploitable Error

↷ Chaining

Propaga�on State – caused by a Fault

Failure – caused by exploita�on of the Final Error

↶ Backwards to previous State

Fig. 6. BF backward bug identficaton Using the BF formal language syntax and semantcs that are based on the BF taxonomies, models, and causaton and propagaton rules, (see Sec. 5, 6, 7, and 8) a state tree can be directly generated backward startng from a failure and a final error or weakness. The state tree is an undirected graph with exactly one simple path between any pair of nodes. The failure is the root of the tree, and each path is a reverted possible vulnerability specificaton chain of weaknesses from the final error through faults to a bug. A weakness is specified as a ⟨bug/fault, operaton⟩→error/final error causal triple. This methodology allows for the generaton of a reasonable number of possible BF specificaton chains of weaknesses for a partcular CVE. The only proper path can then be identfied as the rest get eliminated via code analysis.

13

NIST SP 800-231 July 2024

4. BF Security Concepts A BF security bug or weakness type relates to a distnct sofware, firmware (including microcode), or hardware circuit logic executon phase defined by a set of BF operatons and their input operands and output results. A BF operaton is the minimal input-process-output code that can produce or propagate an improper name, data, type, address, or size. The BF defines the concepts of bug, fault, error, final error, weakness, vulnerability, exploit vector, and failure in the context of cybersecurity to provide the level of detail and granularity needed to understand the causaton within a weakness and the causaton and propagaton between weaknesses and between vulnerabilites. • A security bug is a code or specificaton defect (i.e., an operaton defect) in sofware, firmware, or hardware circuit logic — that is, proper operands over an improper operaton. The specificaton includes the operaton metadata and algorithm. A bug could be introduced by a programmer, be the result of a design flaw, or induced by a hardware defect (e.g., due to overheatng). A bug could also resurface from a design flaw (e.g., an unaccounted-for system configuraton or environment). • A fault is a name, data, type, address, or size error (i.e., an operand error) — that is, an improper operand over a proper operaton. A fault could result from a bug or another fault or be induced by a hardware defect. In the case of low-level storage (e.g., cache and CPU registers), there is no type fault. • An error is the result of an operaton with a bug or faulty operand that propagates to a fault of an operand of another operaton. • A security final error is an undefined or exploitable system behavior. A final error results from an operaton with a bug or faulty operand. • A security weakness is a ⟨bug, operaton⟩→error, ⟨fault, operaton⟩→error, ⟨bug, operaton⟩→final error, or ⟨fault, operaton⟩→final error causal triple. • A security vulnerability is a causal chain of weaknesses that starts with a bug or hardware defect-induced fault, propagates through errors that become faults, and ends with a final error that introduces an exploit vector. The first weakness concerns the root cause of the vulnerability, and the last weakness concerns its sink. • A security exploit vector is the pathway for the exploitaton of a vulnerability. • A security failure is a violaton of a system security requirement caused by the exploitaton of a security vulnerability. 14

NIST SP 800-231 July 2024

The BF security concept definitons are contextually visualized in Fig. 7. Following the blue solid inital arrow, a security vulnerability may start with a sofware or firmware security bug (i.e., a code or specificaton defect within an operaton). Following the green dashed arrow, a vulnerability chain may also start from a hardware defect-induced fault. Fixing the bug or hardware defect-induced fault will resolve the vulnerability, as well as any other vulnerability with the same root cause. Fixing a propagated fault, including the cause of the final error at the sink, will only mitgate the vulnerability. Occasionally, several vulnerabilites must converge at their final errors for an exploit to be harmful. Fixing the bug or startng fault of at least one of the chains would avoid the failure. An exploit of a vulnerability may result in a fault startng a new faults-only vulnerability. Fixing the bug or startng fault of the first vulnerability will resolve the entre chain of vulnerabilites. For more details, refer to the forthcoming SP 800-231A, Bugs Framework: Security Concepts. BF Security Concepts Model Security Vulnerability Bug Type Security Weakness 1

Error Type 1

Improper Opera�on

Weakness Type 1

Opera�on 1, Operand 11 , ... Operand 1i , ...

Security Bug

Error 1

Improper Operand

Fault Type 1 Weakness Type 2

Opera�on 2, Operand 21 , …, Operand 2j , ...

Fault 1

Security Weakness 2

Error Type 2 Error 2

…

Fault Type N-1 Weakness Type N Security Weakness N

Final Error Type

Improper Operand Opera�on N, Operand N1 , …, Operand NP , ...

Fault N-1

Security Final Error

Failure Type 1

Failure TypeF …

Bug

Opera�on

Fault / Error

Final Error

Security Failure 1 Failure

Security Failure F BF, I. Bojanova

Fig. 7. BF security concepts 15

NIST SP 800-231 July 2024

5.

BF Bugs Models

The BF security bugs and related faults landscape covers the operatons (i.e., the BF operatons) in sofware, firmware, and hardware executon phases at appropriate levels of abstracton. A BF operaton is the minimal input-process-output code that — because of a bug or fault — results in an error that propagates to another fault or is final (see Sec. 3.1). The BF bugs models define related executon phases with orthogonal sets of operatons in which partcular types of bugs or faults could occur. They also define the proper flow of operatons within and between the phases, which helps identfy causaton between weaknesses, as well as missing operatons (i.e., missing code bugs) backward from a failure. Some executon phases may only be on an applicaton level (e.g., input/output check), while others may cover deeper levels of abstracton (e.g., the programming language type system, the OS file system, or the CPU). In any case, if there is a security failure, there must have been an operaton with a security bug or a hardware defect-induced fault that propagated through faults of other operatons untl a security final error that introduces an exploit vector is reached. 5.1. BF Input/Output Check ( INP) Bugs Model The BF Input/Output Check ( INP) Bugs Model shows that input/output data check bugs could be introduced at the data validaton (DVL) or data verificaton (DVR) executon phase (see Fig. 8). The phases determine the BF INP classes: Data Validaton (DVL) and Data Verificaton (DVR) [1, 16]. BF Input/Output Check (_INP) Bugs Model Unchecked Data DVL

DVR

Validate

Verify Sani�ze

Correct

Checked Data Data Life�me

BF, I. Bojanova

Fig. 8. BF Input/Output Check ( INP) Bugs Model Each input/output check-related bug or fault involves a Validate, Sanitze, Verify, or Correct operaton. According to the flow of operatons, input/output data must be validated and sanitzed and/or verified and corrected. 16

NIST SP 800-231 July 2024

5.2. BF Memory ( MEM) Bugs Model The BF Memory ( MEM) Bugs Model shows that memory-related bugs could be introduced at any phase in the life cycle of an object: memory addressing (MAD), memory allocaton (MAL), memory use (MUS), or memory deallocaton (MDL) (see Fig. 9). The phases determine the BF MEM classes: Memory Addressing (MAD), Memory Management (MMN) that combines the MAL and MDL phases, and Memory Use (MUS) [1, 17]. Memory Bugs Model

Object Space

Other Object / NULL

MAD (pointer/owner ) Ini�alize

Reassign

assign & posi�on

Reposi�on ++, --, etc.

Al

Dereference

lO rs

e wn

a�er object is ini�alized

MAL ( object)

once

Extend

rs

wne

Reallocate-Extend

All O

Allocate

All Ow ne

rs

Upper Bound

MUS (object) Ini�alize Object Size

first write

Write

Clear last write

Read

MDL (object) Reduce Reallocate-Reduce

Lower Bound

Deallocate once

BF, I. Bojanova

Create Object

Object In Use

Destroy Object

Object Life�me

Fig. 9. BF Memory ( MEM) Bugs Model Each memory-related bug or fault involves an Initalize Pointer, Dereference, Repositon, Reassign, Allocate, Extend, Reallocate–Extend, Initalize Object, Read, Write, Clear, Reduce, Reallocate–Reduce, or Deallocate operaton. 17

NIST SP 800-231 July 2024

The main memory-related operatons flow is presented in Fig. 9 via blue and black solid arrows. The green dashed arrows show the flow for allocaton at a specific address. The red dot-dashed arrows show the extra flow in case of reallocaton. Following the blue arrows, the first operaton is MAL Allocate an object. Following the green arrows, the first operaton is MAD Initalize Pointer. The next operaton following the blue arrows must be MAD Initalize Pointer for the allocated object to the address returned by the Allocate operaton. In contrast, the next operaton following the green arrows must be MAL Allocate an object at the address that the pointer holds. Afer an object is allocated and its pointer initalized, MUS Initalize Object (i.e., the first write) must follow. Then, it may be accessed via MAD Dereference and used via MUS Read or Write at any point before it is cleared and deallocated. The boundaries and size of an object set at allocaton can be changed via MAL Extend, MAL Reallocate-Extend, MDL Reduce, or MDL Reallocate-Reduce. Operatons that involve reallocaton must be followed by MAD Repositon for all of the pointers that own the object. MDL Deallocate an object must be preceded by MUS Clear (i.e., the last write) and followed by MAD Reassign for all of its pointers to either NULL or another object. 5.3. BF Data Type ( DAT) Bugs Model BF Data Type ( DAT) Bugs Model shows that data type bugs could be introduced at the declaraton (DCL), name resoluton (NRS), data type conversion (TCV), or data type-related computaton (TCM) executon phase (see Fig. 10). The phases determine the BF DAT classes: Declaraton (DCL), Name Resoluton (NRS), Type Conversion (TCV), or Type Computaton (TCM) [1, 18]. Each data type-related bug or fault involves a Declare, Define, Refer, Call, Cast, Coerce, Calculate, or Evaluate operaton. According to the data type-related operatons flow shown in Fig. 10, the first operatons over an entty (i.e., object, functon, data type, or namespace) are DCL Declare and DCL Define. Then, it can be referred to in code by its name via NRS Refer. Names that are referred to in remote scopes get resolved via namespaces. Resolved data types get bound to objects, functons, or generic data types according to their declaratons (see the purple dot-dashed arrow flow). Resolved functons get bound to implementatons and may be called via NRS Call. A resolved and bound object may be explicitly converted to another data type via TCV Cast and used to call a member functon via NRS Call or as an argument or return of a computaton functon. A passed-in argument is expected to be of the declared parameter data type, and the passed-out result is expected to be of the return data type. Otherwise, TCV Cast is expected before or at the end of the call (see the blue large-dashed arrow flow), or the value will get implicitly converted via TCV Coerce to the parameter or return data type, respectvely (see the green dashed arrow flow).

18

NIST SP 800-231 July 2024

BF Data Type (_DAT) Bugs Model Space Interpreta�on

Argum ent / R eturn / (.)

Object

DCL (en�ty) Type/ N

Declare

amesp

ace

Define NRS

Object Layout

(en�ty name)

Subty

Refer

Ar gu m

en t/

Elements Size

pe Ob

func�on Call

Re tu

rn /

(.)

Ob

Argum

ent

TCV (object)

jec

Ob jec

ject

t Cast

t

Coerce TCM (object) Calculate Evaluate BF, I. Bojanova

Type System Timeline

Fig. 10. BF Data Type ( DAT) Bugs Model The green arrow flow is only about passed-in or passed-out objects that are coerced. It starts from NRS Call and never from DCL Declare. A comprehensive BF bugs model would combine and connect all BF bugs models via the proper flow between their operatons. For example, DAT DCL Declare and INP DVR Verify may be followed by MEM MAD Repositon, DAT TCM Calculate, or DAT TCV Coerse. DAT TCV Coerse may be followed by MEM MMN Allocate, MEM MAD Repositon, DAT TCM Calculate, or MEM MMN Deallocate. DAT TCM Calculate may be followed by MEM MMN Reallocate-Reduce. For more bugs models and details, refer to the forthcoming SP 800-231B, Bugs Framework: Bugs Models.

19

NIST SP 800-231 July 2024

6. BF Taxonomy The BF taxonomy comprises weakness and failure categories. The BF Weakness category comprises BF weakness class types, such as: • BF Input/Output Check( INP) class type — Weaknesses that lead to input/output data check-related errors or introduce injecton exploit vectors • BF Memory ( MEM) class type — Weaknesses that lead to memory-related errors or introduce memory corrupton/disclosure exploit vectors • BF Data Type ( DAT) class type — Weaknesses that lead to data type-related errors or introduce type compute exploit vectors The BF Failure category comprises the BF failure class type: • BF Failure ( FLR) class type — Failures that lead to the loss of a security property due to the exploit of a vulnerability 6.1. BF Weakness Classes The BF weakness taxonomy structure is based on orthogonal by operatons phases of sofware, firmware, and hardware executon. A BF weakness class defines sets of possible bugs and faults as causes for the operatons of a specific phase over their operands to result in errors and final errors as consequences. As an error propagates to a fault (see Sec. 4), the set of errors is the same as the set of faults across classes. However, a specific propagaton may be via values on different levels of abstracton (see Sec. 3.2). Similarly, the set of final errors across classes is the same as the set of exploit vectors toward failures. A BF weakness class also defines operaton and operand atributes and code sites. A BF weakness class type encompasses strictly defined weakness classes of closely related executon phases. For example, the BF INP class type comprises the Data Validaton (DVL) and Data Verificaton (DVR) classes. The BF MEM class type comprises the Memory Addressing (MAD), Memory Management (MMN), and Memory Use (MUS) classes [17]. The BF DAT class type comprises the Declaraton (DCL), Name Resoluton (NRS), Type Conversion (TCV), and Type Computaton (TCM) classes [18]. For all current BF class types, refer to the BF Taxonomy at at [1]. The definiton of the BF Data Validaton (DVL) class (see Fig. 11) is “Data is validated (i.e., syntax check) or sanitzed (i.e., escape, filter, or repair) improperly.” It organizes security bugs by the Validate and Sanitze operatons and faults by their Data operand as causes [16]. Possible causes are the Missing Code bug and Corrupted Policy Data fault. Possible consequences are the Invalid Data error and Query Injecton and Command Injecton final injecton errors, which relate to input/output check safety (see 9.1). 20

NIST SP 800-231 July 2024

Bugs Framework (BF) Input/Output Check (_INP) Class Type Data Valida�on (DVL) Class Causes

Opera�ons

Code Bug Missing Code Erroneous Code Specifica�on Bug Under-Restric�ve Policy Over-Restric�ve Policy

Consequences

Validate Sani�ze

Data Error

Operands

Injec�on Final Error

Invalid Data

Query Injec�on Command Injec�on Source Code Injec�on Parameter Injec�on File Injec�on

Data

Data Fault Corrupted Data Tampered Data Corrupted Policy Data Tampered Policy Data

BF, I. Bojanova

A�ributes Mechanism Safelist Denylist Format Length

Bug

Source Code Codebase Third-Party Standard Library Compiler/Interpreter

Execu�on Space Local Admin Bare-Metal

Fault/Error

Final Error

Data State Entered Stored In Use Transferred

Opera�on/Operand

Fig. 11. BF Data Validaton (DVL) class The definiton of the BF Memory Use (MUS) class (see Fig. 12) is “An object is initalized, read, writen, or cleared improperly.” It organizes security bugs by the Initalize Object, Read, Write, and Clear operatons and faults by their Data, Type, Address, and Size operands as causes [17]. Possible causes are the Wrong Size and Cast Pointer faults. Possible consequences are the Uninitalized Object error and Buffer Overflow and Use Afer Deallocate (e.g., use afer free or use afer return) memory corrupton or disclosure final errors, which relate to memory safety (see 9.2). The definiton of the BF Type Conversion (TCV) class (see Fig. 13) is “Data is converted or coerced into other types improperly.” It organizes security bugs by the Cast and Coerce operatons and faults by their Name, Data, and Type operands as causes [18]. Possible causes are the Over Range and Wrong Type faults. Possible consequences are the Rounded Value and Downcast Pointer errors, which relate to data type safety (see 9.3). The BF strictly defines the type taxons (e.g., see the terms in black in Figs. 11, 12, and 13) for causes as bugs or faults, for consequences as errors or final errors, and for operaton and operand atributes. For example, the Specificaton Bug, Data Fault, Injecton and Memory Corrupton/Disclosure Final Errors (see Figs. 11 and 12) taxon types are defined in Table 2. The BF also strictly defines the value taxons (e.g., see the terms in purple in Figs. 11, 12, and 13) for class, operatons, causes (as bugs or faults), consequences (as errors or final errors), and operaton and operand atributes. For example, the Under-Restrictve Policy bug, 21

NIST SP 800-231 July 2024

Bugs Framework (BF) Memory Corrup�on/Disclosure (_MEM) Class Type Memory Use (MUS) Class Causes

Opera�ons

Code Bug

Consequences

Ini�alize Object Read Write Clear

Missing Code Erroneous Code Data Fault NULL Pointer Forbidden Address Wrong Size

Operands Data Type Address Size

Type Fault Cast Pointer

Data Error Unini�alized Object Memory Corrup�on/Disclosure Final Error Not Cleared Object Object Corrup�on Type Confusion Use A�er Deallocate Buffer Overflow Buffer Underflow Buffer Over-Read Buffer Under-Read

Address Fault

BF, I. Bojanova

Wild Pointer Dangling Pointer Untrusted Pointer Overbound Pointer Underbound Pointer Wrong Posi�on Pointer Size Fault Insufficient Size A�ributes Mechanism Direct Sequen�al

Bug

Source Code Codebase Third-Party Standard Library Compiler/Interpreter

Execu�on Space Userland Kernel Bare-Metal

Address Kind Huge Moderate Li�le

Fault/Error

Address State Stack Heap /other/

Final Error

Size Kind Actual Used

Opera�on/Operand

Fig. 12. BF Memory Use (MUS) class Wrong Size fault, Sanitze and Write operatons, and Query Injecton and Buffer Overflow final errors (see Figs. 11 and 12) taxon values are defined in Table 3. The operaton atribute types are defined in Table 4. Their values per BF class may be different for the same operaton atribute type (e.g., the Mechanism for MUS Write is Direct or Sequental, while for TCV Coerce, it is Pass in or Pass out). The possible operand attribute types are defined in Table 5. Their values per BF class may be different for the same operand atribute type. Each BF class taxonomy defines a matrix of semantc rules for causaton within a weakness, as some combinatons of its cause, operaton, and consequence value taxons may not be meaningful. They are expressed as ⟨bug, operaton⟩→error, ⟨fault, operaton⟩→error, ⟨bug, operaton⟩→final error, and ⟨fault, operaton⟩→final error triples. For example, ⟨Wrong Size, Write⟩→Buffer Overflow is a valid triple, while ⟨Wrong Size, Write⟩→Buffer Over-Read is not, as the operaton is Write but the final error is about reading.

22

NIST SP 800-231 July 2024

Bugs Framework (BF) Data Type (_DAT) Class Type Type Conversion (TCV) Class Causes

Opera�ons

Code Bug

Consequences

Cast Coerce

Missing Code Wrong Code

Data Error Wrong Value Flipped Sign Truncated Value Distorted Value Rounded Value

Operands Name Fault Name Data Type

Wrong Object Resolved Missing Overloaded Func�on

Type Error Cast Pointer Downcast Pointer Wrong Type

Data Fault Under Range Over Range Flipped Sign Type Conversion Final Error

Subtype Confusion

Type Fault Wrong Type Wrong Object Type Resolved Mismatched Argument

BF, I. Bojanova

A�ributes Mechanism Pass In Pass Out

Bug

Source Code Codebase Third-Party Standard Library Compiler/Interpreter

Execu�on Space Local Admin Bare-Metal

Name State Resolved Bound

Fault/Error

Data Kind Numeric Text Pointer Boolean

Final Error

Type Kind Primi�ve Structure

Opera�on/Operand

Fig. 13. BF Type Conversion (TCV) class Each BF class taxonomy also defines a matrix of semantc rules for propagaton between weaknesses, as error to fault match is always by type but may be on different levels of abstracton by value (for details, see the forthcoming SPs 800-231Cx and [1]). Formally, the specificaton of a security weakness is an instance of a BF weakness class with one cause, one operaton, one consequence, and operaton and operand atribute values from the sets with value taxons of that class. The operaton binds the causaton within a weakness as a ⟨cause, operaton⟩→consequence relaton that must adhere to the within-weakness causaton semantc rules for that class. For example, the two most severe weaknesses — missing validaton of input data leads to a SQL query injecton and writng data via a pointer beyond the upper bound of an array leads to a buffer overflow [27] — are specified with BF as follows: ⟨Missing Code, Validate⟩→ Query Injecton and ⟨Overbound Pointer, Write⟩→Buffer Overflow. The BF class taxonomies with built-in taxon definitons are available in machine-readable formats (e.g., see the BF in XML format in Fig. 14 and query it via the BF API at [1]). The type and value taxon definitons are visualized in the graphical representaton of the BF class taxonomies (e.g., see the BF MUS class at [1]) and BFCVE specificatons (e.g., the BF CVE-2014-0160 specificaton at [1]), and as tooltps of the BF tool (see Sec. 10.3). 23

NIST SP 800-231 July 2024

Table 2. Type taxon definiton examples Name Specificaton Bug

Definiton A defect in the metadata or algorithm of an operaton (i.e., proper operands over an improper operaton). It is the root cause of a security vulnerability. The data of an object has harmed semantcs or an inconsistent or wrong value. An exploitable or undefined system behavior caused by validaton or sanitzaton bugs. An exploitable or undefined system behavior caused by memory addressing, allocaton, use, or deallocaton bugs.

Data Fault Injecton Memory Corrupton/ Disclosure

Table 3. Value taxon definiton examples Name Under-Restrictve Policy Wrong Size Sanitze Write Query Injecton Buffer Overflow

Definiton Accepts bad data. For example, permissive safe list or regular expression, or incomplete deny list. The value used as size or length (i.e., the number of elements) does not match the object’s memory size or length. Modify data (e.g., neutralize/escape, filter/remove, repair/add symbols) to make it valid (well-formed). Change the data value of an object in memory to another meaningful value. Maliciously inserted conditon parts (e.g., or 1 == 1) or entre commands (e.g., drop table) into an input used to construct a query (e.g., SQL or NoSQL Injecton, XPath Injecton, XQuery Injecton, or LDAP Injecton). Write data above the upper bound of an object (i.e., buffer overwrite).

Table 4. Operaton atribute types Name Mechanism Source Code Executon Space

Definiton Shows how the operaton with a bug or faulty operand is performed. Shows where the code of the operaton with a bug or faulty operand resides. Shows where the operaton with a bug or faulty operand is executed and the privilege level at which it runs.

Table 5. Operand atribute types Name Name Kind Name State Data Kind Data State Type Kind Address Kind Address State Size Kind

Definiton Shows what the entty with this name is. Shows what the stage of the entty name is. Shows what the type or category of data is. Shows where the data comes from. Shows what the data type compositon is. Shows how much memory is accessed (i.e., the span) outside of a bound of an object. Shows where the address is (i.e., its locaton) in the memory layout. Shows what is used as the size or length (i.e., the number of elements) of an object.

24

NIST SP 800-231 July 2024

Fig. 14. BF taxonomy in XML

25

NIST SP 800-231 July 2024

6.2. BF Failure Class A BF failure class defines sets of possible exploit vectors used for the exploits of a specific vulnerability to result in the loss of security propertes. The exploit vectors propagate from the final errors of BF weakness classes. The BF Failure ( FLR) class type encompasses strictly defined failure classes, such as: • Informaton Exposure (IEX) — Inadvertent disclosure of informaton that leads to confidentality loss. • Arbitrary Code Executon (ACE) — Executon of unauthorized commands or code executon that could lead to everything being lost. Remote code executon (RCE) is a sub-case of ACE on a target system or device from a remote locaton, typically over a network. • Denial of Service (DOS) — Disrupton of access to or use of informaton or informaton systems that leads to availability loss. • Data Tampering (TPR) — Unauthorized modificaton or destructon of informaton that leads to integrity loss. An IEX, ACE, or TPR failure may result in a fault that starts a new chained vulnerability. 6.3. BF Methodology The methodology for developing BF bugs models and weakness classes involves the following 12 steps (also see Fig. 15): 1. Phases: Analyse common weakness types (including CWEs) and publicly disclosed vulnerabilites (including CVEs) and identfy related sofware, firmware, or hardware executon phases in which specific types of bugs could be introduced and faults propagated. Each executon phase would be the basis for defining a new BF weakness class. The BF classes of related executon phases would define a new BF class type. For example, the MAD and MUS classes (see Fig. 12) correspond to the related memory addressing and memory use executon phases. They are also of the BF MEM class type [1, 17]. 2. Operatons and Operands: Identfy the operatons and their input operands for each executon phase so that all BF classes remain orthogonal by operaton. They would define the possible values of operatons for the ⟨cause, operaton⟩→consequence weakness triples for each of the new BF classes. For example, the DVL class has two operatons (see Fig. 11), MUS has four operatons (see Fig. 12), TCV has two operatons (see Fig. 13), and their sets of operatons do not overlap. 26

NIST SP 800-231 July 2024

BF Weakness Class Methodology

1. Related phases for specific types of bugs/faults

2. Opera�ons for each phase and their operands

4. Bug Causes – improper opera�ons

5. Fault Causes – improper operands

8. Sites in code

9. Opera�on A�ributes

10. Operand A�ributes 11. Seman�c Matrices 3. BF Bugs Model – opera�ons flow

12. Seman�c Graphs

6. Consequences that are Errors – become fault causes for other weaknesses

BF, I. Bojanova

7. Consequences that are Final Errors

Fig. 15. BF class methodology 3. Bugs Model: Define the BF bugs model reflectng the identfied phases, operatons, and the proper flow between the operatons. It would be the basis for the definiton of a semantc graph of meaningful operaton flow. For example, the BF Memory Bugs Model covers the MAD, MAL, MUS, and MDL phases and the flow between their operatons (see Fig. 9). 4. Bug Causes: Identfy the possible code and specificaton defects for the operatons of each phase. They would define the bug values of the ⟨bug, operaton⟩→error or ⟨bug, operaton⟩→final error weakness triples (see Fig. 3) for each of the new BF classes. For example, the DVL class has two values for each of the Code Bug and Code Specificaton bug types — Missing Code and Erroneous Code, and Under-Restrictve Policy and Over-Restrictve Policy, respectvely (see Fig. 11). 5. Fault Causes: Identfy which of the Name, Data, Type, Address, and Size input operands apply to the operatons of each phase. They would define the possible fault and error types. Identfy the possible operand errors, which would define the fault values of the ⟨fault, operaton⟩→error or ⟨fault, operaton⟩→final error weakness triples (see Fig. 3) for each of the new BF classes. For example, the MUS class has Data Fault, Type Fault, Address Fault, Size Fault, and Data Error types — the first four as causes, the last one as a consequence. It also has 11 fault values (see Fig. 12). 27

NIST SP 800-231 July 2024

6. Error Consequences: Identfy the possible output result errors from the operatons that propagate as faults of other weaknesses (i.e., improper input operands for other operatons). These would define the error values of the weakness triples (see Fig. 3). For example, there is one error value for DVL — Invalid Data (see Fig. 11), one for MUS — Uninialized Object (See Fig. 12), and eight for TCV — five of Data Error and three of Type Error type (see Fig. 13). 7. Final Error Consequences: Identfy the possible output result errors from the operatons that do not propagate to faults of other weaknesses and instead propagate to exploit vectors toward failures. They would define the final error values of the weakness triples (see Fig. 3). For example, MUS has one final error type — Memory Corrupton/Disclosure — with eight final error values (see Fig. 12). 8. Sites: Identfy syntactc places in code where such bugs or faults can occur. This step is mainly applicable to low-level bugs and faults. 9. Operaton Atributes: Identfy specific descriptve values for the Executon Space, Mechanism, and Source Code operaton atribute types for each of the new BF classes. For example, DVL has the Safelist, Denylist, Format, and Length values for the Mechanism atribute type (see Fig. 11), while TCV has Pass In and Pass Out (see Fig. 13). 10. Operand Atributes: Identfy specific descriptve values for the relevant Name, Data, Type, Address, and Size atribute types for each of the new BF classes. For example, the TCV class has the Resolved and Bound values for the Name State operand atribute type; Numeric, Text, Pointer, and Boolean values for Data Kind; and Primitve and Structure values for Type Kind (see Fig. 13). 11. Semantc Matrices: Identfy the meaningful ⟨cause, operaton⟩→consequence causal relatons for each of the new BF classes, and same-type different-value consequence↷ cause propagatons for classes of different BF class types. 12. Semantc Graph: Define the graph of meaningful operaton flow based on the BF Bugs Model. Finally, create the BF weakness class taxonomies in machine-readable formats, generate graphical representatons to enhance understanding, regenerate the BF LL(1) CFG to include the new taxonomies, and update the BFDB database (see Sec. 10). The methodology for developing BF failure classes is analogous but also simpler, as final errors of BF weakness classes directly match to exploit vectors of BF Failure classes, and the exploit, at least for now, is on an abstract level. For more BF classes and details, refer to the forthcoming SPs 800-231Cx, Bugs Framework: yyy Taxonomy, where yyy is a BF class type. 28

NIST SP 800-231 July 2024

7.

BF Vulnerability Models

The BF vulnerability models define state and specificaton views of a security vulnerability as a chain of weaknesses linked by causality that may converge and chain with other vulnerabilites to enable harmful failures. The state view represents the weaknesses as improper-state (operaton, operand1 , . . . , operandn ) tuples and their causal transitons. The specificaton view reflects the BF taxonomic representaton of a weakness as a ⟨cause, operaton⟩→consequence relaton and consequence↷cause between weaknesses propagaton. 7.1. BF Vulnerability State Model The BF Vulnerability State Model defines a vulnerability as deterministc state automata of improper states and their transitons (see Fig. 16). A transiton is to another weakness or to a failure. An improper state is an (operaton, operand1 , . . . , operandn ) tuple with at least one improper element (depicted in purple). A BF operaton is the minimal input-processoutput code that — because of a bug or fault — results in an error that propagates to another fault or is final (see Sec. 3.1). A transiton is defined by the erroneous result from the operaton over the input operands (i.e., the output of the improper state). The inital state corresponds to a weakness caused by a bug in the operaton or a hardware defect-induced fault of an operand. It results in an error or — if it is the only state — is a final error (i.e., an undefined or exploitable system behavior). A propagaton state corresponds to a weakness that is caused by a fault of an operand and results in an error. The final state corresponds to a weakness caused by a fault of an operand or — if it is the only state — by a bug in the operaton. It results in a final error that introduces an exploit vector that enables a failure. The inital state relates to the root cause of the vulnerability, and the final state relates to its sink. For simplicity, Fig. 16 does not detail vulnerability chains that start with a hardware defect-induced bug or fault, as Fig. 4 does. Fixing the bug or a hardware defect-induced fault will resolve the vulnerability, while fixing a non-hardware-defect-induced fault will only mitgate it. Fixing a bug may relate to fixing a design flaw, such as an unaccounted-for system configuraton or environment. For a onechain improper states example, recall the BadAlloc patern in Fig. 5. Vulnerabilites compositon is via convergence at their final errors or failure-to-fault-based chaining. In some cases, for an exploit at the sink to be harmful, several vulnerabilites must converge (depicted with ⊕ in Fig. 16) at their final errors. Fixing the root cause (i.e., the bug) of at least one of the chains would avoid the failure. An exploit of a vulnerability may also result in a failure that creates a fault that starts a new vulnerability of only faulttype weaknesses. There must be an exploit for the failure to occur and a fault that results from it to start the new chain (see the gaps between the arrows and failures in Fig. 16 that indicate that there is no direct weakness-to-weakness transiton there). Fixing the root cause (i.e., the bug) of the first vulnerability will resolve the entre chain of vulnerabilites. 29

30

Final StateAn

Final ErrorA

Final StateBm (opera�onBm, …, operandBmq , ... )

Final ErrorB

(opera�onAn, …, operandAnp , ... )

(opera�onB1, operandB11 , ... operandB1i , ... )

…

ErrorBm → Fault OperandBmq

…

ErrorAn → Fault OperandAnp

Ini�al StateB1

ErrorB1 → Fault OperandB2k

(opera�onA2, …, operandA2j , ... )

BugB in Opera�onB1

Propaga�on State2

(opera�onA1, operandA11 , ... operandA1i , ... )

ErrorA2 → Fault OperandA3j

Ini�al StateA1

ErrorA1→ Fault Operand2j

Chaining weaknesses underlying a vulnerability

⊕ Converging vulnerabili�es

↷

(exploit1, vector1)

Failure1

…

ErrorN1→ Fault OperandN2j

(opera�onN1, operandN1i , ... )

Propaga�on StateN1

Fault OperandN1

Fig. 16. BF Vulnerability State model

Failure – a viola�on of a security requirement caused by an exploit; may result in a Fault star�ng a new faults -only vulnerability

Final State – a weakness caused by a Fault in an Operand, resul�ngin a Final Error

Propaga�on State – a weakness caused by a Fault of an Operand, resul�ng in an Error

Ini�al State – a weakness caused by a Bug in the Opera�on, resul�ng in an Error

Improper State – An operation, operand 1, …, operand n) tuple with at least one improper element (depicted in purple)

BugA in Opera�onA1

BF Security Vulnerability State Model

… (opera�onNl, … operandNlr , ... )

Final StateNl

ErrorNl→ Fault OperandNlr

FailureN

…

BF, I. Bojanova

(exploitN, vectorN)

Final ErrorNk

NIST SP 800-231 July 2024

NIST SP 800-231 July 2024

For example, in Fig. 16, Chain A starts from the Inital StateA1 , where operatonA1 has a sofware, firmware, or hardware defect-induced bug. The ErrorA1 result propagates to a fault of operandA2 j , which leads to the Propagaton StateA2 . The last operatonAn in this chain with faulty operandAnp results in the Final ErrorA . Chain B analogously propagates through improper states, and its Final ErrorB converges with Final ErrorA toward Failure1 and possibly more failures. Once the exploit vector introduced by the final errors is used to exploit the vulnerability, Failure1 possibly creates a faulty operandAN1 that starts a new vulnerability chain, and so on untl the final security FailureN is reached. Heartbleed, CVE-2014-0160 — as a real-world example — was a severe vulnerability in the OpenSSL cryptographic library [23]. A server (or client) with a vulnerable heartbeat extension would bleed data via a small heartbeat message with a large requested length (i.e., larger than the actual array size). Each exploit could reveal up to 64KB of raw memory of highly sensitve informaton (e.g., private keys and login credentals) via buffer over-reads. However, NVD labels it with CWE-125: Out-of-bounds Read, which covers both underlower-bound and over-upper-bound reads from a buffer. In additon, it reflects only the weakness with the final error at the sink, not the weakness with the bug as the root cause. The BF state view of Heartbleed is presented in Fig. 17 as two converging vulnerability chains of underlying weaknesses. The BF taxonomy helps identfy and comprehensively label three weaknesses in the main chain and one more in the secondary chain. BF CVE-2014-0160 – Heartbleed Missing Code Bug

Inconsistent Value → Wrong Size Data Error/Fault

DVR (Verify: Missing Code, Data)

Buffer Over-Read Final Error

Over Bound Pointer Address Error/Fault

MUS (Read, Data, Type, Address: Over Bound Pointer, Size)

MAD (Reposi�on, Data: Wrong Size, Type, Address, Size)

Not Cleared Object MUS (Clear: Missing Code, Data, Type, Address, Size)

IEX

BF, I. Bojanova

Improper State – An operation, operand 1, …, operand n) tuple with at least one improper element (depicted in purple) Ini�al State

↷

Intermediate State

Chaining weaknesses underlying a vulnerability

Final State

⊕ Converging vulnerabili�es

Fig. 17. BF states of Heartbleed 31

Failure

NIST SP 800-231 July 2024

The bug was both in the ssl\d1 both.c and ssl\t1 lib.c files of the OpenSSL implementaton of the TLS protocol [28]. Analysis of the C code before the fix (see Fig. 18 for d1 both.c) shows that the very first improper BF state is in the data verificaton phase, where the semantcs of the input should be checked and corrected. The pointer p (see line 1450 in Fig. 18) is to a record of type SSL3 RECORD (see the top of Fig. 18) whose second field holds the length. The payload variable is declared as an unsigned int (see line 1452) and can be a huge number. It is assigned the value of the length field of p via the n2s macro (see line 1457). That is input data that supplies the length of an array (i.e., a buffer), but it is not checked before use toward the actual array size (i.e., the number of elements in the record data). Its value is not verified. This BF bug state is the first of a chain of improper states that would lead to buffer over-read. It is an instance of the BF Data Verificaton (DVR) class [1] as the (Verify: Missing Code, Data) tuple with an improper Verify operaton element (see the first state in Fig. 17) — the entre data verificaton operaton is absent — that results in an Inconsistent Value error. Then, memcpy() reads payload number of bytes from the object pointed by pl and copies them to the object pointed by bp (see line 1480 in Fig. 18). Following the naive C implementaton of memcpy() at the botom in Fig. 18, bp and pl are passed by reference via the dst and src arguments, and the huge payload length is passed via the n argument. First, one byte is read from pl and copied to bp. Untl the huge payload length is reached, both pointers move one byte up, and the newly pointed by pl byte is read and copied. However, while bp is allocated large enough at up to 1+2+65535+16 bytes (see lines 1474 and 1475 in Fig. 18), pl points to an array with a reasonable size (see line 1458). As the content of this array is read and copied to bp, so too is a huge amount of data from over its upper bound. The analysis reveals two fault states: when pl is repositoned over the array upper bound and when data values are read from there. The former is an instance of the BF Memory Addressing (MAD) class [1] as the (Repositon, Data: Wrong Size, Type, Address, Size) tuple with an improper Data operand element (see the second state in Fig. 17) that results in an Overbound Pointer error. There is no bug in the Repositon operaton itself, but a value that is inconsistent with the size of the pl object is used to control the iteraton. The later is an instance of the BF Memory Use (MUS) class [1] as the (Read, Data, Type, Address: Overbound Pointer, Size) tuple with an improper Address operand element (see the third state in Fig. 17) that results in a Buffer Over-Read final error. Again, there is no bug in the Read operaton itself, but because pl points overbound, it is possible to read data that should not be read (i.e., buffer over-read). The three-state BF chain so far (see the upper row in Fig. 17) shows that data can be read from over the bound of the array pointed by pl. However, it does not show why an exploit would reach sensitve informaton, such as private keys or login credentals. The vulnerability triggered by the missing size verificaton bug is only a part (although the main one) of the puzzle. 32

NIST SP 800-231 July 2024

typedef struct ssl3_record_st { int type; /* type of record */ unsigned int length; /* How many bytes available */ unsigned int off; /* read/write offset into 'buf' */ unsigned char *data; /* pointer to the record data */ unsigned char *input; /* where the decode bytes are */ unsigned char *comp; /* only used with decompression - malloc()ed */ unsigned long epoch; /* epoch number, needed by DTLS1 */ unsigned char seq_num[8]; /* sequence number, needed by DTLS1 */ } SSL3_RECORD; 1448 dtls1_process_heartbeat(SSL *s) 1449 { 1450 unsigned char *p = &s->s3->rrec.data[0], *pl; 1451 unsigned short hbtype; 1452 unsigned int payload; 1453 unsigned int padding = 16; /* Use minimum padding */ 1454 1455 /* Read type and payload length first */ 1456 hbtype = *p++; 1457 n2s(p, payload); 1458 pl = p; ... 1465 if (hbtype == TLS1_HB_REQUEST) 1466 { 1467 unsigned char *buffer, *bp; ... 1470 /* Allocate memory for the response, size is 1 byte 1471 * message type, plus 2 bytes payload, plus 1472 * payload, plus padding 1473 */ 1474 buffer = OPENSSL_malloc(1 + 2 + payload + padding); 1475 bp = buffer; 1476 1477 /* Enter response type, length and copy payload */ 1478 *bp++ = TLS1_HB_RESPONSE; 1479 s2n(payload, bp); 1480 memcpy(bp, pl, payload);

/* Naive implementation of memcpy() void *memcpy (void *dst, const void *src, size_t n) { payload size_t i; for (i=0; i<n; i++) *(char *) dst++ = *(char *) src++; return dst; pl bp }

Fig. 18. C code of heartbeat() and naive memcpy() There must have been another coding error due to which an unused object with sensitve data was lef in memory unaware of the risks. The bug state of this parallel vulnerability is again an instance of the BF MUS class but as the (Clear: Missing Code, Data, Type, Address) tuple with an improper Clear operaton (see the second chain in Fig. 17) that results in a Not Cleared Object final error. Converging the final errors from both chains (i.e., buffer overread and not cleared object), the vulnerable sofware can now reach and expose sensitve informaton. 33

NIST SP 800-231 July 2024

The bug and fault state automata of Heartbleed (see Fig. 17) expresses it as two converging vulnerability chains of underlying weaknesses. Missing input data verificaton leads to the use of inconsistent size for a buffer and allows for a pointer repositon over its bound, which — converging with missing clear — allows for remote reads and the exposure of sensitve informaton. Multple exploits of Heartbleed, each exposing up to 64KB of memory, can accumulate huge amounts of data, such as “secret keys used for certficates, user names and passwords, instant messages, emails, and business-critcal documents and communicaton” [29]. The fix of the bug in the main Heartbleed chain was to add input data semantcs checks and silently ignore the heartbeat message if the requested length was larger than the actual array size (see Fig. 19) [30]. Lines 1468 and 1469 discard heartbeats with zero length. Lines 1472 and 1473 ensure that the actual length of the record data is sufficiently large.

Fig. 19. Heartbleed fix in Heartbeat For more details on the BF Vulnerability State Model, refer to the forthcoming SP 800-231D, Bugs Framework: Vulnerability Models.

34

NIST SP 800-231 July 2024

7.2. BF Vulnerability Specificaton Model The BF Vulnerability Specificaton Model defines a vulnerability specificaton as a chain of ⟨cause, operaton⟩→consequence relatons (i.e., weakness triples) with operaton and operand atributes and consequence↷cause between weaknesses propagaton (see Fig. 20). The model reflects the BF taxonomy structure (see Sec. 6) and the BF Vulnerability State Model (see Sec. 7.1). For simplicity, Fig. 20 does not visualize vulnerability convergence and chaining as Fig. 16 does. However, see Fig. 21 for a demonstratve example of vulnerability convergence. The BF allows for the expression of a weakness as a ⟨cause, operaton⟩→consequence causal triple with operaton and operand atributes. A cause is a bug in an operaton or a fault of an operand, and a consequence is the erroneous result from the operaton. Bugs are code or specificaton defects, and faults are input operand defects. The output errors from operatons propagate to faults or are final errors that introduce exploit vectors toward failures. A fault is of a name, data, type, address, or size. (see Sec. 3 and 4). Causaton within a weakness is by meaningful ⟨cause, operaton⟩→consequence relatons. That is, the sets of valid relatons defined for each BF taxonomy (see Sec. 6) restrict it. The bug or faulty input operand of an operaton results in an error or a final error as a valid ⟨bug, operaton⟩→error, ⟨fault, operaton⟩→error, ⟨bug, operaton⟩→final error, or ⟨fault, operaton⟩→final error weakness triple. For example, ⟨Under-Restrictve Policy, Validate⟩→Source Code Injecton and ⟨Mismatched Argument, Coerce⟩→Truncated Value are meaningful weakness triples, but ⟨Underbound Pointer, Write⟩→Buffer Overflow is not, as the pointer is below the lower bound while the Write is over the upper bound. Causaton between weaknesses is by error type to fault type match, and error value↷fault value match or — for weaknesses of different BF class types — a meaningful values propagaton (see Sec. 6). It is also guided by the valid flow of operatons defined by the BF Bugs Models. If the causaton between weaknesses does not follow the proper operaton flow, an operaton must be missing, which indicates an Missing Code bug. For example, ⟨Wrong Type, Coerce⟩→Flipped Sign ↷⟨Wrong Argument, Evaluate⟩→Under Range is a valid weakness causaton because the triples specify valid within-weakness relatons, the Evaluate operaton may follow the Coerce operaton (see Fig. 10), and Flipped Sign↷Wrong Argument is a valid data error-to-fault by value propagaton. The ⟨Erroneous Code, Verify⟩→Inconsistent Value↷⟨Wrong Size, Repositon⟩→Overbound Pointer↷⟨Overbound Pointer, Write⟩→Buffer Overflow are valid weakness causatons, as the data and address by type, Inconsistent Value↷Wrong Size by value, and Overbound Pointer exact value propagaton are all valid. For a similar one-chain example, recall the BadAlloc patern from Sec. 3.3, Fig. 5 and see the BF CVE-2021-21834 specificaton at [1]). For a convergence involving example, see the BF specificaton of Heartbleed below.

35

NIST SP 800-231 July 2024

Causaton between vulnerabilites is by exploit result type↷fault type propagaton (i.e., the fault starts a new faults-only vulnerability). For example, exposed private keys may become the fault that starts a new vulnerability. BF Security Vulnerability Specifica�on Model Bug Type

Error Type 1

Buggy Opera�on

Weakness Type 1

Opera�on 1 Operand 11 , ... Operand 1i , ...

Bug

Weakness 1 Mechanism Value 1m

Source Code Value 1c

Execu�on Space Value 1e

(Bug, Opera�on1, Error1) ← lookup_rela�on() (Opera�on1, Opera�on2) ← lookup_flow()

Error 1

Operand 11 Kind Value 11s Operand 11 State Value 11k

…

Operand 15 Kind Value 15s Operand 15 State Value 15k

Fault1.Type ← Error1.Type (Fault1, Error1) ← lookup_propaga�on()

Weakness Type 2

Opera�on with Faulty Operand

Fault Type 1 Fault 1

Weakness 2

Source Code Value 2c

Mechanism Value 2m

Execu�on Space Value 2e

(Fault1, Opera�on2, Error2) ← lookup_rela�on() (Opera�on2, Opera�on3) ← lookup_flow()

Error 2

Operand 21 Kind Value 21s … Operand 21 State Value 21k

Operand 25 Kind Value 25s Operand 25 State Value 25k

Fault2.Type ← Error2.Type (Fault2, Error2) ← lookup_propaga�on()

…

Weakness TypeN

Error Type 2

Opera�on 2 Operand 21 , …, Operand 2j , ...

Fault Type N-1

Opera�on N Operand N1 , …, Operand NP , ...

Fault N-1

Weakness N Mechanism Value Nm

Final Error Type

Opera�on with Faulty Operand

Source Code Value Nc

Execu�on Space Value Ne

Final Error

Operand N1 Kind Value N1s … Operand N1 State Value N1k

Operand N5 Kind Value N5s Operand N5 State Value N5k

(Faultn-1, Opera�onn, Final Error) ← lookup_rela�on() (Final Error, Exploit1) ← lookup_flow() …

(Final Error, ExploitF) ← lookup_flow()

Failure Type 1 Failure 1 Exploit 1 Vector 1

…

Exploit F Vector F BF, I. Bojanova

Bug Type – Code or Specifica�on Fault/Error Type – Data, Name, Type, Address, or Size

→ Causa�on within weaknesses– by valid (<cause, operation> → consequence) rela�ons ↷ Causa�on between weaknesses– guided by flow of opera�ons Propaga�on between weaknesses – by same error type to fault type and by valid by name transi�on

Bug

Failure TypeF Failure F

Opera�on

Fault / Error

Final Error

Failure

Fig. 20. BF Vulnerability Specificaton Model 36

NIST SP 800-231 July 2024

For example, the BF specificaton view of Heartbleed, CVE-2014-0160, is presented in Fig. 21. It expands the Heartbleed improper states view (see Fig. 17) via the BF taxonomic representaton of a weakness as a ⟨cause, operaton⟩→consequence triple with atributes and its consequence↷cause propagaton. BF Specifica�on of CVE -2014-0160 – Heartbleed in OpenSSL v1.0.1 before v1.0.1g Data Error

_INP Weakness

Code Defect Bug

Data Verifica�on (DVR)

Missing Code

Verify

Inconsistent Value

in 'dtls1_process_heartbeat(SSL *s)

length

'payload'

_MEM Weakness Memory Addressing (MAD)

Opera�on

Mechanism Range

Source Code Third-Party

1 + 2 + 16 <= s ->s3->rrec.length 1 + 2 + payload + 16 <= s->s3->rrec.length

ssl /d1_both.c: 1462 ssl /t1_lib.c: 2591

Data Fault

Execu�on Space Local

via network

Opera�on Wrong Size

Reposi�on

in 'memcpy(bp, pl, payload)'

pointer

Source Code Third-Party

Mechanism Sequen�al

Address Error Over Bound Pointer 'pl'

Address State Heap

Execu�on Space Userland

Size Kind Used

ssl /d1_both.c:1487 ssl /t1_lib.c:2620

_MEM Weakness Memory Use (MUS)

for s→s3→rrec.data[0]

Opera�on

Memory Corrup�on/Disclosure Final Error

Over Bound Pointer

Read

Buffer Over-Read

in 'memcpy(bp, pl, payload)'

object

'pl'

Address Fault

Mechanism Sequen�al

Source Code Third-Party

Memory Use (MUS)

Memory Corrup�on/Disclosure Final Error

Opera�on Clear

Missing Code

Not Cleared Object

object

Source Code Codebase

Size Kind Used

up to 64kb per exploit

Code Defect Bug

Mechanism Sequen�al

Address State Heap

Address Kind Huge

Execu�on Space Userland

ssl /d1_both.c:1487 ssl /t1_lib.c:2620

_MEM Weakness

Data State Transferred

Execu�on Space Userland

Address Kind Huge

Address State Heap

Size Kind Actual

up to 64kb per exploit

Bug

Opera�on

Fault / Error

Final Error

Failure

Fig. 21. BF specificaton of Heartbleed Using the BF taxonomies of the involved weakness types, the ⟨Missing Code, Verify⟩→ Inconsistent Value weakness (see the first triple in the first chain in Fig. 21) is an instance of the BF DVR class. The missing input data verificaton (i.e., semantcs check) security bug leads to a Data Error — a data value that is inconsistent with the size of the array.

37

Failure

IEX BF Tool, I. Bojanova

NIST SP 800-231 July 2024

The operaton and operand atributes provide details on what, how, and where it went wrong. The Mechanism, Source Code, and Executon Space atributes are about the Verify operaton. Mechanism shows that the missing verificaton should have been checked against range (i.e., the actual length). Source Code shows that the bug is in third-party sofware — the d1 both.c and t1 lib.c files. Executon Space shows that the code with the bug is running in an environment with local user (i.e., limited) permissions. The Data State atribute is about the Data operand and shows that the data was transferred. Next, the ⟨Wrong Size, Repositon⟩→Overbound Pointer weakness (see the second triple in the first chain in Fig. 21) is an instance of the BF MAD class. The wrong size Data Fault at repositoning leads to a pointer pointng overbound (i.e., an address error). The Mechanism atribute for this weakness shows that the repositoning is sequental and iterates over the buffer elements. The Executon Space is userland — an environment with privilege levels but in unprivileged mode. The Address State atribute shows that the buffer is dynamically allocated in the heap. The Size Kind atribute shows that the iteraton over the elements of the buffer is limited by a used value (supplied with the request); it is not limited by the actual size of the array. Last in this chain, the ⟨Overbound Pointer, Read⟩→Buffer Over-Read weakness (see the third triple in the first chain in Fig. 21) is an instance of the BF MUS class. The overbound pointer Address Fault results in a buffer over-read Memory Disclosure Final Error. The Address Kind atribute shows that the accessed out-of-bounds memory is huge — up to 64KB of memory per request. The converging vulnerability (see the second chain in Fig. 21) chain comprises another BF MUS instance — a ⟨Missing Code, Clear⟩→Not Cleared Object weakness. The missing clear (change to a non-meaningful value, such as via zeroizaton) bug leads to an object with not cleared data — a memory disclosure final error. The atributes are the same as for the BF MUS weakness in the main vulnerability (see Chain 1 in Fig. 21). However, this is a different vulnerability, and the source code is in different sofware. Combined, the memory disclosure final errors Buffer Over-Read and Not Cleared Object cause an informaton exposure (IEX) security failure. Either the missing Verify bug or the missing Clear bug has to be fixed to avoid this security failure. The corresponding BF specificaton of Heartbleed — CVE-2014-0160.bfcve — in XML format is shown in Fig. 26. For more details, see BF CVE-2014-0160 Heartbleed at [1]. For more details on the BF Vulnerability Specificaton Model, refer to the forthcoming SP 800-231D, Bugs Framework: Vulnerability Models.

38

NIST SP 800-231 July 2024

8. BF Formal Language The BF formal language is generated by the BF lef-to-right lefmost derivaton one-symbol lookahead (LL(1)) atribute context-free grammar (ACFG) derived from the BF CFG. Since it is based on an LL(1) grammar, the BF formal language is guaranteed to be unambiguous, and the BF weakness and vulnerability specificatons are guaranteed to be clear and precise.2 The BF lexis, syntax, and semantcs are based on the BF structured causal taxonomies (e.g., Fig. 12), bugs models (e.g., Fig. 9), and vulnerability models (e.g., Fig. 16 and 20). Lexis refers to the vocabulary (i.e., words and symbols) used by a specificaton language. Syntax is about validatng the grammatcal structure (i.e., the form) of a specificaton. Semantcs is about verifying the logical structure (i.e., the meaning) of a specificaton. The BF CFG is a powerful tool for specifying and analyzing security weaknesses and vulnerabilites. It is defined in Listng 1 as a four-tuple G = (V, Σ, R, S),

(1)

where: • Σ defines the BF lexis (i.e., the alphabet of the CFG) as a finite set of tokens (terminals) comprised by the sets of BF taxons and BF symbols  Σ = α | α ∈ ΣTaxon ∪ ΣSymbol • V and R define the BF syntax (i.e., the types of phrases and the rules of the CFG) as ◦ A finite set of variables (nonterminals)  V = S,V1 , . . . ,Vn and ◦ A finite set of syntactc rules (productons) in the form  �
∗ R = A 7−→ ω | A ∈ V ∧ ω ∈ V ∪ Σ , where: �
∗ V ∪ Σ is a string of tokens and/or variables, and A 7−→ ω means that any variable A occurrence may be replaced by ω. • S ∈ V is the predefined start variable from which all BF specificatons derive.

2 Clear means easy to understand, straightorward, and unambiguous with no room for confusion or misin-

terpretaton. Precise means exact, accurate, and specific, which also implies unambiguous.

39

NIST SP 800-231 July 2024

A BF specificaton starts from S and ends with the empty string. The derivaton is via a sequence of steps in which nonterminals are replaced by the right-hand side of a producton. The producton rules are applied to a variable regardless of its context. The BF formal language is generated by the BF LL(1) ACFG G = (V, Σ, R, S) (see Listng 8) that augments the syntax of the BF CFG with semantc rules (see Listng 7). It is defined in Listng 2 as the set L(G) of all strings of tokens ω derivable from the start variable S. ∗

L(G) = {ω ∈ Σ∗ : S=⇒ω},

(2)

where: • Σ∗ is the set of all possible strings that can be generated from Σ tokens • S is the start variable ∗

• α =⇒ β means string α derives string β . Strings involving nonterminals are not part of the language (i.e., ω must be in Σ∗ — the set of strings made from terminals). 8.1. BF Lexis The BF formal language lexis refers to the vocabulary of the BF formal language: the set of tokens Σ. Listng 3 defines it as the set of BF taxons (see Sec. 6) and the set of symbols for converging and chaining vulnerabilites (see Fig. 16):

 Σ = ΣTaxon, ΣSymbol

(3)

 ΣTaxon = Operation, BugType, Bug, FaultType, Fault, ErrorType, Error, FinalErrorType, FinalError, OperationAttribute, OperandAttribute, . . .  ΣSymbol = CausationSymbol,ChainingSymbol,ConvergingSymbol, SemicolonSymbol,CommaSymbol, Le f tAngleSymbol, RightAngleSymbol The BF CFG lexis defines the BF taxons (e.g., for BF operatons, bugs, faults, final errors, operaton atributes, operand atributes, and failures). It also defines the set of BF symbols for specifying causaton within a weakness (→), chaining weaknesses or vulnerabilites (↷), and converging vulnerabilites (⊕). The taxons are in quotes (e.g., ‘Missing Code’ or ‘Query Injecton’) and considered literal words. The BF classes are of a ‘Weakness’ or ‘Failure’ category. Listng 4 provides an excerpt of the BF lexis expressed via the Extended Backus–Naur Form (EBNF) [31] using the following meta-notatons: 40

NIST SP 800-231 July 2024

Symbol = | ;

Meaning defining definiton separator terminator Category = ′Weakness′ | ′ Failure′ ; ClassType = ′ INP′ | ′ MEM ′ | ′ DAT ′ | . . .

Class = ′ DV L′ | ′ DV R′ | ′ MAD′ | ′ MMN ′ | ′ MUS′ | ′ DCL′ | ′ NRS′ | ′ TCV ′ | ′ TCM ′ | . . . ; Operation = ′Validate′ | ′ Sanitize′ | ′Veri f y′ | ′Correct ′ | ′ Initialize Pointer′ | ′ Dere f erence′ | ′ Reposition′ | ′ Reassign′ | ′ Allocate′ | ′ Extend ′ | ′ Reallocate − Extend ′ | ′ Reallocate − Reduce′ | ′ Reduce′ | ′ Deallocate′ | ′ Initialize Ob ject ′ | ′ Read ′ | ′W rite′ | ′Clear′ | ′ Declare′ | ′ De f ine′ | ′ Re f er′ | ′Call ′ | ′Cast ′ | ′Coerce′ | ′Calculate′ | ′ Evaluate′ . . . ; BugType = ′Code Bug′ | ′ Speci f ication Bug′ ; Bug = ′ Missing Code′ | ′ Erroneous Code′ | ′ Mismatched Operation′ | . . . | ′Under − Restrictive Policy′ | ′ Over − Restrictive Policy′ | ′ Missing Modi f ier′ | ′W rong Modi f ier′ | ′ AnonymousScope′ | ′W rongScope′ | ′ Missing Quali f ier′ | ′W rong Quali f ier′ | . . . ; FaultType = ′ Name Fault ′ | ′ Data Fault ′ | ′ Type Fault ′ | ′ Address Fault ′ ; Fault = ′ Missing Overridden Function′ | ′ Missing Overloaded Function′ | ′W rong Ob ject Resolved ′ | ′W rong Function Resolved ′ | . . . ; | ′Corrupted Data′ | ′ Tampered Data′ | ′Corrupted Policy Data′ | ′ Tampered Policy Data′ | ′ Invalid Data′ | ′ NULL Pointer′ | ′ Hardcoded Address′ | ′ Single Owned Address′ | ′W rong Index′ | ′W rong Size′ | ′ Flipped Sign′ | ′W rong Argument ′ | ′ Re f erence vs. Dere f erence′ | . . . | ′Cast Pointer′ | ′W rong Type′ | ′W rong Index Type′ | ′ Insu f f icient Size′ | ′ Downcast Pointer′ | ′W rong Argument Type′ | ′W rong Ob ject Type Resolved ′ | . . . | ′W ild Pointer′ | ′ Dangling Pointer′ | ′U ntrusted Pointer′ | ′ Overbound Pointer′ | ′Underbound Pointer′ | ′W rong Position Pointer′ | . . .

41

(4)

NIST SP 800-231 July 2024

ErrorType = ′ Name Error′ | ′ Data Error′ | ′ Type Error′ | ′ Address Error′ ; FinalErrorType = ′ In jection FinalError′ | ′ Memory Corruption/Disclosure FinalError′ | ′

Entity Access FinalError′

FinalError = ′ Query In jection′ | ′Command In jection′ | ′ Source Code In jection′ | . . . ; | ′ NULL Pointer Dere f erence′ | ′U ntrusted Pointer Dere f erence′ | ′U ninitialized Pointer Dere f erence′ | ′ Memory Leak′ | ′ Memory Over f low′ | ′ Double Deallocate′ | ′ Ob ject Corruption′ | ′ Not Cleared Ob ject ′ | ′ Type Con f usion′ | ′Use A f ter Deallocate′ | ′ Bu f f er Over f low′ | ′ Bu f f er Under f low′ | ′ Bu f f er Over − Read ′ | ′ Bu f f er Under − Read ′ | ′ Subtype Con f usion′ | ′U nde f ined ′ | . . . ; ... CausationSymbol = ′ →′ ;

SemicolonSymbol = ′ :′ ;

Le f tAngleSymbol = ′ ⟨′ ;

ChainingSymbol = ′ ↷′ ;

CommaSymbol = ′ ,′ ;

RightAngleSymbol = ′ ⟩′

ConvergingSymbol = ′ ⊕′ ; ;

8.2. BF Syntax The BF formal language syntax is about validatng the grammatcal structure of a BF specificaton. It adheres to the BF producton rules (i.e., nonterminals) for constructng (producing) valid specificatons of the language that correspond to the BF Vulnerability Specificaton Model structure and flow (see Fig. 20), including the converging and chaining rules (see Fig. 16) defined by the BF Vulnerability State Model. The BF CFG syntax defines a vulnerability that possibly converges with other vulnerabilites, leading to one or more failures. The CFG producton rules are expressed via the EBNF using the following meta-notatons: Symbol(s) = | [ ] {} () ;

Meaning defining definiton separator opton — zero or one occurrences repetton — zero or more occurrences grouping terminator (5)

42

NIST SP 800-231 July 2024

S = Vul nerability, ′ ↷′ , Failure; Vulnerability = WeaknessChain, {′ ⊕′ , WeaknessChain}; WeaknessChain = Weakness, {′ ↷′ , Weakness}; Weakness = ′ ⟨′ , Cause, ′ ,′ , Operation, ′ ⟩′ , ′ →′ , Consequence; Cause = Bug | Fault; Consequence = Error | FinalError; Error = Fault;

A vulnerability is defined as a chain of weaknesses, possibly converged and chained with other vulnerabilites. A weakness is defined as a ⟨cause, operaton⟩→ consequence triple. A cause is defined as a bug or a fault. A consequence is defined as an error or a final error (see Listng 5). However, according to the BF Vulnerability Specificaton Model (see Fig. 20), only the cause of the first weakness can be a bug, and only the last consequence can be a final error. The last producton in Listng 5 expresses that the same set of taxons corresponds to Fault and Error, although they are different non-terminals — the former is a cause of a weakness, the later is a consequence of a weakness. An Error ↷ Fault propagaton may be on a different level of abstracton (e.g., Inconsistent Value ↷ Wrong Size). A vulnerability with a single weakness is the only case in which a weakness is defined with both a bug cause and a final error consequence. A propagaton weakness is caused by a fault and results in an error. Listng 6 reflects these rules in the productons of Listng 5 and eliminates the Cause and Consequence variables. (6) S = Vulnerability, ′ ↷′ , Failure; Vulnerability = WeaknessChain, {′ ⊕′ , WeaknessChain}; WeaknessChain = SingleWeakness | FirstWeakness, {′ ↷′ , Weakness}, ′ ↷′ , LastWeakness; SingleWeakness = ′ ⟨′ , (Bug | Fault), ′ ,′ , Operation, ′ ⟩′ , ′ →′ , FinalError; FirstWeakness = ′ ⟨′ , Bug | Fault ), ′ ,′ , Operation, ′ ⟩′ , ′ →′ , Error; Weakness = ′ ⟨′ , Fault , ′ ,′ , Operation, ′ ⟩′ , ′ →′ , Error; LastWeakness = ′ ⟨′ , Fault, ′ ,′ , Operation, ′ ⟩′ , ′ →′ , FinalError;

To ensure that the BF specificatons are unambiguous, the next step is to demonstrate the successful derivaton of a BF LL(1)3 formal grammar from the BF CFG. A CFG is an LL(1) 3 The most restrictve LL(1) is chosen for the simplicity and efficiency of parser implementatons.

43

NIST SP 800-231 July 2024

grammar if and only if only one token (terminal) or variable (nonterminal) is needed to make a parsing decision [32]. LL(1) grammars are not ambiguous and not lef-recursive. The BF LL(1) formal CFG is derived from the BF EBNF productons on Listng 6 via lef factorizaton and lef recursion eliminaton. It is suitable for recursive descent parsing, as the start of each producton opton is unique. The rule to choose on each step is uniquely determined by the current variable and the next taxon (if there is one). Listng 7 defines the BF LL(1) CFG producton rules for constructng valid, unambiguous BF specificatons. Compared to Listng 6, it also details the bug, fault, error, and final error type non-terminals. (7) S = Vulnerability, Converge Failure; Vulnerability = ′ ⟨′ , Bug Fault, ′ ,′ , Operation, ′ ⟩′ , ′ →′ , OperAttrs Error FError; Bug Fault = BugType, ′ :′ , Bug | T Fault; OperAttrs Error FError = OperationAttribute, OperAttrs Error FError | ErrorType, ′ :′ , Error, ′ ↷′ , ′ ′

⟨ , T Fault, ′ ,′ , OprndAttrs Operation

| FinalErrorType, ′ :′ , FinalError; OprndAttrs Operation = OperandAttribute, OprndAttrs Operation | Operation, ′ ⟩′ , ′ →′ , OperAttrs Error FError; Converge Failure = ′ ⊕′ , Vulnerability, Converge Failure | →′ , Failure; T Fault = FaultType, ′ :′ , Fault;

The BF specificatons are derived from the start symbol S by step-by-step producton applicaton, substtutng for the lefmost terminal one at a tme untl the string is fully expanded (i.e., consists of only terminals). 8.3. BF Semantcs The BF formal language semantcs is about verifying the logical structure of a BF specificaton. It is defined by extending the BF LL(1) CFG to a BF LL(1) ACFG with statc semantc rules that adhere to the BF Vulnerability Models causaton and propagaton rules (see Fig. 16 and 20). The statc semantc rules are expressed via a set of grammar atributes (i.e., propertes to which values can be assigned), a set of semantc functons for computng the atribute values, and a possibly empty set of predicate functons for each producton rule (e.g., Donald Knuth’s atribute grammars [33]). 44

NIST SP 800-231 July 2024

Listng 8 presents the BF LL(1) ACFG syntax and semantc rules. If a nonterminal appears in more than one rule, it gets subscripted. The semantc rules prevent invalid within weaknesses relatons and error↷fault by value between weaknesses propagaton and check for valid flow by operaton. The BF LL(1) ACFG adds the Type synthesized atribute for the nonterminals Fault and Error to store the operand types (i.e., Name, Data, Type, Address, or Size) and FinalError to store the final error types (e.g., Injecton, Memory Corrupton/Disclosure, Access, and Type Compute). The predicates express propagaton by error type and fault type. (8) Syntax Rules: S = Vulnerability, Converge Failure; Vulnerability = ′ ⟨′ , Bug Fault, ′ ,′ , Operation1 , ′ ⟩′ , ′ →′ , OperAttrs Error FError; Bug Fault = BugType, ′ :′ , Bug | FaultTy pe, ′ :′ , Fault; OperAttrs Error FError = OperationAttribute, OperAttrs Error FError | ErrorType, ′ :′ , Error, ′ ↷′ , ′ ′

⟨ , FaultType, ′ :′ , Fault1 , ′ ,′ , OprndAttrs Operation

| FinalErrorType, ′ :′ , FinalError; OprndAttrs Operation = OperandAttribute, OprndAttrs Operation | Operationk , ′ ⟩′ , ′ →′ , OperAttrs Error FError; Converge Failure = ′ ⊕′ , Vulnerability, Converge Failure | Failure; T Fault = FaultType, ′ :′ , Fault; Semantc Rules: �
Bug, Operation1 , Error ← lookup relation() �
Bug, Operation1 , FinalError ← lookup relation() �
Fault1 , Operationk , Error , k > 1 ← lookup relation() �
Fault1 , Operationk , FinalError , k > 1 ← lookup relation() (Operation1 , . . . , Operationk ), k > 1 ← lookup f low() Fault1 ← i f (Fault1 .ClassType == Error.ClassType) then Error else (Fault1 , Error) ← lookup propagation() Predicates: Fault1 .Type == Error.Type ExploitVector.Type == FinalError.Type

45

NIST SP 800-231 July 2024

For example, listng 9 expresses the formal BF specificaton of CVE-2014-0160 Heartbleed. (9) BF INP DV R ⟨Code Bug : Missing Code, Veri f y⟩ → Data Error : Inconsistent Value Mechanism : Range, Source Code : T hird − Party, Execution Space : Local Data State : Trans f erred ↷ BF MEM MAD ⟨Data Fault : W rong Size, Reposition⟩ → Address Error : Over Bound Pointer Mechanism : Sequential, Source Code : T hird − Party, Execution Space : Userland Address State : Heap, Size Kind : Used ↷ BF MEM MUS ⟨Address Fault : Over Bound Pointer, Read⟩ → Memory Corruption/Disclosure Final Error : Bu f f er Over − Read Mechanism : Sequential, Source Code : T hird − Party, Execution Space : Userland Size Kind : Used, Address Kind : Huge, Address State : Heap ⊕ BF MEM MUS ⟨Code Bug : Missing Code, Clear⟩ → Memory Corruption/Disclosure Final Error : Not Cleared Ob ject Mechanism : Sequential, Source Code : T hird − Party, Execution Space : Userland Address Kind : Huge, Address State : Heap, Size Kind : Actual ↷ IEX

For the fully expressed BF lexis, syntax, and semantcs in EBNF, refer to the forthcoming SP 800-231E, Bugs Framework: Formal Language.

46

NIST SP 800-231 July 2024

9.

BF Secure Coding Principles

The Software Engineering Institute (SEI) Computer Emergency Response Team (CERT) Coding Standards (e.g., [34] and [35]) and the Open Worldwide Application Security Project (OWASP) Secure Coding Practices [36] set the current state of the art in secure coding. They provide rules and practices that are grouped by topic and described in natural language. The CERT rules are also programming language-specific, though they do provide useful non-compliant code examples and compliant solutions. In contrast, the BF bugs models, weakness and failure taxonomies, and vulnerability models (see Sec. 5, 6, and 7) form the basis for the formal definition of secure coding principles by software, firmware, or hardware execution phases, that are also programming language-independent. For example, the BF Input/Output Check Bugs Model (see Fig. 8) and classes (see BF INP at [1]) address input/output check safety (e.g., no SQL injections or use of wrong input values). The BF Memory Bugs Model (see Fig. 9) and classes (see BF MEM at [1]) address memory safety (e.g., no use after frees or buffer overflows). The BF Data Type Bugs Model (see Fig. 10) and classes (see BF DAT at [1]) address data type safety (e.g., no integer overflows or subtype confusions). The BF Vulnerability Models rules (see Sec. 7), which are reflected in the BF semantics, help identify the dependencies between different kinds of code safety. The BF bugs models define the sets of operations where code safety could break. They also define the proper operation flow within and between execution phases that — if not followed — could also break code safety. The x-axis of a model reflects temporal safety. The y-axis of a model may reflect spatial safety. The BF weakness taxonomies are organized by the bugs models phases and define why (i.e., bugs and faults), where (i.e., operations), and how (i.e., errors and final errors) the code safety could break. The BF vulnerability models define the causation, propagation, and convergence rules, which in addition to the proper operation flow, define how breaking one kind of code safety may lead to breaking another. 9.1.

Input/Output Check Safety

Input/output check safety ensures the use of proper input/output data in code. That is, data is properly validated and sanitized and/or verified and corrected. It is addressed by the BF Input/Output Check Bugs Model (see Fig. 8) operation flow and the BF DVL and DVR classes (see BF INP at [1]) that define why, where, and how input/output check safety could break. It relates to the BF data operations Validate, Sanitize, Verify, and Correct. Input/output data must be validated (syntax check) and then sanitized (escaped, filtered, or repaired) and/or verified (semantics check) and then corrected (assigned a new value or removed), if needed. Avoiding the meaningful ⟨bug/fault, operation⟩ couples of the BF INP classes would guarantee input/output check safety. That is, avoiding the BF DVL bugs (i.e., missing or erroneous validation, or under-restrictive or over-restrictive validation policy) and faults (i.e., 47

NIST SP 800-231 July 2024

corrupted or tampered data or validaton policy) guarantees safety from errors, such as Invalid Data and final errors, such as Query Injecton (e.g., SQL injecton) and Source Code Injecton (e.g., Cross Site Scriptng (XSS)). Injectons enable the following security failures: IEX, TPR, ACE, and its sub-case RCE. Avoiding the BF DVR bugs (i.e., missing or erroneous verificaton or under-restrictve or over-restrictve verificaton) and faults (i.e., invalid data) guarantees safety from errors, such as Wrong Value, Inconsistent Value, and Wrong Type. 9.2. Memory Safety Memory safety ensures the proper access and use of memory in code. That is, pointers to objects are properly initalized, dereferenced, repositoned, or reassigned, and objects are properly allocated, initalized, read, writen, resized, cleared, or deallocated. It is addressed by the BF Memory Bugs Model (see Fig. 9) operaton flow and the BF MAD, MMN, and MUS classes (see BF MEM at [1]) that define why, where, and how memory safety could break. Memory safety has both temporal and spatal aspects that depend on pointer safety. Temporal memory safety ensures that an object memory is only accessed or used during its life cycle and only via its proper pointers (owners). Access is via BF MAD Dereference of a pointer to the object; use is via BF MUS Read or Write of object data. The first operaton over an allocated object must be BF MUS Initalize Object, and the last one before it is deallocated must be BF MUS Clear (see Fig. 9). Examples of temporal memory safety are uninitalized object, use afer deallocate (i.e., use afer free or use afer return in C), and double deallocate (i.e., double free in C) safety. The first prevents the use of non-meaningful data values, the second prevents the use of data values via dangling pointers, and the third prevents the deallocaton of deallocated objects via dangling pointers. The following BF weakness specificatons detail what bugs or faults could break these three kinds of temporal memory safety: ⟨Missing Code/Erroneous Code, Initalize Object⟩→Uninitalized Object, ⟨Dangling Pointer, Read⟩→Use Afer Deallocate, and ⟨Dangling Pointer, Deallocate⟩→Double Deallocate. A dangling pointer holds the address of its successfully deallocated object (i.e., a pointer to a freed heap object or address of a stack object returned by a functon) and is the consequence of a ⟨Missing Code, Reassign⟩→Dangling Pointer (see the discussion on pointer safety below) afer a Deallocate operaton. Spatal memory safety ensures access or use within the bounds of an allocated object and only via its pointers (owners). In additon to the MAD Dereference and MUS Read and Write operatons, it also relates to the MAD and MDL operatons along the y-axis of the MEM Bugs Model (see Fig. 9) that affect the object boundaries: Allocate, Extend, ReallocateExtend, Reduce, and Reallocate-Reduce. The size of the object is always strictly defined, and the pointer must not exceed its boundaries.

48

NIST SP 800-231 July 2024

Examples of spatal memory safety are buffer overflow and underflow safety, and buffer over-read and under-read safety. The following BF weakness specificatons detail what bugs or faults could break these two kinds of spatal memory safety: ⟨Overbound Pointer, Write⟩→Buffer Overflow and ⟨Underbound Pointer, Read⟩→Buffer Under-Read. For consideraton, there are also the fault weaknesses that may cause them, such as ⟨Wrong Size, Allocate/Reduce⟩→ Insufficient Size, ⟨Wrong Size, Repositon⟩→Underbound Pointer, and ⟨Insufficient Size, Repositon⟩→Overbound Pointer, which in turn are caused by the declaraton of verificaton bug weaknesses. Buffer overflows and underflows enable TPR, DOS, and ACE failures. Buffer over-reads and under-reads enable IEX failures. Allocaton in excess or failure to deallocate unused objects (see the MMN Memory Overflow and Memory Leak final errors, correspondingly) could exhaust memory. The former impacts spatal memory safety. The later directly impacts temporal safety and indirectly impacts spatal memory safety. Both enable DOS failures. Pointer Safety ensures that an object is only accessed via its proper pointers (owners). It relates to the MAD, MAL, and MDL operatons (see Fig. 9) that assign or reassign the object pointer (owner): Initalize Pointer, Allocate, and Reassign. Use of Wild Pointer, Untrusted Pointer, Cast Pointer, or Forbidden Address (including Null Pointer) would break pointer safety and lead to final errors such as Object Corrupton, Memory Leak, Type Confusion, and NULL Pointer Dereference, respectvely. Subsequently, bugs and faults covered by any non- MEM classes, whose operatons produce such pointers, should also be avoided. According to the proper memory-related operaton flow (see Fig. 9), a pointer may be initalized before or afer the allocaton of its object. However, it must be initalized before it is used to address its object, repositoned afer the reallocaton of its object, and reassigned afer the deallocaton of its object. These correspond to the MAD Wild Pointer and Dangling Pointer errors. If an object is reallocated because of being extended or reduced, all of its owners must be repositoned. An object must not be read before it is initalized (i.e., the first write) and must be cleared (i.e., the last write) before it is deallocated. An unneeded object must be cleared and deallocated, and all of its pointers (owners) must be reassigned. It should not be possible to access and use its data afer it is deallocated. These correspond to the BF MUS Uninitalized Object error and Not Cleared Object, Memory Leak, and Use Afer Deallocate (i.e., use afer free or use afer return) final errors. Memory leaks enable IEX and DOS failures. The use of deallocated objects enables IEX, TPR, DOS, and ACE failures. Temporal memory safety may depend on input data safety. For example, verificaton of an input size toward the actual size of a buffer before Read or Write will eliminate related buffer overflows. Spatal memory safety may depend on data type safety. For example, avoiding Cast-related data errors that may lead to the use of an incorrect element size and Repositon overbound or underbound will eliminate related buffer overflows.

49

NIST SP 800-231 July 2024

Avoiding the meaningful ⟨bug/fault, operaton⟩ couples of the BF MEM classes would guarantee temporal and spatal memory safety, as well as general pointer safety. Avoiding erroneous pointer arithmetcs will also eliminate related buffer overflows. For example, proper type declaraton would avoid type coercion at argument passing to functons that calculate the size of a buffer and result in flipped signs and wrap-around (e.g., integer overflows), rounded (i.e., breaking floatng point safety), or truncated values. 9.3. Data Type Safety Data type safety ensures the proper use of enttes (e.g., objects, functons, and data types) in code. That is, objects, functons, and data types are properly declared, defined, and referenced; objects are properly typecast or coerced; and functons are correctly called to perform error-free type-related computatons. It is addressed by the BF Data Type Bugs Model (see Fig. 10) operaton flow and the BF DCL, NRS, TCM, and TCV classes (see BF DAT at [1]) that define why, where, and how data type safety could break. Data type safety has both temporal and spatal aspects. Temporal data type safety ensures the use of data values that are compatble and data types that are non-confused with the declared data type of an object. Enttes must not only be declared but also defined and their names properly resolved and bound. Compute and evaluate functons must also be defined with the appropriate argument data types. Temporal data type safety is mostly covered by the type system of the programming language. However, DCL bugs that cause errors (e.g., Missing Overloaded Functon) or propagate to faults (e.g., Wrong Argument Type) could stll break data type safety. Spatal data type safety ensures proper object type conversions and use of its layout. It is addressed by the operatons that affect the interpretaton of the object layout or the elements’ size along the y-axis of the DAT Bugs Model (see Fig. 10): TCV Cast and Coerse. Examples of spatal data type safety are cast pointer safety, coerced object safety, and subtype safety. The first prevents a pointer and its object from having incompatble data types. A declared overloaded functon must have implementatons for all of the needed argument types. Otherwise, Coerce will be forced on the argument values. The last example prevents a pointer and its object from having confused data types. A cast pointer can cause different element size interpretatons and overall object size that may lead to buffer overflows. A wrong argument type coercion can result in truncated or rounded data values. Downcastng a pointer to a sibling class can cause Subtype Confusion and enable an ACE or RCE (of functons of the sibling class) failure. Data type safety may depend on input data safety. For example, verificaton of the target data type toward the object (source) data type before the Cast of an object pointer will eliminate related Cast Pointer errors and Type Confusion final errors. Avoiding the meaningful ⟨bug/fault, operaton⟩ couples of the BF DAT classes would guarantee temporal and spatal data type safety. 50

NIST SP 800-231 July 2024

The methodology for the definiton of secure coding principles by sofware, firmware, or hardware executon phases involves the following seven steps (also see Fig. 22): 1. BF Bugs Model: Identfy the BF Bugs Model that corresponds to the executon phases for which secure coding principles are to be defined. 2. Temporal and Spatal Operatons: Determine the operatons along the x-axis of the Bugs Model that relate to the temporal safety for the BF class type. If a y-axis exists, determine which operatons relate to its spatal safety for the BF class type. 3. Operatons Flow Rules: Formally describe the proper operatons flow according to the semantc graphs of the BF Bugs Model. 4. BF Class Type: Identfy the BF Class Type that corresponds to the BF Bugs Model and the semantc matrices for each of its BF classes. 5. Spatal Safety Rules: Formally describe what (i.e., bugs or faults) how (i.e., errors and final errors) could break the code safety via spatal operatons according to the within weakness causaton semantc rules of the BF classes. 6. Temporal Safety Rules: Formally describe what (i.e., bugs or faults) and how (i.e., errors and final errors) could break the code safety via temporal operatons according to the within weakness causaton semantc rules of the BF classes. 7. Dependency Rules: Identfy code safety dependencies according to the BF between weaknesses causaton and propagaton semantc rules. BF Secure Coding Principles Methodology 1. BF Bugs Model

4. BF Class Type BF Class

2. Temporal Safety Opera�ons Spa�al Safety Opera�ons

3. BF Seman�c Graph

Seman�c Matrix

Opera�ons Flow Rules

5. Spa�al Safety Rules

6. Temporal Safety Rules

7. Dependency Rules BF, I. Bojanova

Fig. 22. BF secure coding principles methodology While the BF formal language is descriptve, the secure coding principles are prescriptve against bugs and faults per operaton that break specific kinds of code safety. For more secure coding principles and details, refer to the forthcoming SP 800-231F, Bugs Framework: Secure Coding Principles. 51

NIST SP 800-231 July 2024

10. BF Tools The BF features generaton tools that reflect the BF taxonomy, models, and formal language syntax and semantcs. The BFCWE tool and the BFCVE tool facilitate the generaton of formal weakness and vulnerability specificatons. The BF tool guides the creaton of complete BF vulnerability specificatons. The related BF APIs at [1] provide BF data retrieval and specific tool functonalites. The BFDB database hosts the BF data. The BF taxonomy structure and semantcs rules are organized via a relatonal database with graph features and via XML and JSON data interchange formats (query them via the BF API at [1]). The BFDB contains the types, names, and definitons of the BF taxons, their relatonships within the taxonomy, and the BF weakness and vulnerability semantc relaton and propagaton matrices and operaton flow graphs. The BF mashup database organizes additonal data for querying BF toward the CWE, CVE, NVD, GitHub [37], KEV [6], and Exploit Predicton Scoring System (EPSS) [38]. 10.1. BFCWE Tool The BFCWE tool facilitates the creaton of CWE-to-BF (CWE2BF) mappings by weakness operaton, error, final error, and possibly entre ⟨cause, operaton⟩→consequence) weakness triples [39]. It also generates BFCWE formal specificatons as entries of the BFCWE security weakness types dataset and graphical representatons of the CWE2BF mappings and the BFCWE specificatons to enhance understanding (e.g., see [16–18, 22]). Metculous analysis of the natural language descriptons of CWEs, relevant code examples, and descriptons of related CVEs is conducted to create CWE2BF mappings by weakness operaton, error, and final error and then by detailed ⟨bug, operaton⟩→error, ⟨fault, operaton⟩→error, ⟨bug, operaton⟩→final error, and ⟨fault, operaton⟩→final error weakness triples [40]. The BFCWE tool is utlized to generate the graphical representatons of the CWE2BF mappings for enhanced understanding as directed graphs with parent-child CWE relatonships. Examples include INP CWE2BF [16], MEM CWE2BF [17], and DAT CWE2BF [18]. Since a specific CWE should be about a single weakness, any parts of its descripton that reveal possible causing weaknesses are not considered for the BFCWE specificaton. However, they are considered for the partal BFCVE specificatons (see Sec. 11.3 and BFCVE Partal). All identfied weakness triples are checked against the BF matrix of valid ⟨cause, operaton⟩→consequence within weakness relatons, which defines part of the BF formal language semantcs. The same methodology helps reveal overlaps among the CWEs, as many of them have the same BF specificaton — that is, the same BF weakness triple. The BFCWE tool is utlized to generate the formal BF specificaton of each weakness as an entry of the BFCWE security weakness dataset and its graphical representaton. However, there could be a set of corresponding BF specificatons for some CWEs. For exam52

NIST SP 800-231 July 2024

ple, the natural language descriptons, demonstratve examples, and potental mitgatons for CWE-125 reveal the ⟨Overbound Pointer, Read⟩→Buffer Over-Read and ⟨Underbound Pointer, Read⟩→Buffer Over-Read possible weakness triples. Subsequently, these are the possible BF specificatons for the main weakness of a CVE mapped to CWE-125. Figure 23 shows their generated graphical representaton. BF Specifica�ons of CWE -125 _MEM Weakness Memory Use (MUS)

Address Fault

_MEM Weakness Memory Use (MUS)

Address Fault

Opera�on

Over Bounds Pointer

Read (Improper Operand: Address)

Opera�on

Under Bounds Pointer

Read (Improper Operand: Address)

Memory Corrup�on/Disclosure Final Error Buffer Over-Read

Memory Corrup�on/Disclosure Final Error Buffer Under-Read BF, I. Bojanova

Class Type

Defini�on

Memory Corrup�on/Disclosure (_MEM)

Weaknesses that lead to memory related errors or introduce memory corrup�on/disclosure exploit vectors.

Class

Defini�on

Memory Use (MUS)

An object is ini�alized, read, wri�en, or cleared improperly.

Opera�on

Defini�on

Read

Retrieve the data value of an object from memory.

Cause

Defini�on

Address Fault

The object address in use is wrong.

Overbound Pointer

Holds an address that is above the upper boundary of its object.

Underbound Pointer

Holds an address that is below the lower boundary of its object.

Consequence

Defini�on

Memory Corrup�on/Disclosure Final Error

An exploitable or undefined system behavior caused by memory addressing, alloca�on, use, or dealloca�on bugs.

Buffer Over-Read

Read data above the upper bound of an object.

Buffer Under-Read

Read data below the lower bound of an object.

Fig. 23. BF specificatons of CWE-125 The BFCWE tool is also useful for the generaton and analysis of CWE directed graphs by other criteria. For example, see the directed graphs of hardware CWEs and their analysis in NIST IR 8517 [41]. For more details, refer to the forthcoming SP 800-231G, Bugs Framework: Tools and APIs. 10.2. BFCVE Tool The BFCVETool facilitates the creaton of CVE-to-BF (CVE2BF) mappings by final error and possibly entre ⟨bug/fault, operaton⟩→final error weakness triple. It also generates possible chains of weaknesses for a vulnerability (e.g., a CVE) by an identfied failure, final error, or entre final weakness; generates possible BFCVE formal specificatons and their graphical representatons; and identfies CWEs for NVD assignment [42]. Code analysis and the BF graphical user interface (GUI) functonality can be used to identfy and complete the unique unambiguous BF vulnerability specificaton. 53

NIST SP 800-231 July 2024

The BF relatonal database, the NVD Representatonal State Transfer Applicaton Programming Interface (REST API), and the GitHub REST API are utlized to extract CVEs with assigned CWEs for which Code with Fix is available. For example, as of June 20, 2024, there are 5 162 CVEs that map to BF INP [1, 16] weakness triples by CWE, 4 484 CVEs that map to BF MEM [1, 17], and 629 CVEs that map to BF DAT [1, 18] for which GitHub diffs are available via the NVD. Other repositories may also provide fix commits and even the code of vulnerable functons (e.g., DiverseVul [43]). Informaton on the failure and the final weakness is gained from CVE reports, CVE descriptons, and CWE2BF weakness triple mappings if a CWE is assigned by the NVD. The BFCVE tool utlizes the BFDB relatonal database and the NVD REST API to extract the CWE2BF triples for that CVE. It then generates CVE2BF mappings by possible final error or final weakness and failure. For a specific CVE, the BFCVE tool applies the BF causaton and propagaton rules (i.e., the BF formal language syntax and semantcs) to go backward from the failure through the final weakness to generate all possible BF chains of weaknesses for that specific CVE independently of whether the CVE Code with Fix is available. Going backward from the failure, the BFCVE tool builds a connected acyclic undirected graph (i.e., a tree whose root is the failure) of all possible weakness chains with type-based backward fault type↶error type match and fault value↶error value propagaton or — for weaknesses of the same BF class type — direct match. The chains undergo scrutny to ensure further alignment with the BF formal language semantcs, the causaton matrices of meaningful ⟨cause, operaton⟩→consequence within weakness relatons, the graphs of meaningful (operaton1 , . . . , operatonn ) bug or fault state paths, and the matrices of meaningful consequence↷cause between weaknesses propagatons. The identfied failure and final weakness triple dramatcally reduce the number of generated possible paths in the acyclic graph. This is also a good startng point for specifying vulnerabilites that are not recorded in the CVE. The CVE Code with Fix can then be examined by security researchers or utlizing AI and compared with the generated chains of weakness triples to pinpoint the unique unambiguous BF vulnerability specificaton. For that, the BF tool functonality and automated code analysis — including via large language models (LLMs) — can be used. For example, the main vulnerability for CVE-2014-0160 Heartbleed (see Sec. 7.1) is mapped to CWE-125 in the NVD, and the CWE2BF mappings for CWE-125 restrict the final weakness optons for Heartbleed to ⟨Overbound Pointer, Read⟩→Buffer Over-Read and ⟨Underbound Pointer, Read⟩→Buffer Under-Read (see Sec. 10.1). However, the CVE-2014-0160 descripton reveals the word over, which indicates that CWE-125 is too abstract for it and eliminates the second final weakness opton. In additon, as Heartbleed leads to informaton exposure, the last part of the BF weaknesses chain is ⟨Overbound Pointer, Read⟩→Buffer Over-Read↷IEX. The Read operaton uniquely identfies the weakness as an instance of the BF MUS class, as BF classes do not overlap by operaton.

54

NIST SP 800-231 July 2024

Going backward from Overbound Pointer via the BF causaton and propagaton rules, the BFCVE tool generates a tree of suggested weakness chains for Heartbleed (see Fig. 24). The failure is the root, the final weakness is the first node, and a bug weakness is the last node of each path. The only optons for the weakness causing the final weakness are ⟨Wrong Index, Repositon⟩→Overbound Pointer and ⟨Wrong Size, Repositon⟩→Overbound Pointer. Both have the same optons for causing chains, only two of which do not start with a bug, though the preceding weakness optons start with a bug. Exhaustng these few optons via deep code analysis or the use of LLMs would confirm that the unique unambiguous chain for Heartbleed is ⟨Missing Code, Verify⟩→Inconsistent Value↷⟨Wrong Size, Repositon⟩→Overbound Pointer↷⟨Overbound Pointer, Read⟩→Buffer Over-Read↷IEX.

Fig. 24. Generated BF weakness chains for Heartbleed The BFCVE tool generates graphical representatons of the BFCVE formal specificatons to enhance understanding (see Fig. 21). Related BF tools functonality is the generaton of the webpages for the BF class taxonomies (e.g., BF MUS) and the BFCVE specificatons (e.g., BF CVE-2014-0160) of the BF website [1]. For more details, refer to the forthcoming SP 800-231G, Bugs Framework: Tools and APIs. 10.3. BF GUI Tool The BF tool is a GUI applicaton that works with both the BF relatonal database and the BF in XML or JSON format; the later is useful when the database is unavailable [44]. It allows users to create a new BF CVE specificaton, save it as a machine-readable .bfcve file, and open and browse previously created .bfcve specificatons [22]. The BF tool (see Fig. 25) guides the specificaton of a security vulnerability as a chain of underlying weaknesses. A security bug causes the first weakness, which leads to an error. This error becomes the cause (i.e., the fault) of the next weakness and propagates through subsequent weaknesses untl a final error is reached, enabling a security failure. The causaton within a weakness is by a meaningful ⟨cause, operaton⟩→consequence relaton. The causaton between weaknesses is by error type to fault type match and operaton flow or error↷fault by value propagaton. 55

NIST SP 800-231 July 2024

Fig. 25. BF GUI tool

56

NIST SP 800-231 July 2024

If a CVE is being specified, the user can select CVE Year and CVE ID in the CVE Details GroupBox to display its description, vendor, and product from the CVE repository and its CVSS [10, 11] severity score from the NVD. To create a BFCVE specification of that CVE, the user is guided to define an initial weakness, possible propagation weaknesses, and a final weakness leading to a failure. If a vulnerability has only one underlying weakness, it would be both the initial and final weakness. To start defining a weakness, the user has to select a BF weakness class from the BF Class TreeView in the Weakness GroupBox container, where the classes are grouped by BF class types as parent nodes. The selection of a class populates the five TreeView controls in the Weakness GroupBox container: Bug/Fault, Operand, Error/Final Error, Operation Attributes, and Operand Attributes. To specify the weakness, the user has to select child nodes from the five TreeView controls and enter comments in the text boxes beneath them. The BF tool can enforce that the initial weakness starts with a bug and the rest of the weaknesses start with a fault. However, this is not necessary for partial specifications or if a vulnerability starts with a hardware defect-induced fault. The Bug/Fault label changes to Bug when the initial weakness is viewed and to Fault when the propagation or final weakness is viewed. In the case of a bug, the child nodes are only allowed under the Code and Specification nodes. In the case of a fault, the child nodes are only allowed under the Data, Type, and Address nodes. Tooltips with term definitions are displayed over all TreeView nodes. The BF tool also enforces that the weakness with the final error consequence is the final weakness leading to a failure. Once a weakness is specified, the user can proceed via the >> button and create the next weakness of the vulnerability chain. Weakness chaining is restricted by the error-to-fault by type match rule, which — to a large extent — also restricts to meaningful operation flow, as the BF classes are developed to adhere to the BF bugs models that are specific to their BF class types. The Generate BF Description button displays a draft BF description based on the selected values from the five TreeView controls and Comment text boxes. Figure 26 presents the BF specification of the main vulnerability chain of Heartbleed in XML format generated by the BF tool. In addition to the XML attributes that relate to the BF Taxonomy, the CVE-2014-0160.bfcve also contains generated natural language descriptions, programming language, links to reports, code with bugs, code with fixes, commit IDs, authors, and code locations (i.e., lines) per weakness. For more details, see BF CVE-2014-0160 at [1]. The BF tool demonstrates how the BF taxonomy and causation and propagation rules tie together into the strict BF formal language. It uses the BFCVE tool functionality to generate graphical representations of the BF formal specifications to enhance understanding. For example, refer to the BF CVE-2014-0160 and related BF taxons definitions at [1]. For more details, refer to the forthcoming SP 800-231G, Bugs Framework: Tools and APIs. 57

NIST SP 800-231 July 2024

Fig. 26. BF Heartbleed in XML 58

NIST SP 800-231 July 2024

11.

BF Datasets and Systems

The BF formalism enables systematc comprehensive labeling of common weakness types (including CWEs) and publicly disclosed vulnerabilites (including CVEs). The BF tools and APIs enable the generaton of weakness and vulnerability specificatons. As of June 20, 2024, 31 % of the CWEs and 64 % of the CVEs labeled by the NVD with CWEs map to BF INP, MEM, and DAT classes. These provide a solid base for the creaton of comprehensively labeled BFCWE weakness and BFCVE vulnerability datasets. The BF and the contnuous development of BFCWE and BFCVE datasets would allow for multdimensional representatons of vulnerabilites in contrast to the one-dimensional representaton provided by the CVE enumeraton [8]. 11.1. BFCWE Dataset There are 938 CWEs [3] as of June 20, 2024. Of those, 157 map to the BF INP [1, 16] class type; 60 map to BF MEM [1, 17]; and 72 map to BF DAT [1, 18]. These 289 unique CWEs form 31 % (see Fig. 27) of the CWE repository and provide the basis for the systematc creaton of a comprehensively labeled BFCWE weakness dataset. Most of them represent the most dangerous weakness types by BF final error: Injecton and Memory Corrupton/Disclosure [45]. CWEs by BF Class Type

157 (17%) 60 (6%) 72 (8%) 649 (69%)

BF _INP

BF _MEM

BF _DAT

Others

Fig. 27. CWEs by BF class types The NVD uses the 130 “most commonly seen weaknesses” from CWE View-1003 [46] to label CVEs but may also list other CWEs assigned by third-party contributors. The BFCWE dataset may cover sofware, firmware, or hardware weakness types that are not listed in the CWE.

59

NIST SP 800-231 July 2024

The methodology for the creaton of a BFCWE dataset that utlizes the BF formal language involves the following four steps: 1. CWEs: Identfy CWEs and other weakness types that correspond to a specific sofware, firmware, or hardware executon phase. 2. CWE2BF Mappings: Create CWE2BF mappings by BF operaton, error, final error, and detailed ⟨bug/fault, operaton⟩→error/final error weakness triples [16–18, 22]. 3. BF Specificatons: Generate BFCWE formal specificatons as entries of the BFCWE security weakness types dataset. 4. Graphical Representatons: Generate BFCWE graphical representatons to enhance understanding of the CWE2BF mappings by operaton, error, final error, and complete weakness triples with parent-child CWE relatons. As the BFCWE specificatons are essentally partal BFCVE specificatons, the matrix and dataset are also contnuously enriched by newly developed BF specificatons of CVEs and other reported security vulnerabilites. All developed BFCWE specificatons are added to the comprehensively labeled BFCWE dataset (query it via the BFCWE API at [1]). The BFCWE dataset augments the NVD (see [47]) and the CWE via formal BF specificatons of common weaknesses as BF weakness triples and severity-related atributes. However, the BF has the expressive power to clearly describe any security weakness, not only the types listed in the CWE. 11.2. BFCVE Dataset There are over 180 472 CVEs labeled with CWEs by the NVD [5] as of June 20, 2024. Of those, 68 513 map to the BF INP [1, 16] class type by final error, 46 231 map to MEM [1, 17], and 3 631 map to DAT [1, 18] (see Fig. 28). These 118 375 unique CVEs represent 64 % of the CVEs labeled with CWEs and provide the basis for the systematc creaton of a comprehensively labeled BFCVE vulnerability dataset. Most of them relate to the most dangerous weakness types by BF final error: Injecton and Memory Corrupton/Disclosure [45]. The methodology for the creaton of a BFCVE dataset that utlizes the BF formal language involves the following nine steps: 1. CVEs with Code: Query the NVD and other vulnerability repositories for CVEs and other vulnerabilites with available GitHub commits — that is, CVEs for which Code with Fix is available. 2. Failure Mapping: Analyze each CVE to determine the reported failures, and map them to BF Failure classes.

60

NIST SP 800-231 July 2024

CVEs by BF Final Error

68513 (36%)

73517 (38%)

46231 (24%) 3631 (2%)

BF _INP

BF_MEM

BF _DAT

Other

Fig. 28. CVEs by BF class types 3. Final Error Mapping: Analyze each CVE to determine the reported sink — in some cases, it is also the root cause or wrongly reported as such — and map it to a BF Final Error consequence. 4. CVE2BF Mappings: Utlize steps from the methodology for the creaton of BFCWE, and create CVE2BF mappings by final weakness and failure for CVEs with assigned CWEs for which Code with Fix is available. 5. Backward State Tree: Generate possible backward chains of weaknesses for a vulnerability by its identfied failure and some or all of the elements of the final ⟨fault, operaton⟩→final error weakness or — in the case of a one-weakness vulnerability — ⟨bug, operaton⟩→final error weakness (see Sec. 3.4). 6. Bug or Fault Locaton: Identfy where in the code (i.e., file and lines) the resolved bug or a mitgated fault happened. Comparison of available Code with Bug and Code with Fix commits would help identfy these locatons. Improper operaton flow by BF bugs models would reveal missing operatons (i.e., Missing Code bugs). 7. BF Specificatons: Conduct deep code analysis — including via LLMs — to filter the generated chains, and use the BF formal language to complete the unambiguous BF vulnerability specificatons. 8. Graphical Representatons: Generate BFCVE graphical representatons to enhance understanding of the BF vulnerability specificatons as entries for the BFCVE security vulnerability dataset. 9. CWE Assignments: Identfy, refine, and recommend CWEs for NVD assignment. Although this step may seem illogical since a BF specificaton already provides comprehensive informaton, it may be useful when comparing CWE-based testng tool reports or if a more appropriate CWE is identfied.

61

NIST SP 800-231 July 2024

A key part of the BFCVE dataset generaton is the use of preliminary sets of partal BF specificatons of CVEs for which Code with Fix is available. These CVE sets are generated by querying the NVD and specific GitHub repositories toward the BFDB. For example, Fig. 29 shows a SQL query for vulnerabilites related to the BF MEM class type [1, 17] toward a repository with fix commits that are extracted via the GitHub REST API. The query also identfies the possible BF chains of weaknesses for each vulnerability. Security experts and LLMs can then conduct deep code analysis to create the complete BF vulnerability specificatons.

Fig. 29. NVD-GitHub-BF query for MEM CVEs A similar NVD-GitHub-BF query is used to generate the BFCVE Partal dataset of CVEs for which GitHub Code with Fix is available. As of June 20, 2024, there are 5 162 BF INP CVEs with GitHub commits in NVD, 4 484 MEM CVEs, and 629 DAT CVEs. This methodology would also guide the creaton of BF specificatons of vulnerabilites for which code is not available, and insights from existng BF specificatons would contribute to their analyses. Going backward from a final weakness would reveal optons for previous weaknesses untl a weakness with a bug as a cause is reached. For example, going backward from ⟨Wrong Size, Repositon⟩→Overbound Pointer reveals that the previous causing weakness is a BF Data Validaton (DVL) inital weakness among ⟨Missing Code / Erroneous Code / Under-Restrictve Policy / Over-Restrictve Policy, Verify / Correct⟩→Wrong Value / Inconsistent Value. Developed BFCVE specificatons are added to the comprehensively labeled BFCVE dataset (query it via the BFCVE API at [1]). The BF semantc matrices, graphs, and datasets are also 62

NIST SP 800-231 July 2024

continuously enriched by the newly developed formal BF specifications of CVEs and other reported security vulnerabilities. The BFCVE dataset augments the NVD (see [47]) and CVE via formal BF specifications of the publicly disclosed vulnerabilities as chains of weaknesses. However, the BF has the expressive power to clearly describe any security weakness and vulnerability, not only those listed in the CWE and CVE. It has its own databases with causal weakness taxonomies and formal vulnerability specifications composed of underlying weaknesses specifications. For more details, refer to the forthcoming SP 800-231H, Bugs Framework: Datasets and Classifications. 11.3.

BF Vulnerability Classifications

The BF Vulnerability Classification Model (see Fig. 30) defines how the BF taxonomy and tools are utilized to generate BFCWE and BFCVE datasets (see Sec. 11) and query them and possibly other vulnerability-related repositories to create the BFVul dataset of diverse multidimensional vulnerability classifications based on common properties and similarities. The methodology for the creation of BF-based vulnerability classifications involves the following steps: 1. BFCWE Dataset: Create a comprehensively labeled weakness dataset. 2. BFCVE Dataset: Create a comprehensively labeled vulnerability dataset. 3. Severity: Query the CVE for CVSS scores, or use other automated approaches to determine the vulnerability severity score. 4. Platform: Query the CVE for associated CPEs. 5. Exploitation: Query the NVD and EPSS for the probability of a CVE being exploited in the next 30 days. 6. Priority: Query the NVD and KEV or use other automated approaches to determine prioritization for remediation. 7. Vulnerability Classifications: Generate multidimensional vulnerability classifications based on common properties and similarities. Security vulnerabilities could be classified by common root causes (i.e., software or firmware bugs or hardware defect-induced bugs or faults), such as declaring a variable of a wrong data type. They could also be classified by any other BF taxons, such as propagating faults, common final errors, operation and operand attributes, identical BF specifications (i.e., chains of weaknesses), and even the number of underlying weaknesses. The BF operation and operand attributes provide insight into the severity of the weaknesses and how they relate to commonly used scores, such as CVSS [11] and EPSS [38]. 63

NIST SP 800-231 July 2024

BF Vulnerability Classifica�on Model

Descrip�ons Examples Basic CS & Security Research CWE Assignments

BF Taxonomy

Descrip�on Severity Score

CWE2BF

Other Vulnerability Repositories

BFCWE Tool

Commit URLs CVEs w/ CWEs

BFCWE

Code with Fix BFCVE Tool

Code with Diffs

BFCVEpre

Exploited Vulnerabili�es

Code Analysis Security Experts, LLMs BF Tool Exploit Probability

BFCVE

BF, I. Bojanova

BF Vulnerability Classifica�on

Fig. 30. BF Vulnerability Classificaton Model Their analysis would allow for deeper research on the most significant [45] and most exploited [48] weaknesses and vulnerabilites. Intriguing classificatons by BF classes and CPE [49] data may reveal systematc input/output check safety, memory safety, data type safety, and other secure coding problems by partcular vendors and products. These multdimensional BF vulnerability classificatons (query some of them via the BFVul API at [1]) would contribute to a deeper analysis and refined understanding of security 64

NIST SP 800-231 July 2024

weaknesses, vulnerabilities, exploits, and failures. They would enable more focused cybersecurity research and the highly informed development of effective countermeasures against potential security threats and specific exploits. For more details, refer to the forthcoming SP 800-231H, Bugs Framework: Datasets and Classifications. 11.4.

BF Systems

The BF supports the development of diverse systems related to bug identification and triaging, vulnerability detection, analysis, prioritization, reporting, and resolution or mitigation. The methodology for the development of a BF-based system involves the following steps: 1. Bug Identification: Utilize steps from the methodology for the creation of BFCVE and BFVul datasets, and identify and label the root cause of the vulnerability. 2. Vulnerability Detection: Utilize steps from the methodology for the creation of BFCVE and BFVul datasets, and identify and label the weaknesses underlying the vulnerability. This may include automated analysis via static and dynamic code analysis tools, and simulation or emulation algorithms that reflect the BF methodologies. Given the formal specification of code and the BF definitions of weakness, vulnerability, and failure, formal methods may also be applied to detect vulnerabilities. 3. Report Generation: Utilize steps from the methodology for the creation of BFCVE and BFVul datasets, and generate a BF formal specification, natural language description, and machine-readable and graphical representations of the vulnerability. An LLM may also be prompted to generate the report for that CVE given a CVE description, examples, reports, other references, the code with bug, the code with fix, BF security concept definitions, machine-readable representations of BF taxonomies (including definitions for the taxons and taxon types), and exemplary BF specifications (i.e., entries from the BFCVE dataset). 4. Severity and Prioritization: Determine the vulnerability severity score, and assess whether it needs to be resolved or mitigated urgently. This would be based on the BF-labeled weaknesses and operation and operand attributes per weakness and may include analysis of data from services and repositories, such as the EPSS [38], CVSS [11], and KEV [6]. 5. Resolution: Determine how the vulnerability should be resolved based on fixing the identified and BF-labeled bug of the vulnerability chain or more than one bug in the cases of converging vulnerabilities. 6. Mitigations: Determine the possible ways to mitigate the detected vulnerability based on fixing one of the BF-labeled faults through the vulnerability chain. For more details, refer to the forthcoming SP 800-231I, Bugs Framework: Systems. 65

NIST SP 800-231 July 2024

12.

Conclusion

This Special Publicaton presents an overview of the Bugs Framework (BF) [1] systematc approach and methodologies for the classificaton of bugs and faults per orthogonal by operaton executon phases, formal specificaton of weaknesses and vulnerabilites, definiton of secure coding principles, generaton of comprehensively labeled weakness and vulnerability datasets and vulnerability classificatons, and development of BF-based algorithms and systems. The BF weakness and failure taxonomies and bugs and vulnerability models form the basis for the BF ACFG that generates the BF formal language. The BF also helps formally define secure coding principles, such as input/output check safety, memory safety, and data type safety. The BF formal language is descriptve in that it is used to formally specify encountered or predicted weaknesses and vulnerabilites. The BF secure coding principles are prescriptve in that they prevent the bugs and faults per operaton that break specific related kinds of code safety. The BF formalism supports a deeper understanding of vulnerabilites as chains of weaknesses and allows for backward bug identficaton from a failure. It enables the development of new statc and dynamic analysis, simulaton, and emulaton algorithms (e.g., see [2]). AI or formal methods-enabled capabilites could be used to identfy bugs and detect, analyze, prioritze, and resolve or mitgate vulnerabilites (i.e., fix the bug or a fault of each vulnerability, respectvely) to secure critcal infrastructure and supply chains. The weakness and vulnerability BF specificaton datasets augment the CWE, CVE, and NVD. However, the BF has the expressive power to clearly describe any other security weaknesses and vulnerabilites. It also allows for the predicton and identficaton of as yet unencountered security weakness types, which allows for the predicton and detecton of new kinds of vulnerabilites. The BF aims to become the new standard for the specificaton and labeling of security weaknesses and vulnerabilites. It enables the clear and precise expression of security bugs, weaknesses, vulnerabilites, and failures. Government insttutons could improve the descriptons in public vulnerability repositories and create advanced policies and guidelines for sofware, firmware, and hardware testng. Security companies could improve their testng tools and bug and vulnerability reports. Academics could teach beter about security bugs, weaknesses, and vulnerabilites and conduct deeper security vulnerability and failure research. All of these would lead to unambiguous communicaton about cybersecurity, the increased precision of code review tools, and a decrease in security bugs, weaknesses, and vulnerabilites.

66

NIST SP 800-231 July 2024

References [1] Irena Bojanova (2014-2024) NIST Bugs Framework (BF) Website. Available at https: //usnistgov.github.io/BF. [2] Kedrian James, K Valakuzhy, K Snow, F Monrose (June 2024) CrashTalk: Automated Generaton of Precise, Human Readable, Descriptons of Sofware Security Bugs. CODASPY ’24: Proceedings of the Fourteenth ACM Conference on Data and Applicaton Security and Privacy, pp 337 – 347. htps://doi.org/10.1145/3626232.3653256 [3] MITRE (2006-2024) Common Weakness Enumeraton (CWE). Available at https://cw e.mitre.org. [4] MITRE (1999-2024) Common Vulnerabilites and Exposures (CVE). Available at https: //cve.mitre.org. [5] NIST (1999-2024) Natonal Vulnerability Database (NVD). Available at https://nvd.ni st.gov. [6] CISA (2021-2024) Known Exploited Vulnerabilites Catalog (KEV). Available at https: //www.cisa.gov/known-exploited-vulnerabilites-catalog. [7] MITRE CWE History. Available at https://cwe.mitre.org/about/history.html. [8] David E Mann, S M Christey (Jan. 8, 1999) Towards a Common Enumeraton of Vulnerabilites. Available at https://www.cve.org/Resources/General/Towards-a-Commo n-Enumeraton-of-Vulnerabilites.pdf. [9] MITRE CVE History. Available at https://www.cve.org/About/History. [10] Peter Mell, K Kent, S Romanosky (2006) Common vulnerability scoring system. Available at https://tsapps.nist.gov/publication/get pdf.cfm?pub id=50899. [11] FIRST (2015-2024) Common vulnerability scoring system special interest group. Available at https://www.first.org/cvss. [12] Irena Bojanova (Dec. 9, 2014) Formalizing Sofware Bugs. NIST, ITL, SSD. Available at https://www.nist.gov/publicatons/formalizing-software-bugs. [13] Irena Bojanova (Apr. 8, 2015) Towards a ’Periodic Table’ of Bugs. NIST, ITL, SSD. Available at https://www.nist.gov/publicatons/towards-periodic-table-bugs. [14] Yan Wu, I Bojanova, Y Yesha (2015) They Know Your Weaknesses - Do You?: Reintroducing Common Weakness Enumeraton. CrossTalk (The Journal of Defense Sofware Engineering), pp 44–50. Available at https://web.archive.org/web/20180425211828 id /http://static1.1.sqspcdn.com/static/f/702523/26523304/1441780301827/20150 9-Wu.pdf?token=WJEmDLgmpr3rIZHriubA20L%2F1%2F4%3D. [15] Irena Bojanova, P E Black, Y Yesha, Y Wu (October 2016) The NIST Bugs Framework (BF): A Structured Approach to Express Bugs. 2016 IEEE Internatonal Conference on Sofware Quality, Reliability and Security (QRS), pp 175–182. htps://doi.org/10.1109/ QRS.2016.29 [16] Irena Bojanova, C E Galhardo (October 2021) Input/Output Check Bugs Taxonomy: Injecton Errors in Spotlight. 2021 IEEE Internatonal Symposium on Sofware Reliability Engineering Workshops (ISSREW), pp 111–120. htps://doi.org/10.1109/ISSREW5361 1.2021.00052 67

NIST SP 800-231 July 2024

[17] Irena Bojanova, C E Galhardo (July 2021) Classifying Memory Bugs Using Bugs Framework Approach. 2021 IEEE 45th Annual Computers, Sofware, and Applicatons Conference (COMPSAC), pp 1157–1164. htps://doi.org/10.1109/COMPSAC51774.2021. 00159 [18] Irena Bojanova, C E Galhardo, S Moshtari (October 2022) Data Type Bugs Taxonomy: Integer Overflow, Juggling, and Pointer Arithmetcs in Spotlight. 2022 IEEE 29th Annual Sofware Technology Conference (STC)), pp 192–205. htps://doi.org/ 10.1109/STC55697.2022.00035 [19] Constable S (Febryary 29, 2024) Chips & Salsa: Industry Collaboraton for new Hardware CWEs. Available at https://community.intel.com/t5/Blogs/Products-and-Solut ions/Security/Chips-Salsa-Industry-Collaboraton-for-new-Hardware-CWEs/post/1 575521. [20] Kedrian James, Y Du, S Das, F Monrose (December 2022) Separatng the Wheat from the Chaff: Using Indexing and Sub-Sequence Mining Techniques to Identfy Related Crashes During Bug Triage. 2022 IEEE 22nd Internatonal Conference on Sofware Quality, Reliability and Security (QRS), pp 31–42. htps://doi.org/10.1109/QRS575 17.2022.00014 [21] Drew Malzahn, Z Birnbaum, C Wright-Hamor (2020) Automated Vulnerability Testng via Executable Atack Graphs. 2020 Internatonal Conference on Cyber Security and Protecton of Digital Services (Cyber Security) (IEEE), p 1–10. htps://doi.org/10.1109/ CyberSecurity49315.2020.9138852 [22] Irena Bojanova (Jan.-Feb. 2024) Comprehensively Labeled Weakness and Vulnerability Datasets via Unambiguous Formal NIST Bugs Framework (BF) Specificatons. IEEE IT Professional, Vol. 26, 1, pp 60–68. htps://doi.org/10.1109/MITP.2024.3358970 [23] Wikipedia (2023) Heartbleed. Available at https://en.wikipedia.org/wiki/Heartbleed. [24] IEEE Computer Society (September, 1990) IEEE Standard 610.12-1990, Glossary of Sofware Engineering Terminology. Available at https://ieeexplore.ieee.org/stamp/stam p.jsp?arnumber=159342. [25] CISA (2022) ICS Advisory (ICSA-21-119-04). Available at https://www.cisa.gov/uscert/ ics/advisories/icsa-21-119-04. [26] Omri Ben-Bassat TA (2021) ERROR: BadAlloc! - Broken Memory Allocators Led to Millions of Vulnerable IoT and Embedded Devices. Blackhat USA 2021 Available at https://www.youtube.com/watch?v=lSvygMc8uc0. [27] Assane Gueye, C E Galhardo, I Bojanova (Jul.-Aug. 2023) Critcal Sofware Security Weaknesses. IEEE IT Professional, Vol. 25, 4, pp 11–16. htps://doi.org/10.1109/MITP .2023.3297387 [28] OpenSSL (2005) Openssl/ssl/d1 both.c. Available at https://git.openssl.org/?p=ope nssl.git;a=blob;f=ssl/d1 both.c;h=0a84f957118afa9804451add380eca4719a9765e;h b=4817504d069b4c5082161b02a22116ad75f822b1. [29] Sean Cassidy (April, 2014) Diagnosis of the OpenSSL Heartbleed Bug. Available at ht tps://www.seancassidy.me/diagnosis-of-the-openssl-heartbleed-bug.html.

68

NIST SP 800-231 July 2024

[30] OpenSSL (2014) openssl/openssl, openssl 1 0 1-stable. Available at https://github.c om/openssl/openssl/commit/96db9023b881d7cd9f379b0c154650d6c108e9a3. [31] ISO/IEC 14977 (1996) Internatonal Standard: Informaton technology — Syntactc metalanguage — Extended BNF. Available at https://www.iso.org/standard/261 53.html. [32] Alfred Aho, M Lam, R Sethi, J Ullman (2006) Compilers: Principles, Techniques, and Tools (Addison-Wesley). [33] Donald Knuth (1968) Semantcs of context-free languages. Math. Systems Theory 2, p 127–145. htps://doi.org/10.1007/BF01692511 [34] Sofware Engineering Insttute (2016) SEI CERT C Coding Standard: Rules for Developing Safe, Reliable, and Secure Systems. Available at https://resources.sei.cmu.edu/ downloads/secure-coding/assets/sei-cert-c-coding-standard-2016-v01.pdf. [35] Sofware Engineering Insttute (2016) SEI CERT C++ Coding Standard: Rules for Developing Safe, Reliable, and Secure Systems. Available at https://resources.sei.cmu.ed u/downloads/secure-coding/assets/sei-cert-cpp-coding-standard-2016-v01.pdf. [36] Open Web Applicaton Security Project (2010) OWASP Secure Coding Practces-Quick Reference Guide. Available at https://owasp.org/www-project-secure-coding-pract ices-quick-reference-guide. [37] GitHub (2008) GitHub. Available at https://github.com. [38] FIRST (2021-2024) Exploit Predicton Scoring System (EPSS). Available at https://ww w.first.org/epss. [39] Irena Bojanova (2020-2024) NIST Bugs Framework (BF), BFCWE Tool. Available at ht tps://usnistgov.github.io/BF/info/tools/bfcwe-tool. [40] Irena Bojanova, J J Guerrerio (Sept.-Oct. 2023) Labeling Sofware Security Vulnerabilites. IEEE IT Professional, Vol. 25, 5, pp 64–70. htps://doi.org/10.1109/MITP.2023. 3314368 [41] Peter Mell, Irena Bojanova (2024) NIST IR 8517, Hardware Security Failure Scenarios: Potental Weaknesses in Hardware Design. Available at https://doi.org/10.6028/NI ST.IR.8517. [42] Irena Bojanova (2020-2024) NIST Bugs Framework (BF), BFCVE Tool. Available at http s://usnistgov.github.io/BF/info/tools/bfcve-tool. [43] Chen Y, at all (2023) DiverseVul: A New Vulnerable Source Code Dataset for Deep Learning Based Vulnerability Detecton. Available at https://github.com/wagner-gro up/diversevul. [44] Irena Bojanova (2020-2024) NIST Bugs Framework (BF), BF Tool. Available at https: //usnistgov.github.io/BF/info/tools/bf-tool. [45] Carlos EC Galhardo, P Mell, I Bojanova, A Gueye (December 2020) Measurements of the Most Significant Sofware Security Weaknesses. 2020 Annual Computer Security Applicatons Conference (ACSAC), p 154–164. htps://doi.org/10.1145/3427228.3427 257 [46] MITRE (2023) Weaknesses for Simplified Mapping of Published Vulnerabilites. Available at https://cwe.mitre.org/data/definitions/1003.html. 69

NIST SP 800-231 July 2024

[46] MITRE (2023) Weaknesses for Simplified Mapping of Published Vulnerabilites. Available at https://cwe.mitre.org/data/definitions/1003.html. [47] Kevin Poireault (Mar. 28, 2024) NIST Unveils New Consortum to Operate Natonal Vulnerability Database. Available at https://www.infosecurity-magazine.com/news /nist-unveils-new-nvd-consortium/#:∼:text=NVD’s%20One%2Dto%2DFive%20Year, years%2C%20especially%20around%20software%20identfication. [48] Peter Mell, I Bojanova, Carlos EC Galhardo (May-Jun. 2024) Measuring the Exploitaton of Weaknesses in the Wild. IEEE IT Professional, Vol. 26, 2, pp 14–21. htps://doi.org/10.1109/MITP.2024.3399485 [49] NIST Common Platorm Enumeraton (CPE). Available at https://csrc.nist.gov/projec ts/security-content-automation-protocol/specifications/cpe.

70

Related documents

• CYB 5900 : Cybersecurity Capstone#1178955
• Designing a decision support system for the weakly formalized problems in the provision of cybersecurity#671989
• 15 U.S.C. § 7432 — National cybersecurity challenges#565568
• NIST SP 800-195: 2016 NIST/ITL Cybersecurity Program Annual Report#2945
• NIST SP 800-211: 2019 NIST/ITL Cybersecurity Program Annual Report#2961