[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 17 May 2022 13:52:21 +0200
From: Greg KH <greg@...ah.com>
To: oss-security@...ts.openwall.com
Cc: Seth Arnold <seth.arnold@...onical.com>
Subject: Re: linux-distros list policy and Linux kernel
On Tue, May 17, 2022 at 01:10:16PM +0200, Jason A. Donenfeld wrote:
> This brings us back to the original topic of this (sub-)thread: do
> public fixes make security vulnerabilities manifest to the public? I
> guess it depends on who you consider to be the public. If you're
> speaking from the perspective of placating customers and taking care of
> some commercial bottom line, the answer is no. No public PR situation
> coming your way, so no work to be done, vulnerability doesn't exist yet.
> But if you're speaking from the perspective of whether attackers now are
> aware of the bug and can write exploits for it -- that is, a real threat
> model -- then the answer is obviously yes, if the fix is public, the bug
> is public.
>
> So when I read in this thread calls for extending embargoes until the
> vulnerability is "disclosed" in some sort of announcement (that is, PR),
> rather than just until the public git fix, it seems plain that the end
> goal is a messaging or communication one, rather than a security one. On
> the surface, delaying the release of a vulnerability until it's had time
> to reach customer systems sounds like a good idea. But zoom in a little
> bit and you quickly realize that the vulnerability has *already* been
> released to attackers who read commit logs, and the thing we're talking
> about delaying is an official announcement. It turns out, attackers
> don't care about your official announcements; the marketing team does.
As you know, there are different "grades" of attackers. There's a huge
range from "run metasploit that I just downloaded" to "look at this
kernel change and figure out how to abuse the system that does not have
it". By delaying a small bit of time from publically posting a patch to
telling the world that "hey, that was a security fix over there" that
allows the community that works in the public added time for review and
testing as our testing infrastructure that is NOT public is quite
limited and reviews are limited given the huge range of needed
developers to do that review.
That delay can allow users to have the fix on their system first before
the "metasploit" package is updated to attack it, which reduces the
amount of vulnerable systems out there. Yes, it does not solve the
"prevent readers of all commits" issue, but I don't know what we can
really do about that except switch to a closed source development model,
which isn't a good thing overall anyway.
So it's just a delay, not a "never disclose" issue here. Is a delay
good or not? Personally I think it is, but as you say here, others
might not think so.
> And as I understand it, the Openwall mailing lists have never been about
> enabling companies to better control their messaging. They've been about
> a deterministic embargo & disclosure process, to strike the right
> balance of letting people coordinate privately when needed, and then
> letting various parties make the best decisions they can once the cat is
> out of the bag. Should the distros@ policy change to be more PR-friendly,
> or should it stay true to its security policy ideals?
I don't think it's a "PR-friendly" issue here, it's about how best to
develop and ship secure systems as that's what the linux-distros members
are responsible for. The linux-distros group needs to talk about this
and come up with what they are going to do for this issue as it is their
members that has to define their ideals and how to follow them best.
thanks,
greg k-h
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.
