[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20141104093909.1CB9C52E08D@smtpvbsrv1.mitre.org>
Date: Tue, 4 Nov 2014 04:39:09 -0500 (EST)
From: cve-assign@...re.org
To: oss-security@...ts.openwall.com
Cc: cve-assign@...re.org
Subject: Re: strings / libbfd crasher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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.]
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.]
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@...me.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. 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.
- --
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)
iQEcBAEBAgAGBQJUWJ02AAoJEKllVAevmvmseDEIALTyzs7kgLcf7Tc5kQS3ppNf
5w7iGJFmcWtP5N/LrEM0ZfPBtH4biT6VUo28ZbC4cX6zmZ0w9C3WvRGGDY+MCJHI
4wZefBjssqrXL0cyNape3YXjTwCEpXA7IOt0isX/38rUx5sLMsBUSrvdHlplnBtJ
v9zII+yvG0me53KUelNKWdqZaDCvFSL9qLtu+bptA8SPK9wYnRKYxsOZcq4UCqdW
/+bkZT4kUYVSw9slXdMw0vQucn0F2CjqjqYII/LAbeLVfiBwAKvzziImWwGSbwf8
xnC1kBlJhJTQAnRJtLN1eJwV05st3krr/a09ZwoHizQwQ/HpkDGCPV24VjVFbpc=
=3dwk
-----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
