Date: Fri, 28 Jun 2019 14:57:43 +0200 From: Solar Designer <solar@...nwall.com> To: oss-security@...ts.openwall.com Subject: Re: linux-distros membership application - Microsoft On Thu, Jun 27, 2019 at 01:05:08PM -0400, Sasha Levin wrote: > email@example.com is not a disclosure list, but > rather just a way to pull in kernel folks to fix issues. Some (most?) of > the kernel bugs that get fixed don't go through that list to begin with. "Some (most?) of the kernel [security] bugs that get fixed don't go through" linux-distros as well. > The kernel's documentation with regards to security issues and > disclosure actually points to linux-distros: > https://www.kernel.org/doc/Documentation/admin-guide/security-bugs.rst . I'm not entirely happy with the wording used there, which currently is: --- Fixes for sensitive bugs, such as those that might lead to privilege escalations, may need to be coordinated with the private <linux-distros@...openwall.org> mailing list so that distribution vendors are well prepared to issue a fixed kernel upon public disclosure of the upstream fix. Distros will need some time to test the proposed patch and will generally request at least a few days of embargo, and vendor update publication prefers to happen Tuesday through Thursday. When appropriate, the security team can assist with this coordination, or the reporter can include linux-distros from the start. In this case, remember to prefix the email Subject line with "[vs]" as described in the linux-distros wiki: <http://oss-security.openwall.org/wiki/mailing-lists/distros#how-to-use-the-lists> --- This says that "Distros [...] will generally request at least a few days of embargo", but the actual policy of (linux-)distros is that the reporter must provide a tentative public disclosure date/time in their very first message. Also, this doesn't say that by disclosing something to (linux-)distros the reporter accepts the list's policy, and leaves actually reading that wiki page with the policy optional. I don't readily have suggested edits, but we should address these issues somehow. Please feel free to suggest edits. On a related note, this might not be representative, but I ran a Twitter poll on days of week for vulnerability disclosures: https://twitter.com/solardiz/status/923885360001757185 Poll: What days of week work best for you for public disclosure by others of vulnerabilities in software you (or your employer, etc.) use? 23% No preference or Other 33% Mon 36% Tue, Wed, Thu 8% Fri, Sat, Sun 164 votes 12:13 PM - 27 Oct 2017 As you can see, Mon fared really well - almost same as Tue, Wed, Thu combined, meaning that it might be _the_ preferred day of week for vulnerability disclosures. So we probably shouldn't exclude Mondays. > To complicate your question further: the Linux usage on our cloud has > surpassed Windows, as a by-product of that MSRC has started receiving > security reports of issues with Linux code both from users and vendors. > It's also the case that issues that are common for Windows and Linux > (like those speculative hardware bugs) are shared with us via MSRC as > well. > > If you think that there's value in connecting between these 3 > entities, I'd be happy to do so (maybe as part of a new task). I'm not sure. The microarchitectural "bugs" would have been inappropriate to bring to the distros list earlier than in 14 days prior to their public disclosures, and I don't know if the public disclosure dates on those were specific enough to achieve that. Maybe you know? > >It'd be helpful if you could directly address this part: "including some > >that had been handled on (linux-)distros, meaning that membership would > >have been relevant to you". Without such examples yet, we'd have to be > >guessing whether the membership would have been relevant to you or not. > > > >Right now, the statistics at: > > > >https://oss-security.openwall.org/wiki/mailing-lists/distros/stats > > > >only go until the end of 2018, so you'd be able to use them for examples > >dating back to 2018 and earlier. We should ask Gentoo to update these > >statistics soon, perhaps for period until end of June 2019, which will > >be possible soon. > > Sure! Issues on the stats page that would not have been reported to MSRC > but are relevant to us would include: > > - On the kernel side, issues such as CVE-2017-7533 > (https://www.openwall.com/lists/oss-security/2017/08/03/2) would be > relevant for all our offerings. > > - Core libraries affect us as well, for example CVE-2017-1000408 > (https://www.openwall.com/lists/oss-security/2017/12/11/4). This > would affect our Sphere and SaaS offerings, as well as probably make > us run through them through test gauntlet for WSLv2. > > - Higher level Linux tools, such as the one in CVE-2018-14722 > (https://www.openwall.com/lists/oss-security/2018/08/14/7) affect > mostly our IaaS offerings, but I expect that we'd again validate the > rest of our offerings with the fix. Thanks! Ideally, you'd also demonstrate that Microsoft fixed those issues (where relevant) within days of their public disclosure (so that some days of advance notice would have made a difference). Can you? Or are you merely pointing out the kind of issues that would have been relevant to you and presumably fixed promptly now, but were not relevant and thus were not fixed back then? That's less than ideal if so. > Sure, we'd love to help with the list's pain points. Great! > >The lack of a volunteer distro for Administrative "4. Evaluate relevance > >to other parties ..." came up e.g. here: > > > >"Linux kernel: Bluetooth: two remote infoleaks (CVE-2019-3459, > >CVE-2019-3460)" > >https://www.openwall.com/lists/oss-security/2019/01/11/2 > > This could be interesting for us. we already work closely with multiple > distros as part of our public IaaS offering, as well as my work > maintaining the stable tree means I interact often with many subsystem > maintainers. We could leverage that for this task. > > I think that this task would also benefit from collaboration with MSRC, > where for example we could verify whether the Bluetooth issue you brought > up would affect Windows, and whether issues reported to MSRC also affect > Linux. If Microsoft joins for its Linux offerings (including Linux on top of Windows), then checking if the Linux issues also affect Windows (itself) would involve sharing beyond the need-to-know condition of (linux-)distros list policy, so isn't allowed by default. It could still be done with explicit approval of the reporter, though, and I expect most people would give such approval if asked. 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.