Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 28 Jun 2019 13:08:12 -0400
From: Sasha Levin <>
Subject: Re: linux-distros membership application - Microsoft

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:
>> .
>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
><> 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:
>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:
>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: 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:
>> >
>> >
>> >
>> >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
>>  ( would be
>>  relevant for all our offerings.
>> - Core libraries affect us as well, for example CVE-2017-1000408
>>   ( 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
>>   ( 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-5391, CVE-2018-5390:
CVE-2019-11477, CVE-2019-11478, CVE-2019-11479:

>> Sure, we'd love to help with the list's pain points.
>> >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)"
>> >
>> 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@.../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. 


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.