[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141002032943.GA27000@openwall.com>
Date: Thu, 2 Oct 2014 07:29:44 +0400
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Cc: Chet Ramey <chet.ramey@...e.edu>
Subject: Re: More parser odities
On Wed, Oct 01, 2014 at 07:44:38PM -0700, Michal Zalewski wrote:
> > Maybe it's just the right opportunity to do that, instead of assigning
> > yet another CVE to Michal's latest finding? Oh, I think Michal's
> > latest already got a CVE too? Does this once again render the
> > (previously) exposed parser not CVE-worthy? ;-(
>
> Whoa :-) So to be clear, I felt that it makes sense to ask for CVEs
> and report these externally because up until that point, we had no
> conclusive evidence that the original patch is truly inadequate, and
> that Florian's patch is anything more than a nice-to-have that several
> people on oss-security are fond of. Tavis' EOL find was troubling, but
> fixed upstream with a one-liner in bash43-026, not with Florian's
> patch.
>
> (In fact, Florian's patch wasn't upstreamed when I started fuzzing the
> parser and hit the bugs.)
Sure. I absolutely didn't imply that you did anything wrong. You have
helped a lot!
I had at least as much opportunity to insist on a different approach
early on, including to CVE assignments (and I regret I did not; to me,
those CVEs don't matter much, but clearly they do to a lot of people).
What I meant is that with hindsight maybe we could have done better, by
using whichever parser bug as an opportunity to request a CVE ID for the
parser being exposed instead. A lot of people primarily look at CVEs,
and might miss the most important patch when it's not associated with
any CVE ID.
Maybe you fuzz yet another RCE bug, and we request a CVE ID for the
parser being exposed then? ;-)
Or maybe the CVE powers that be will find the parser being exposed
CVE-worthy without yet another PoC, especially given that upstream
already has a fix issued? If such a CVE is issued, I'd happily refer
primarily to it instead of to all the other recent bash CVEs.
> Anyway, I think that the confusion stemmed mostly from fairly
> inaccurate "vanity" pages, news articles, and "vulnerability checkers"
Perhaps, but (in hindsight) we should have expected that and maybe we
could have worked around it. Maybe a lesson for next time when a
combination of important potential "hardening" change and "unimportant"
individual bug fixes comes up, in any software project.
> At this point, it definitely makes no sense to keep assigning CVEs to
> additional prefix-requiring problems in the parser at this point,
Right.
> since hopefully everybody got the message to upgrade.
Yeah, I hope no one installing a newer CVE-assigned parser bug upstream
patch will happen to skip the prefix/suffix upstream patch. The fact
that these patches are numbered helps a lot here. And I hope distros
got the message, and will include a prefix/suffix patch too (many
already did).
Yet a CVE ID for the parser previously having been exposed still makes
sense to me.
Alexander
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.
