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.