Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 07 Oct 2014 14:15:24 -0400
From: Chet Ramey <>
To: mancha <>,
Subject: Re: Shellshocker - Repository of "Shellshock" Proof
 of Concept Code

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.

> An effect few mention is how dramatically things changed post-embargo.
> Sure, Chet's been burning the midnight oil (many thanks, Chet; you're
> owed many beers) but on some level, or maybe only after the dust
> settles, he'll be very appreciative of the way the community rallied in
> a highly dynamic way to ultimately help make Bash a better product.

Don't get me wrong: while I was working on the bash patches I
appreciated -- and I still appreciate -- this community's contributions.
I think the additional eyes, and additional tools, this group brought to
the effort played a large part in making it, in my mind, successful.

> From the identification of key breach points (thanks Stephane, Tavis,
> and Michal) to the development of critical hardening (thanks Florian),
> the level of engagement has been, and continues to be, extraordinary.

Agreed.  While there are remaining technical issues with how the situation
sorted itself out that I will have to deal with, for example

they were the result of uncoordinated work, not the amount of work.

The signal/noise ratio of this community's contributions was extraordinary.

> 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.

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.

> It's amazing how productive people can be when incentives are properly
> aligned.
> 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.

``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU

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.