[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190628125743.GA2187@openwall.com>
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:
> 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.
> 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.
