Re: Current standards/criteria for 'Undefined Behavior'

["Adinolfi, Daniel R" <dadinolfi@mitre.org>]

All,

 

The CVE Team largely agrees with community discussion of this topic at:

  http://openwall.com/lists/oss-security/2017/04/12/3

  http://openwall.com/lists/oss-security/2017/04/12/2

In terms of the CNA Rules, we feel that these undefined-behavior reports satisfy the definition of a vulnerability (Appendix A) because it is unreasonable for computational logic to depend on the implementation details of a compiler or the selected compiler options.

All, or nearly all, of the recent "undefined behavior" CVE IDs are the result of a discloser relying on the UndefinedBehaviorSanitizer tool that has design goals expressed in the http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html post. Also, these CVE IDs are for software products that are libraries, usable in building arbitrary programs including long-running daemons.

Referring to the C standard at http://www.open-std.org/jtc1/sc22/wg14/www/standards.html or similar online versions such as the http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf document, one can see statements such as "Possible undefined behavior ranges from ignoring the situation completely with unpredictable results ... to terminating a translation or execution." Terminating an execution is probably the most relevant for these CVE IDs. Also, the document

specifically mentions types of undefined behavior for which CVE IDs have been assigned, e.g., "If the value being converted is outside the range of values that can be represented, the behavior is undefined" and "The result of E1 << E2 is E1 left-shifted E2 bit positions ... otherwise, the behavior is undefined."

In other words, a program termination (aka a crash) is an outcome called out in the C standard. A crash within library code has a loss of availability, and thus matches the definition of a vulnerability.

 

One scenario of interest is a user who explicitly chooses compiler options that terminate the program upon encountering undefined behavior, e.g., "clang -fsanitize=undefined -fno-sanitize-recover" with LLVM. This means that an availability impact does occur. Admittedly, the availability impact may be rare in the real world, because people don't often use those clang flags for production code.

Another scenario of interest is compiler optimizations that happen to result in generation of vulnerable code for a program that relies on undefined behavior, such as CVE-2017-7892 which is about undefined behavior in "pointer arithmetic calculations that overflow." Here, the impact might not be limited to availability.

Based on the above, the MITRE CNA currently uses this guideline: a report of undefined behavior in a library is considered equivalent to a report of a crash in a library, in determining whether a CVE ID may exist.

However, Appendix E of the CNA Rules is also followed. For example, in the CVE-2017-7961 case, we received a dispute stating that there is no impact. We recorded the dispute as required (this does not necessarily mean that we believe the dispute is correct).

 

Please let us know if you have any other questions or need any other clarification.

 

Thanks.

 

-Dan, for the Team

 

From: <owner-cve-editorial-board-list@lists.mitre.org> on behalf of jericho <jericho@attrition.org>
Date: Monday, May 8, 2017 at 19:50
To: "Evans, Jonathan L." <jevans@mitre.org>
Cc: cve-editorial-board-list <cve-editorial-board-list@lists.mitre.org>
Subject: RE: Current standards/criteria for 'Undefined Behavior'

 

Jonathan,

 

On Wed, 3 May 2017, Evans, Jonathan L. wrote:

 

: We are not entirely sure what you mean by "undefined behavior."  Are you

: talking about the CVE entries that specifically say "undefined

: behavior," such as CVE-2017-8326 and CVE-2017-7961?

 

Yes. A short list:

 

https://www.google.com/search?q=site%3Acve.mitre.org+%22undefined+behavior%22&oq=site%3Acve.mitre.org+%22undefined+behavior%22&aqs=chrome..69i57j69i58.3867j0j7&sourceid=chrome&ie=UTF-8

 

Thank you,

 

Brian