Re: Re: strings / libbfd crasher

[Alexander Cherepanov <cherepan () mccme ru>]

On 2014-11-04 12:39, cve-assign () mitre org wrote:
> Four of the main factors that affect libbfd CVE assignments are:
>
>    1. existence of a "multi-session" use case
>    2. discussion of exploitability of a specific attack vector
>    3. likelihood of exploitability of classes of observed behavior
>    4. actual or expected volume of distinct discoveries
>
> We'll try to give an example of each of these.
>
> 1. existence of a "multi-session" use case
>
> One situation in which libbfd code is executed is running the strings
> program. We consider that a "single-session" use case. Unless
> arbitrary code execution occurs, the principal impact of a crash is
> that the strings program doesn't produce the desired output, and we
> don't consider that to be within the scope of what "denial of service"
> means. [Obviously there could be exceptions, e.g., the way in which
> the libbfd code crashes causes especially severe resource consumption.
> These exceptions are probably rare.]

I guess just eating tens of gigabytes of memory (in a small or in a big 
number of blocks) doesn't qualify? It's easy to get such samples for 
binutils.

And according to 
https://sourceware.org/bugzilla/show_bug.cgi?id=17512#c45 some infinite 
loops actually eat memory:

| The loop would have ended eventually - when your machine ran out of
| memory. :-)

> If all known use cases for a library are single-session use cases,
> then the existence of a crash is not sufficient for a CVE assignment.
> Specifically, we would exclude any attack vector that is not thought
> to lead to arbitrary code execution.
>
> In the multi-session case, a "session" could be roughly defined as "a
> persistent interface for interactive access to data from a single
> source."
>
> It's conceivable that libbfd code is incorporated into a multi-session
> GUI malware forensics tool. For example, there could be a scenario in
> which the malware analyst has 10 windows open, each showing a
> carefully chosen point within one malware sample, along with
> (possibly) data-entry windows containing analyst notes. Next, suppose
> the analyst loads an 11th malware sample that triggers a libbfd bug.
> Then, the entire forensics tool crashes, and all of the data and state
> is irrecoverably lost (i.e., more than one "session" is abruptly
> terminated). A denial of service has occurred, and ideally there would
> be an associated CVE ID for that libbfd bug.
>
> Currently, we don't happen to know of the existence of that type of a
> multi-session program that relies on libbfd, and has that type of
> outcome upon encountering a libbfd crash bug. If we did know of such a
> program then, ideally, every crash bug would have an associated CVE
> ID.
>
> [They might not all have different CVE IDs. For example, we would
> typically combine two observations that were both use-after-free
> issues, affecting the same versions of GNU Binutils, and reported on
> the same day by the same person.]

"the same day" is kinda vague. In which timezone?
It's not yet an actual question but the last two links for readelf (see 
below) are quite close. Depending on timezone they could have different 
dates.

Judging from the rest of your email, I guess "the same day" should be 
read as something informal which helps to group issues together by 
proximity in time.

> 2. discussion of exploitability of a specific attack vector
>
> This relates to what "is not thought to lead to arbitrary code
> execution" means. If there's any credible statement about this type of
> non-exploitability, then there typically isn't a CVE ID assignment.
> Obviously, this is open to interpretation: a specific wording could be
> used by one credible person to mean "writing an exploit is probably
> impossible" and that same wording could be used by another credible
> person to mean "it's possible to write an exploit program that
> sometimes works, but it's prohibitively difficult to write a reliable
> exploit program."
>
>
> 3. likelihood of exploitability of classes of observed behavior
>
> Currently we think that the likelihood of exploitability is too low
> for a libbfd NULL pointer dereference, and those cases are excluded
> from CVE. We don't think that the likelihood of exploitability is
> always too low for every libbfd out-of-bounds read. Either of these
> could be revised based on better information about how libbfd
> interacts with memory.
>
>
> 4. actual or expected volume of distinct discoveries
>
> > From: Alexander Cherepanov <cherepan () mccme ru>
> > Subject: Re: [oss-security] Re: strings / libbfd crasher
> > Date: Mon, 03 Nov 2014 01:43:54 +0300
>
> > Simple fuzzing of objdump with zzuf (not even afl) quickly gives out
> > tens and hundreds of different cases of mentioned errors
>
> Suppose there were hundreds of different cases: for example, 200
> different people ran zzuf and found 200 unique ways to cause
> out-of-bounds reads.

Or one men releasing one way to cause out-of-bounds reads a day for 200 
days:-)

> Then, it would be unrealistic for us to provide
> 200 unique CVE IDs, even though that would match the currently
> advertised per-discoverer level of abstraction for CVE. This does not
> mean that any specific unanalyzed out-of-bounds read is ineligible for
> a CVE ID: it just means that, as a practical matter, it is unlikely
> that those 200 CVE IDs would ever be assigned.
>
> In that situation, the level of abstraction of CVEs would probably be
> reduced to the level of abstraction of vendor releases with fixes,
> e,g., issues resolved in Binutils 2.26 would have a different CVE ID
> than issues resolved in 2.27.
>
> We're not able to offer a comprehensive set of guidelines such that,
> even if there were an arbitrarily large number of findings satisfying
> the guidelines, it is guaranteed that each finding would map to a CVE
> ID that is anchored on the problem report rather than anchored on the
> fix announcement.

Thanks a lot for your detailed response. It much clearer now.

You could also like to take a look at the following reports:

- ~40 samples leading to >10 crashes of `objdump -x` with distinct call 
stacks and triggering >50 distinct invalid reads on the way:
https://sourceware.org/bugzilla/show_bug.cgi?id=17512#c49
https://sourceware.org/bugzilla/show_bug.cgi?id=17512#c54

- ~20 samples leading to ~10 crashes of `readelf -a` with distinct call 
stacks and triggering ~100 distinct invalid reads on the way:
https://sourceware.org/bugzilla/show_bug.cgi?id=17531#c0
https://sourceware.org/bugzilla/show_bug.cgi?id=17531#c6
https://sourceware.org/bugzilla/show_bug.cgi?id=17531#c10

IIRC in all these cases valgrind shows only invalid reads and similar 
errors (no invalid writes). Not sure how it influences your analysis of 
potential exploitability.

--
Alexander Cherepanov