Date: Fri, 4 Aug 2017 19:36:58 +0200 From: Solar Designer <solar@...nwall.com> To: Andrey Konovalov <andreyknvl@...il.com> Cc: oss-security@...ts.openwall.com, 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 04, 2017 at 06:59:15PM +0200, Andrey Konovalov wrote: > 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 Thank you! I'm afraid the reality is that preferences vary, including even between different upstream developers. That said, we should in fact probably try to come up with guidelines similar to what you made a start at. Here are some assorted comments from me: Please inform oss-security as soon as the issue is made public, anywhere. There's no need to wait for a CVE, patch, nor anything to do that. If the issue is public, it must be on oss-security right away. You should add CVE, patch, etc. by "replying" to your own message later. This especially makes a difference in your "Reporting minor security bugs", where making the issue public is currently listed as step 1, and posting it to oss-security as step 3, with a potentially time-consuming step 2 inbetween (waiting for a CVE). Both must be part of step 1, or for clarity they may be steps 1 and 2 if there's expected to be no delay between them. In "Reporting major security bugs", you could make it clearer that there's no or little delay between notification to security@... and to linux-distros. As currently written, it is unclear whether you recommend to wait for security@... to come up with a patch before informing linux-distros. I hear that for netdev bugs, security@... is likely to ask you to post such bugs to the public netdev list right away, without any embargo. You could want to see whether this is in fact the case, and adjust your instructions if so. I don't know whether the CNAs on linux-distros have control to "make the CVE description public" as you suggest as one of the steps. This is a question to them - can they? I assume this means the description isn't available to MITRE nor anyone outside of linux-distros (and the distros' people with need-to-know) before that step. Just like in "Reporting minor security bugs", there should be almost no delays between the different public disclosure steps - CVE description, distros' updates, upstream commit, notification to oss-security. All of these should be on the same day, at worst. Perhaps clarify this. When you refer to linux-distros, please ask people to carefully read the distros list wiki page before sending anything to the list. They must be aware of list policy, and they must learn of the magic string to include in the Subject from there (do not list this magic string in your own instructions, though - just like you correctly don't do it now). The "good example" of oss-security posting that you refer to does in fact demonstrate a good oss-security posting, but it also demonstrates problematic handling of the issue before that point. Here's the timeline found in that message: 2016-11-28: Bug reported to security () kernel org 2016-11-30: Patch submitted to netdev, notification sent to linux-distros 2016-12-02: Patch committed to mainline kernel 2016-12-06: Public announcement "2016-11-30: Patch submitted to netdev" essentially means making the issue public. (I guess this is an instance of what I had meant above regarding netdev issues being forced to the public from security@....) After that time, there was no point in "notification sent to linux-distros" (which is for private issues only), and instead "2016-12-06: Public announcement" should have occurred on oss-security right away on 2016-11-30 (all linux-distros members are supposed to monitor oss-security). Keeping the issue "semi-"public like that is generally wrong. (I don't recall the details of why we let it happen the way it did for that one issue last year. My comments above are in general.) That's it for now. I'm sorry for not having a set of clear and simple edits to your current proposal, but I do hope this thread will result in a better "publicly available actionable list of steps", as you suggest. Thank you for working on it! >  https://www.kernel.org/doc/html/latest/admin-guide/security-bugs.html > >  http://oss-security.openwall.org/wiki/mailing-lists/distros > >  http://oss-security.openwall.org/wiki/mailing-lists/oss-security 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