[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALx_OUDVH400dWx72oLLUP49B788dzASuN9mHgBSMj8G95e6RQ@mail.gmail.com>
Date: Mon, 3 Nov 2014 17:07:52 -0800
From: Michal Zalewski <lcamtuf@...edump.cx>
To: oss-security <oss-security@...ts.openwall.com>
Cc: Assign a CVE Identifier <cve-assign@...re.org>
Subject: Re: Re: strings / libbfd crasher
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@...o.com> wrote:
> On Mon, Nov 03, 2014 at 01:43:54AM +0300, Alexander Cherepanov wrote:
>> On 2014-10-31 08:57, cve-assign@...re.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
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.
