Re: A Proposal to Precisely Define Weaknesses

>             A Proposal to Precisely Define Weaknesses
>
>                      by Paul E. Black
>
>                         1 May 2009
>
>  
>
> Although much work has been done, which has greatly improved the definitions
> of source code weaknesses, there are still inconsistencies, ambiguities, and
> errors.  Better definitions are needed as one element to speed the work of
> detecting and preventing weaknesses.
>
>  
>
> We propose, first, that one element of a CWE be designated the prime
> definition.  If there is inconsistency between the prime definition and a
> description, example, or definition in another element, the prime definition
> is considered to be correct.  If there is an error, the prime definition is
> the first to be fixed.  Other descriptions and definitions can later be
> brought into alignment.  Second we propose a specific set of reviews and
> other steps as necessary and sufficient to consider a prime definition to be
> thoroughly reviewed.
>
>  
>
> This document has three sections: motivation for precisely and accurately
> defining weaknesses, comments on the current state of definitions, and the
> proposal itself.  
>
>  
>
> If you disagree (or agree!)  with the proposal or have suggestions, please
> respond.  Feel free to share this.
>
>  
>
>  
>
> SECTION 1. WHY CAREFULLY DEFINE WEAKNESSES?
>
>  
>
> An important prelude to preventing, mitigating, or detecting weaknesses in
> software and systems is to have clear, unambiguous, widely-accepted
> definitions of such weaknesses.  Consider the following questions that might
> occur to someone learning about software weaknesses.  What precisely is a
> buffer overflow?  Is it the same as a heap overflow or an unbounded
> transfer?  Is one just a refinement of another?  If an integer overflow
> leads to memory violation, which weakness is it?  Is it both or is there
> some other relation between them?  Precise definitions could answer these
> questions and others.
>
>  
>
> Many people have done excellent work toward clearly defining types of
> weakness.  (Hereafter we usually use the term "weakness" to mean a weakness
> class or type, not a particular instance of a weakness type.) Some papers
> and work are "Seven Pernicious Kingdoms: A Taxonomy of Software Security
> Errors" (Tsipenyuk, Chess, and McGraw), "The CLASP Application Security
> Process", (Viega), "The Preliminary List of Vulnerability Examples for
> Researchers (PLOVER)" (Christey), "The Ten Most Critical Web Application
> Security Vulnerabilities" (OWASP), "19 Deadly Sins of Software Security
> Programming Flaws and How to Fix Them" (Howard, LeBlanc, and Viega), "A
> Taxonomy of Computer Program Security Flaws, with Examples" (Landwehr, Bull,
> McDermott, and Choi), (see http://cwe.mitre.org/about/sources.html for more)
> "Structured CWE Descriptions" (Christey, Harris, Heinbockel) available at
> http://cwe.mitre.org/documents/structured_descriptions/, ISO/IEC Project
> 22.24772: Programming Language Vulnerabilities available at
> http://aitc.aitcnet.org/isai/ and many others.  KDM Analytics has produced
> formal definitions of some 30 weaknesses.
>
>  
>
> Since 2006 MITRE has led the Common Weakness Enumeration (CWE) effort to
> collect, reconcile, organize, and define weaknesses.  Not only has this work
> improved and unified definitions, it has also led to discovery of
> fundamental clarifying concepts, such as chains and composites of weaknesses
> ("Chains and Composites", Steve Christey,
> http://cwe.mitre.org/data/reports/chains_and_composites.html).
>
> Precise definitions can lead to further better understanding of weaknesses,
> their causes, cures, and preventions.
>
>  
>
> There are still inconsistencies and ambiguities within CWEs.  Consider that
> a CWE may have many descriptive elements.  Some in CWE Version 1.0 are
>
>     Black_Box_Definition (possibly more than one)
>
>     White_Box_Definition (possibly more than one)
>
>     Description
>
>     Description_Summary
>
>     Extended_Description
>
>     Compound_Element
>
>     Name (Weakness)
>
>     Demonstrative_Example
>
>     Observed_Example
>
>     Note
>
>     Theoretical_Note
>
> Could inconsistencies be eliminated by deleting all but one such element in
> each CWE?  That is not practical.  One definition cannot serve all people in
> all instances.  Training and reference needs succinct prose definitions and
> examples.  Automated tools need a definition written in machine-readable
> languages.  When discussion gets specific, people need the nuances and
> details of what constitutes that weakness.  Proving that a weakness is
> absent or is prevented by some approach needs a rigorous, mathematically
> formal definition.
>
>  
>
> Improving the state-of-practice of software development to reduce instances
> of weaknesses and the vulnerabilities they cause takes work from language
> designers, compiler writers, educators, assurance tool developers, auditors
> and developers of guidance, people who specify and contract software
> development, researchers, vulnerability trackers, software engineers, and
> many more.  If people in these roles disagree about what constitutes a
> particular weakness, or even whether it is a weakness at all, communication
> is difficult at best.  At worst they may work at cross purposes.  Broadly
> accepted definitions should allow different groups to work together more
> effectively.
>
>  
>
> Unambiguous, complete definitions allows those in the field to understand
> precisely what different software assurance tools, services, technologies,
> or methods can detect, mitigate, or prevent.
>
> Formal definitions may allow tools to automatically check for weaknesses,
> create wrappers to filter out attacks to exploit them, or even rewrite the
> code to eliminate them.
>
>  
>
>  
>
> SECTION 2. DOES THE CURRENT METHOD NEED IMPROVEMENT?
>
>  
>
> Currently there isn't a documented process to validate weakness definitions.
> Descriptions, definitions, and examples in the CWE have been reviewed and
> improved by different entities and the quality and consistency have improved
> dramatically over the years.  Yet, even casual examination shows that most,
> if not all, CWEs need further work.
>
>  
>
> Given the number of CWEs and their range of complexity, frequency, and
> severity, it is probably not worthwhile to precisely define every single
> weakness.  But for those which need precise definitions, it is not clear
> exactly what should be.  As with code, an essentially unlimited amount of
> checking and review could be done for each weakness.  The community should
> agree on the types and amounts of validation that are necessary and
> sufficient.
>
>  
>
> To be specific, currently every CWE has a summary description.  A CWE may
> also have alternate term descriptions, demonstrative examples, or a white
> box definition.  Thousands of these descriptions have been reviewed and
> improved greatly.  But which ones are merely informative and which ones are
> intended to be the carefully reviewed, precise and accurate?  Consider
> CWE-121, Stack-based Buffer Overflow.  (Text taken from CWE version 1.3).
> Here is the description summary:
>
>  
>
>    "A stack-based buffer overflow condition is a condition where the
>
>    buffer being overwritten is allocated on the stack (i.e., is a
>
>    local variable or, rarely, a parameter to a function)."
>
>  
>
> Here is the White Box Definition:
>
>  
>
>     "A buffer overflow where the buffer from the Buffer Write
>
>     Operation is statically allocated"
>
>  
>
> Is the following an instance of CWE-121?  Note that alloca() gets memory
> from the stack, not the heap.
>
>  
>
> #define BUFSIZE 256
>
> char *buf;
>
> int main(int argc, char **argv) {
>
>     buf = (char *)alloca(BUFSIZE);
>
>     strcpy(buf, argv[1]);
>
> }
>
>  
>
> The description summary uses "i.e." meaning "that is" or a restatement.  A
> strict reading excludes this example because the buffer is only referenced
> by a global variable.
>
>  
>
> The white box definition says the buffer is statically allocated, that is,
> allocated automatically by the compiler or language support routine, not by
> functions invoked at run-time, such as alloca().
>
> Again a strict reading excludes this example because the buffer is
> dynamically allocated.
>
>  
>
> Yet most people would agree that the example code has an instance of
> Stack-based Buffer Overflow and that the descriptions have minor
> inaccuracies.  Even ignoring this particular example, we see there is
> inconsistency between the descriptions.
>
>  
>
> The following code snippets highlight not merely quibbles about wording, but
> raise the fundamental question of what CWE-121 means.
>
>  
>
> typedef struct
>
> {
>
>   char buf1[10];
>
>   char buf2[10];
>
> } my_struct;
>
>  
>
>   my_struct s;
>
>  
>
>   s.buf1[17] = 'A';
>
>  
>
> (from SRD test case 188)
>
>  
>
> The C99 standard [1] Sect. 6.7.2.1 Structure and union specifiers, page 102,
> para 5 says fields are "allocated in order".  So buf2 makes the structure at
> least big enough that the access doesn't go outside the structure.  Any
> particular compiler probably allocates the structure consistently, so the
> above code likely have a specific behavior in each environment, although it
> might differ from environment to environment.  Is this an instance as
> CWE-121?
>
>  
>
> It is common in network programming to have structures and code like the
> following:
>
>  
>
>     struct {
>
>       int header;
>
>       char payload[ 0 ];
>
>     } *p;
>
>  
>
>     p = malloc(sizeof *p + 2);
>
>     p->payload[0] = 'A';
>
>     p->payload[1] = '\0';
>
>  
>
> (adapted from Aurelien Delaitre)
>
>  
>
> Nothing in the C standard justifies this code, but most compilers will treat
> it reasonably.  Since the code does not strictly follow the C standard, is
> its behavior undefined so that this should not be considered an instance of
> CWE-121?
>
>  
>
> Compilers usually allocate structures in multiples of four bytes, so the
> following code should be fine.  That is, there is memory for 12 characters
> in the structure.  Should this example be considered to write outside of the
> buffer or not?  On what grounds?
>
>  
>
> typedef struct
>
> {
>
>   int int_field;
>
>   char buf[10];
>
> } my_struct;
>
>  
>
>   my_struct s;
>
>  
>
>   s.buf[10] = 'A';
>
>  
>
> (from SRD test case 201)
>
>  
>
> We see that precise definitions are important to make consistent judgments.
> We also see that it is very difficult to write a definition which is precise
> and accurate.  
>
>  
>
> Given all the work which the CWE embodies, how can the effect of
> inconsistencies be minimized?  Where should work be concentrated to achieve
> good definitions?  All CWEs have a status of draft or incomplete.  How much
> and what kind of work should be done before a definition is considered to be
> "thoroughly reviewed", that is, good enough for the community to move on to
> another one?  What language, either formal (mathematically precise) or
> prose, should be used to state definitions clearly and so the style is
> similar across CWEs?
>
> What should be done to minimize assumptions or artifacts arising from the
> use of a particular formal language or style?
>
>  
>
>  
>
> SECTION 3. THE PROPOSAL
>
>  
>
> This proposal is part of a vision to improve software assurance by having
> widely-used clear definitions of software weakness classes.
>
> The goals of this proposal are to
>
>   * increase precision (minimize ambiguity and inconsistency) in CWE
>
>       entries and
>
>   * increase accuracy (minimize mistakes indicated by broad agreement).
>
>  
>
> The proposal has two points: (1) the need for an prime definition and
>
> (2) a review process.  Each point has several parts or supporting clauses
> which are somewhat independent.
>
>  
>
> POINT ONE: The community should have one prime definition of each weakness.
>
>  
>
> PROPOSAL CLAUSE 1: the Common Weakness Enumeration (CWE) is the repository
> of the prime definition.
>
>  
>
> PROPOSAL CLAUSE 2: each weakness has exactly one prime definition.
>
>  
>
> All other notes, summaries, descriptions, categories, components, examples,
> definitions, etc. are subordinate to it.  For instance, if a summary seems
> to contradict the prime definition, the prime definition is assumed to be
> correct and the summary should be reinterpreted or changed.
>
>   There may be times when the prime definition is just wrong and needs to be
> corrected (see review process below), but short of that, the prime
> definition is authoritative.
>
>  
>
> The prime definition is a complete description of the weakness.  All details
> and nuances are in that element.  One need not read any other element to
> understand what is or is not an instance, although other elements may be
> helpful as examples or restatements.
>
>  
>
> It is important for the community to choose a prime definition so work can
> be focused on it.  Having prime definitions lets us decide that a CWE is
> precisely and accurately described.  Other summaries, descriptions, views,
> names, etc. can be brought into agreement as time, resources, and need
> arise.
>
>  
>
> The prime description will likely be legalistic and dry, like most formal
> descriptions.  One would read something else to initially get a sense of
> what it is or to be reminded of it.  Summaries, relationships, and notes
> serve such purposes.  Rather the prime definition answers questions when
> differences of opinion or interpretation arise.
>
>  
>
> A clearly defined vocabulary is needed.  Likely there will be stock phrases,
> too.  This vocabulary and the definitions themselves should be based on the
> work already done by many contributors to the CWE.
>
> One example is "Structured CWE Descriptions" (Christey, Harris, Heinbockel),
> available at http://cwe.mitre.org/documents/structured_descriptions/ Another
> is the work by KDM Analytics.  Starting from scratch would be wasteful.
>
>  
>
> DISCUSSION POINT: if elements refer to completely orthogonal ideas, there
> could be more than one prime element and still has no chance of (internal)
> contradiction.  
>
>  
>
> We don't think this occurs in CWE.
>
>  
>
> DISCUSSION POINT: "prime definition" is only one possible name.  Other
> possibilities are master, attested, decisive, prevailing, key, normative,
> authoritative, official, sanctioned, or commonly accepted element or
> definition.
>
>  
>
> PROPOSAL CLAUSE 3: different kinds of weaknesses are best expressed with
> different prime elements.
>
>  
>
> Most weaknesses are manifest in code, like hard-coded password
>
> (CWE-259) or leftover debug code (CWE-489).  (Note that these two are not
> 100% discernible from code alone.)  However some weaknesses are "black box",
> behavioral, functional, or external weaknesses, like denial of service
> (CWE-730), configuration (CWE-16), or violation of secure design principles
> (CWE-657).
>
>  
>
> PROPOSAL CLAUSE 4: each kind of weakness (see CLAUSE 3) has a prime element.
>
>  
>
> For instance, the prime definition for all weaknesses manifest in code might
> be White_Box_Definition.
>
>  
>
> DISCUSSION POINT: what is the right element for each kind of weakness?  For
> weaknesses manifest in code White_Box_Definition seem most appropriate.
> Application behavior could be described in Black_Box_Definition.
>
>  
>
>  
>
> POINT TWO: How should the Community Decide a Definition is Right?
>
>  
>
> An implementation may be checked for correctness against its specification.
> But how can a specification be checked?  The short answer is that it can't
> be fully checked.  However, we can take steps to validate a definition and
> minimize mistakes.
>
>  
>
> PROPOSAL CLAUSE 5: a CWE prime definition is acceptable when the following
> are done:
>
>   (A) the definition is published on the CWE discussion list, and
>
>      there is no (or only limited) disagreement that it is precise
>
>      (unambiguous) and accurate (correct).
>
>   (B) the definition agrees with SC22/WG23 Programming Language
>
>      Vulnerabilities if there is a correspondence.
>
>   (C) the definition is carefully reviewed by two experts, who find it
>
>      to be precise and accurate.
>
>   (D) the definition is written in two different "executable" forms
>
>      which are tested and deemed to find/generate/mitigate the
>
>      weakness (and nothing else).
>
>  
>
> We think these steps are the minimum needed to come up with good
> definitions.  We need the general consensus of the community to make sure it
> is broadly agreeable.  We want definitions which are consistent with other
> standards rather than creating yet another
>
> (inconsistent) "standard".  We need experts to make sure the definition says
> the right thing.  Finally, we need executable forms to make sure the
> definition is precise.
>
>  
>
> Since CWEs are still being developed and the community is self-selected, We
> don't think unanimous agreement is needed.
>
> Nevertheless, any objections should be taken very seriously.  The desired
> goal is unanimity.
>
>  
>
> The community of concern is large and there are other efforts.  As much as
> possible the definitions should be in harmony.  One particular effort is
> PDTR 24772 a draft of which is document N0138 at
> http://aitc.aitcnet.org/isai/  Here are some correspondences between CWEs
> and entries in PDTR 24772:
>
> 6.15 Numeric Conversion Errors [FLC]
>
>     CWE 192
>
> 6.17 Boundary Beginning Violation [XYX]
>
>     CWE 123
>
>     CWE 129
>
> 6.18 Unchecked Array Indexing [XYZ]
>
>     CWE 129
>
> 6.19 Buffer Overflow in Stack [XYW]
>
>     CWE 121
>
>  
>
> We need reviews from at least two very different experts to minimize the
> chance that the definition only reflects the view of one person or one
> group.  Why not three or more?  The only objective reason we offer is that
> economy suggests the fewest possible, and two is the least number greater
> than one.
>
>  
>
> Who are the experts?  We don't have specific people in mind.  It seems it
> should be people who have a lot of experience in the field.  It also seems
> like it should be people who have thought about such definitions, so its
> likely to be authors, security researchers, and tool makers.  Maybe we
> should designate a pool of experts and any two of them are acceptable.  (And
> no objections from "experts"?)  Expert availability will probably be a
> factor.
>
>  
>
> The definition should be "formalized" in at least two completely different
> ways to minimize the chance of unstated assumptions or severe bias to one
> form of expression.  Some ways may be a language for generating test cases,
> rules for a source code scanner to find the weakness, or a purely formal
> description in a highly mathematical notation for proving program
> properties.
>
>  
>
> The executable forms and the expert reviews should be completely
> independent.  That is, a expert writing an "executable" form only counts as
> an expert review (C above) or an executable (D above), but not both.  Also
> the two experts should not be from the same organization.
>
>  
>
> It was suggested that one more step be added: that the definition be
> validated to accurately describe some subset of reported instances of the
> weakness, like the CVE.  The aim is to make sure the definition corresponds
> to real examples.
>
>  
>
> This proposal does not address how the process would be executed, in
> particular where the resources would come from.  Nevertheless, We think it
> is important to begin by getting community agreement on these two points.
>
>  
>
> -paul-
>
>  
>