oss-sec mailing list archives
Re: Aftershock (was: Shellshocker - Repository of "Shellshock" Proof of Concept Code)
From: mancha <mancha1 () zoho com>
Date: Wed, 8 Oct 2014 18:37:12 +0000
On Tue, Oct 07, 2014 at 02:15:24PM -0400, Chet Ramey wrote:
On 10/7/14, 2:46 AM, mancha wrote: Please take my comments as the perspective of someone who only interacts with this group peripherally. That may or may not give them value.
Hi Chet. Many thanks for your thoughtful response. Any discussion about shellshock lessons learned would be incomplete without your input.
I don't know how long the initial report was embargo'd but I'm pretty sure the process became infinitely more productive after the veil of semi-secrecy was lifted (be it in metrics like LoC/hour or reports/day).It was almost two weeks. I figured out the initial fix within hours, and as far as I know, the rest of the embargo time was spent preparing vendor patches and deciding on the logistics of notification. From my perspective, that process was opaque, including the set of vendors that was notified.
Taking "within hours" to mean 4 for argument's sake, gives about a 1.2% to 98.8% breakdown of embargo time spent developing a fix versus all else. Striking.
I guess whether or not the process `became more productive' is debatable. Again from my perspective, it became clear that Florian's function name mangling approach was the way to go once Tavis reported the second parser problem. However, since I don't do this work for a living, I had to wait until the weekend to do it. There's nothing about the process that would have improved that. If you assume that `infinitely more productive' means that there were more bug reports against the parser and other code, then sure, there were more bug reports after the initial disclosure. You can, and should, ignore LoC as a metric. None of these fixes took more than a couple of dozen lines of code. The longest by far was the function name mangling patch, and that didn't directly address a vulnerability. Frankly, if you want to improve the process, we should all get better at defining the boundary between CVE-worthy incidents and bugs. Once the function name mangling patch was released, which was by the third day after the initial disclosure, everything that followed was a shell bug. Without remote exploit possibility or local privilege escalation, you're just left with bugs. You can use CVE IDs as an incentive to get vendors to release patches and users to install them, and that's fine, but be transparent that that's what you're doing.
Maybe LoC is a poor metric but I don't want that to obscure the real message: the process's high dynamism post-disclosure. As you correctly point out, many recent parser flaws don't rise to the level of security concerns primarily because of the prefix/suffix barrier. However, it's important to point out that critical piece of hardening was a post-disclosure innovation and, more importantly, was triggered by post-disclosure findings and interaction. I've not given the CVE allocation process much thought but it has been discussed a bit in http://seclists.org/oss-sec/2014/q4/26.
Your solution is to add Tavis and Michal to distros@. What about the next flaw when the two researchers who turn out to be key are Bob and Fred? Add them next? You'll be playing catch-up.Isn't it generals who are always fighting the last war? It depends on what kind of community you're trying to build, and the form you want it to take. It's equally valid to say that researchers who have already done good work are likely to do more in the future.
I certainly agree it's reasonable to expect researchers like Stephane, Tavis, and Michal, who've been instrumental in the analysis & response of shellshock writ large, to prove valuable in future TBD security scenarios as well. My response was about how best to secure their (and others') involvement in a way that maximizes benefits. I perceived Alexander to be suggesting the answer is enlisting them pre-disclosure by adding them to a closed list. Maybe so. But, after having observed important dots only get connected post-disclosure, I see strong arguments in favor of earlier engagement of the broader security community. As happened with shellshock, this can unleash unanticipated synergies and provide an extensive and important sounding board. Once again, thanks for all your efforts. $ env BASH_FUNC_x%%='() { echo "--mancha"; }' bash -c 'x;'
Attachment:
_bin
Description:
Current thread:
- Re: Shellshocker - Repository of "Shellshock" Proof of Concept Code, (continued)
- Re: Shellshocker - Repository of "Shellshock" Proof of Concept Code Solar Designer (Oct 05)
- RE: Shellshocker - Repository of "Shellshock" Proof of Concept Code Sona Sarmadi (Oct 05)
- Re: Shellshocker - Repository of "Shellshock" Proof of Concept Code Kurt Seifried (Oct 05)
- RE: Shellshocker - Repository of "Shellshock" Proof of Concept Code Sona Sarmadi (Oct 06)
- Re: Shellshocker - Repository of "Shellshock" Proof of Concept Code Solar Designer (Oct 06)
- Re: Shellshocker - Repository of "Shellshock" Proof of Concept Code mancha (Oct 06)
- Re: Shellshocker - Repository of "Shellshock" Proof of Concept Code Solar Designer (Oct 07)
- Re: Shellshocker - Repository of "Shellshock" Proof of Concept Code mancha (Oct 07)
- Re: Shellshocker - Repository of "Shellshock" Proof of Concept Code Solar Designer (Oct 07)
- Re: Shellshocker - Repository of "Shellshock" Proof of Concept Code Chet Ramey (Oct 07)
- Re: Aftershock (was: Shellshocker - Repository of "Shellshock" Proof of Concept Code) mancha (Oct 08)
- Re: Aftershock Chet Ramey (Oct 09)
- RE: Shellshocker - Repository of "Shellshock" Proof of Concept Code Sona Sarmadi (Oct 07)