oss-sec mailing list archives
Re: Re: strings / libbfd crasher
From: Michal Zalewski <lcamtuf () coredump cx>
Date: Mon, 3 Nov 2014 17:07:52 -0800
Well, I think that for most part, they are just trying to do their best based on the limited information and limited time they can spend on every report. If you care about CVEs being assigned only for meaningful security issues, it's good to research practical exploitability first, or help them evaluate other public reports if they seem unclear. If you don't care about it... well, that's a perfectly valid stance :-) There's a bit of weirdness around assigning CVEs to groups of issues ("multiple crashes with evidence of memory corruption"), not assigning them to proactive security improvements (e.g., the Shellshock thing); but ultimately, they are just a tool (mostly for looking up original patches and advisories later in the game), and most of the situations where they are relied on for something more (e.g., comparing the security of competing software) are misguided. On Mon, Nov 3, 2014 at 1:52 PM, mancha <mancha1 () zoho com> wrote:
On Mon, Nov 03, 2014 at 01:43:54AM +0300, Alexander Cherepanov wrote:On 2014-10-31 08:57, cve-assign () mitre org wrote: Thanks for assigning CVEs for these issues but I have a couple of questions regarding CVE-worthiness of various things. And some questions for the community.Use CVE-2014-8502 for the objdump-pe-crasher2 issue.Here, AddressSanitizer said "heap-buffer-overflow" and then "READ of size 1". Why this crasher is judged as CVE worthy? Is it oversight or are invalid reads assumed to be exploitable by default? Another possibility is to treat all crashes in all libraries as CVE worthy. We don't know how these libraries are used ITW and any crash in any of them could potentially lead to data loss in some application. But... ...it seems libbfd is not treated as a library any crash in which is CVE worthy.Use CVE-2014-8503 for this ihex parser issue.Again "READ of size 1".Thanks for your post. I would also find it instructive if MITRE shed light on its CVE assignation heuristics for libbsd. Response to libbfd issues can be particularly enlightening because the issues vary largely in scope & type. In the past, I've noticed a liberal approach to CVE allocation when dealing with libraries due to what you said: it is often difficult to assess the security impact of flaws because they ultimately depend on the context of applications using the library. As case in point, the NULL pointer dereference crasher (zero-size S-record) DoS'es manchabfd 0.42a1 (small network daemon I just wrote). That flaw didn't receive a CVE. --mancha unedited post: http://www.openwall.com/lists/oss-security/2014/11/02/4
Current thread:
- Re: Re: strings / libbfd crasher, (continued)
- Re: Re: strings / libbfd crasher Jann Horn (Nov 02)
- Re: Re: strings / libbfd crasher Alexander Cherepanov (Nov 04)
- Re: Re: strings / libbfd crasher Michal Zalewski (Nov 04)
- Re: Re: strings / libbfd crasher Alexander Cherepanov (Nov 11)
- Re: Re: strings / libbfd crasher Michal Zalewski (Nov 11)
- Re: Re: strings / libbfd crasher Michal Zalewski (Nov 11)
- Re: Re: strings / libbfd crasher Alexander Cherepanov (Nov 15)
- Re: Re: strings / libbfd crasher Michal Zalewski (Nov 15)
- Re: Re: strings / libbfd crasher Alexander Cherepanov (Nov 15)
- Re: Re: strings / libbfd crasher mancha (Nov 03)
- Re: Re: strings / libbfd crasher Michal Zalewski (Nov 03)
- Re: Re: strings / libbfd crasher mancha (Nov 03)
- Re: strings / libbfd crasher cve-assign (Nov 04)
- Re: Re: strings / libbfd crasher Alexander Cherepanov (Nov 04)
- Re: Re: strings / libbfd crasher mancha (Nov 05)
- Re: Re: strings / libbfd crasher Alexander Cherepanov (Nov 04)
- Re: strings / libbfd crasher cve-assign (Nov 12)
- Re: Re: strings / libbfd crasher Michal Zalewski (Oct 26)
- Re: Re: strings / libbfd crasher Michal Zalewski (Oct 27)
- Re: Re: strings / libbfd crasher Jakub Wilk (Oct 27)