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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ