Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 4 Aug 2017 11:07:40 -0600
From: Kurt Seifried <kseifried@...hat.com>
To: oss-security <oss-security@...ts.openwall.com>
Cc: willemdebruijn.kernel@...il.com, Dmitry Vyukov <dvyukov@...gle.com>, 
	Kostya Serebryany <kcc@...gle.com>
Subject: Re: Reporting and disclosing Linux kernel vulnerabilities

On Fri, Aug 4, 2017 at 10:59 AM, Andrey Konovalov <andreyknvl@...il.com>
wrote:

> Hi!
>
> It's not completely clear to me how to properly report and disclose
> Linux kernel security issues. There are a few different parties [1, 2,
> 3] that need to be informed and coordinated. I couldn't find a
> publicly available actionable list of steps, so I've outlined it as I
> see it here:
>
> https://github.com/google/syzkaller/blob/master/docs/
> linux_kernel_reporting_bugs.md#reporting-security-bugs
>
> Thoughts? Comments?
>

I would strongly suggest that people notify distros@ (keeping in mind it
has a 2 week embargo limit, so if you need more than that, don't notify
distros@ until you are ready) and notify the Kernel (we want this fixed
upstream too,obviously, but also keeping in mind that they have a 1 week
embargo limit, so if you need more than that, don't notify the Kernel until
you are ready). Another option it to notify a vendor such as Red Hat (
secalert@...hat.com) or SUSE (security@...e.com) as we can handle things in
house (we have kernel devs/etc) and we know whom to notify at other vendors
as needed (e.g. Debian, Ubuntu, etc.) and can hold embargoes as needed
(although typically we don't like long embargoes either, I would say 4-5
weeks absolute max ideally).

Another benefit of notifying the vendors/distros is we can help with the
coordination and notification, CVEs, etc. Kernel upstream basically just
fixes it and moves on (which is legitimate, it's not their job to make sure
every possible downstream gets notified*)

[*] although it would be nice if this stuff gets a CVE and the CVE gets
used, then people know to pay attention to those commits/etc.


>
> Thanks!
>
> [1] https://www.kernel.org/doc/html/latest/admin-guide/security-bugs.html
>
> [2] http://oss-security.openwall.org/wiki/mailing-lists/distros
>
> [3] http://oss-security.openwall.org/wiki/mailing-lists/oss-security
>



-- 

Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: secalert@...hat.com

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.