oss-sec mailing list archives
Re: linux-distros membership application - Microsoft
From: Sasha Levin <sashal () kernel org>
Date: Fri, 28 Jun 2019 13:08:12 -0400
On Fri, Jun 28, 2019 at 02:57:43PM +0200, Solar Designer wrote:
On Thu, Jun 27, 2019 at 01:05:08PM -0400, Sasha Levin wrote:security@k.o 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.
True, but we care about more than just the kernel side of things.
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 () vs 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.
Can I suggest that we fork the discussion around security-bugs.rst to LKML? I can suggest an initial patch to address your comments here but I think that this is better handled on LKML.
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.
My concern with Monday is timezones: we should do the math here, but I'd like to avoid spilling over to Sunday (or very early Monday for that matter) for some timezones.
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?
As far as I understand specific dates for the microarchitectural bugs were set pretty late in the process. It's not just the microarchitectural bugs I was referring to, we are getting security reports from users about security bugs in various distros and we end up circling back with relevant distros to patch them up. A recent example would be: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1834499 where an internal user has reported a kernel memory leak due to a missing patch in Ubuntu.
>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.
Microsoft's history with Linux is a rather recent one. I can offer the following examples if you're willing to give us a few months off of the "1 year" requirement: CVE-2018-1002105: https://azure.microsoft.com/en-us/updates/aks-clusters-patched-for-kubernetes-vulnerability/ CVE-2018-5391, CVE-2018-5390: https://azure.microsoft.com/en-us/blog/security-bulletin-for-august-2018/ CVE-2019-5736: https://azure.microsoft.com/en-us/updates/iot-edge-fix-cve-2019-5736/ CVE-2019-11477, CVE-2019-11478, CVE-2019-11479: https://azure.microsoft.com/en-us/updates/security-advisory-on-linux-kernel-tcp-vulnerabilities-for-hdinsight-clusters/
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.
I'd love to develop a framework that would allow for sharing of reports between linux-distros/security@k.o/MSRC given the explicit approval of the reporter. I think that the current "silo" model is broken. Microsoft in general, and MSRC in particular have proved during Meltdown/Spectre that they are a trusted entity which can work well withthe open source community to advance our common goals.
-- Thanks, Sasha
Current thread:
- Re: linux-distros membership application - Microsoft, (continued)
- Re: linux-distros membership application - Microsoft Greg KH (Jun 27)
- Re: linux-distros membership application - Microsoft Solar Designer (Jun 27)
- Re: linux-distros membership application - Microsoft Greg KH (Jun 27)
- Re: linux-distros membership application - Microsoft Tyler Hicks (Jun 27)
- Re: linux-distros membership application - Microsoft Greg KH (Jun 27)
- Re: linux-distros membership application - Microsoft Greg KH (Jun 27)
- Re: linux-distros membership application - Microsoft Anthony Liguori (Jun 27)
- Re: linux-distros membership application - Microsoft Tyler Hicks (Jun 27)
- Re: linux-distros membership application - Microsoft John Haxby (Jun 27)
- Re: linux-distros membership application - Microsoft Sasha Levin (Jun 27)
- Re: linux-distros membership application - Microsoft Solar Designer (Jun 28)
- Re: linux-distros membership application - Microsoft Sasha Levin (Jun 28)
- Re: linux-distros membership application - Microsoft Simon Lees (Jun 30)