Re: Re: strings / libbfd crasher

[mancha <mancha1 () zoho com>]

On Mon, Nov 03, 2014 at 05:07:52PM -0800, Michal Zalewski wrote:
> 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.

You're preaching to the choir; I highly value the good work they do. And
I am sensitive to the fact that assignments are sometimes made with
imperfect/incomplete information with time and other resource
constraints limiting the amount of analysis that can go into any given
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 :-)

I used Alexander's post as a springboard for a follow-up question. The
case of libbfd, because of the variation in the issues, can be
illuminating as to CVE allocation - broadly speaking.

But, my take differs from Alexander's. He seemed to be questioning the
justification of some of the libbfd CVE assignments. My preference, on
the other hand, is a more liberal approach to allocation when dealing
with libraries. My earlier email explains why.

Your reply made me worry my email came across as some kind of rebuke.
So let me go on record by saying that though not taxonomic by design,
the CVE project is an extremely valuable vulnerability tracking tool and
MITRE should be commended for their leadership in this area.  

> 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

Attachment: _bin
Description: