[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    Re: [oss-security] linux-distros membership application - Microsoft
From:       Sasha Levin <sashal () kernel ! org>
Date:       2019-06-28 17:08:12
Message-ID: 20190628170812.GG11506 () sasha-vm
[Download RAW message or body]

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 with
the open source community to advance our common goals. 

--
Thanks,
Sasha


[prev in list] [next in list] [prev in thread] [next in thread]