Re: Current standards/criteria for 'Undefined Behavior'

["Landfield, Kent" <Kent_Landfield@McAfee.com>]

That brings up a conflict for potentially a number of us.  The NIST Cybersecurity Framework Development Workshop is being held at NIST on the 16^th and 17^th.  I will not be available to participate in the CVE Board call since I will be attending and on a panel.  There may be others as well.  Any chance we can either push the call next week a day or two or push it a week to the following Wednesday? 

 

If we are going to be discussing the current thread, I definitely want to be there.

 

--

Kent Landfield

817-637-8026

kent_landfield@mcafee.com

 

From: <owner-cve-editorial-board-list@lists.mitre.org> on behalf of "Levendis, Chris" <clevendis@mitre.org>
Date: Thursday, May 11, 2017 at 4:23 PM
To: "Millar, Thomas" <Thomas.Millar@hq.dhs.gov>, Carsten Eiram <che@riskbasedsecurity.com>, "Adinolfi, Daniel R" <dadinolfi@mitre.org>
Cc: cve-editorial-board-list <cve-editorial-board-list@lists.mitre.org>
Subject: RE: Current standards/criteria for 'Undefined Behavior'

 

We're making it an agenda item for the next Board call.

 

Chris Levendis

Sent with BlackBerry Work
(www.blackberry.com)

From: Millar, Thomas <Thomas.Millar@hq.dhs.gov>

Date: Thursday, May 11, 2017, 4:45 PM

To: Carsten Eiram <che@riskbasedsecurity.com>, Adinolfi, Daniel R <dadinolfi@mitre.org>

Cc: cve-editorial-board-list <cve-editorial-board-list@lists.mitre.org>

Subject: RE: Current standards/criteria for 'Undefined Behavior'

 

I tend to agree with Carsten here but I assume a response further explaining the CVE Team’s reasoning is being drafted already.

 

From: owner-cve-editorial-board-list@lists.mitre.org [mailto:owner-cve-editorial-board-list@lists.mitre.org] On Behalf Of Carsten Eiram
Sent: 11 May, 2017 07:19
To: Adinolfi, Daniel R <dadinolfi@mitre.org>
Cc: cve-editorial-board-list <cve-editorial-board-list@lists.mitre.org>
Subject: Re: Current standards/criteria for 'Undefined Behavior'

 

I hope the new MITRE CVE team realizes they are in a minority of people in this industry, who actually consider such issues as being CVE worthy by default or even security-relevant without some proof of there being a (realistic) security impact.

 

Referencing Hanno Böck and Agostino Sarubbo of all people does not lend a lot of "street cred" or underline the point. These guys are fairly inexperienced when it comes to vulnerability research and focus on fuzzing with AFL. One of them (Hanno) until recently didn't even really understand the output; the other still struggles.

 

We do not disagree that issues leading to undefined behaviour _theoretically_ have a security impact. Rarely is it ever proven, though. In fact, I don't think Agostino Sarubbo (or Hanno for that matter) has proven a single of the UBSan issues, which he has reported many of, actually did have a real-world impact.

 

Most experienced people in this industry have historically expected some reasonable indication of a security impact that was not too theoretical. There is a reason for us not seeing these types of reports from experienced researchers, who are also fuzzing using AFL. Even the OSS-Fuzz project flags UBSan issues as "Bug" and not "Bug-Security" by default. Sure, they should be fixed for good measure and are bad coding practice, but even developers generally don't treat the fixes as security-relevant. And rightly so.

 

MITRE is humoring beginners, who are fuzzing and just dumping their UBSan output without doing minimal due diligence; it would be better to educate them to higher standards i.e. the standards of most vulnerability researchers as well as the old MITRE CVE team. Otherwise, I hope the new MITRE CVE team is wearing their track pants and are on top of their cardio. You'll need some excellent stamina when taking on the CVE assignments for the metric ton of UBSan issues you'll be dealing with, if that is your default position.

 

/Carsten

 

 

On Wed, May 10, 2017 at 4:04 PM, Adinolfi, Daniel R <dadinolfi@mitre.org> wrote:

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