[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20170531121432.GA8671@openwall.com>
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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
