Date: Wed, 31 May 2017 14:14:32 +0200 From: Solar Designer <solar@...nwall.com> To: oss-security@...ts.openwall.com Cc: Qhdwns123 <qhdwns123@...tonmail.com> Subject: Re: I found Crash in tcpdump and radare2. On Wed, May 31, 2017 at 01:16:15PM +0200, Hanno B??ck wrote: > On Wed, 31 May 2017 06:39:12 -0400 Qhdwns123 <qhdwns123@...tonmail.com> wrote: > > > I found Crash in tcpdump and radare2. > > > > It points to the heap overflow as the result of analysis by ASAN. > > > > What steps should I take to report this issue? > > Please report the issues first to their respective developers and > provide the crashing files to them. > > tcpdump has a contact address for security issues: > http://www.tcpdump.org/#security > > I think radare2 has no specific security reporting process, you can > report it through their github tracker: > https://github.com/radare/radare2/issues > > When the bugs are fixed you can post details to this list. Thanks, Hanno! My opinion, both personal and as oss-security list admin: It is rarely sensible to delay posting the detail to oss-security until the bugs are fixed - e.g., what if a bug is never fixed upstream? We would still like to have the detail here - in fact, the detail should be in here no later (or not much later - e.g., same day) as it's made public elsewhere. So if a bug report to an upstream project is made via a public GitHub issue (as may need to be the case for radare2, and that's fine), the detail should also be posted in here at about the same time, please. For tcpdump, it may be OK to give the upstream some sane amount of time, like 7 or 14 days, but to notify them of this limited time along with the initial notification, and to post the detail to oss-security when the bug is fixed or when the time runs out, whichever occurs first. Also, ask the upstream whether they expect to have a fix within the offered amount of time - if not, then post right away. I don't know if the tcpdump project specifically is able to fix bugs reasonably fast - what was the precedent so far? If not, then no point in giving them any advance notice (but you should notify them anyway, along with making the issue public). I am speaking about notifying upstreams in general, using this as an example. Frankly, for the few issues I brought in here myself, I sometimes happened to give upstreams too much time or/and to discuss those issues in other public places for a while. However, this is merely how it happened, for reasons including my own lack of time to stay on top of issues and because of initially unclear nature of some issues (e.g., security or not?) As I wrote above, I think that ideally if an issue is already being discussed in public elsewhere (such as with upstream), it should also be in here at the same time, and for issues reported to upstreams privately the amount of time offered should quite limited. Alexander
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ