[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230828180518.GA29293@openwall.com>
Date: Mon, 28 Aug 2023 20:05:18 +0200
From: Solar Designer <solar@...nwall.com>
To: Willy Tarreau <w@....eu>
Cc: oss-security@...ts.openwall.com,
Vegard Nossum <vegard.nossum@...cle.com>,
Jiri Kosina <jkosina@...e.cz>, Donald Buczek <buczek@...gen.mpg.de>,
Greg KH <gregkh@...uxfoundation.org>
Subject: Re: linux-distros list policy and Linux kernel, again
Hi Willy,
Thank you for your helpful feedback and criticism.
I just noticed the recent ksummit list thread is also summarized by LWN:
https://lwn.net/Articles/941745/
In there, Johannes Segitz (SUSE, and a former linux-distros subscriber)
made a comment saying (among other things):
"I see the 14 day requirement by distros as the major problem in the way
it is currently run. I understand why solar designer insists on this (it
is really tricky to keep information private for any extended time), but
this then leads to people working around distros and distributing the
information up front, only to notify distros when it's basically already
solved and widely known."
I think people handling a complex issue more privately at first and only
notifying distros when no more than 14 days is left until planned public
disclosure is actually fine. I doubt all distros need to be involved in
early analysis and fixing of a complex issue e.g. in the kernel.
On Sun, Aug 27, 2023 at 09:57:07PM +0200, Willy Tarreau wrote:
> On Sat, Aug 26, 2023 at 12:23:59AM +0200, Solar Designer wrote:
> > In terms of (linux-)distros list policy, what can we do here? Accept up
> > to 7 days since fix is ready and thus accept arbitrarily long embargoes
> > and more likely have issues "requiring" such embargoes brought to the
> > list? BTW, for CPU microarchitectural issues, that would probably need
> > to be for the full distros list, not limited to Linux, and from what I
> > know disclosure timelines for such issues may be 3 to 12+ months.
>
> Please note that delays are not specific to hardware issues. We've had
> to work maybe 3 months with a reporter on a randomness problem that
> allowed to some extents to guess TCP ports and sequence numbers, and it
> required us to imagine various approaches that shouldn't break TCP, and
> iterate with the researchers who studied them, tested them before getting
> back to us with "it still isn't sufficient". It was a long and painful
> one, nobody remained idle, yet it was really needed to get to the end of
> it before publishing anything. Further, the researchers asked us to keep
> some details on hold for a while because they were preparing a paper, and
> this is also something to keep in mind (some of them depened on this,
> though we must not accept that it drags for too long).
Yes, I understand that such cases and such incentives exist. In those
cases, the issue should only be brought to (linux-)distros when it's
almost ready for publication.
That said, can you share more detail on the specific issue you referred
to above and its handling/disclosure timeline? Was it ever brought to
oss-security, and if not then why not?
I am guessing this is related to your work on random32 in 2020:
https://lore.kernel.org/netdev/20200808152628.GA27941@SDF.ORG/
If so, it looks like the original issue became public via your commit in
July 2020, but further issues with that fix commit were discovered and
fixes for them prepared in public in August and only merged in October.
So I guess some lengthy private discussion occurred before July 2020,
but it wasn't enough anyway, which makes me question the value of having
the initial handling in private. Maybe the issue wasn't critical enough
and privately-fixable enough for that. Maybe this actually illustrates
that such issues are best handled entirely in public... if it were not
for the researchers' incentive you mentioned (plan to publish a paper).
> As such I think that it's not a good solution to anything to require a
> disclosure before a fix is ready. Actually there can be one exception:
> when no more progress is being made. I don't think I would personally be
> shocked by saying that a discussion that remained inactive for 7 days
> leads to publication, it would sufficiently put the pressure on all parties
> not to let it cool rot. And difficult issues generally don't stay inactive
> for more than a few days.
Makes sense. The current kernel documentation edit should take care of
this (no linux-distros notification until fix is ready) for cases where
the reporter learns of linux-distros from there. Maybe we should even
duplicate this information on the linux-distros wiki page?
Alternatively, we may need to relax the policy.
> > As to publishing PoCs/exploits, this is already mitigated by the Linux
> > kernel documentation edit making it less likely (but far from
> > impossible) that people would send stuff to linux-distros without being
> > aware of the policy. We could further mitigate this issue by allowing
> > up to 30 days (but perhaps suggesting at most 7 days?)
>
> I don't think maintaining pressure on the reporter regarding the need
> for publishing reproducers is doing any good. It should be up to the
> reporter to say "please keep this confidential". We've had many of
> these on s@k.o, and it's perfectly understandable. Knowing that they
> must be very careful about what they share because it will be published
> is a big constraint, whether it's in terms of code quality, authorization
> from an employer or customer, code that was blatantly copy-pasted from
> another exploit just to help with testing, etc. All of this is useful
> for those trying to fix the problem and do not strictly need to be
> published, so it's pointless to add pressure on the reporter regarding
> this.
Via links from the new LWN story, I also found your similar comments
from 2022:
https://lwn.net/Articles/897065/
Here's a thought experiment: what if the list were not private at all,
e.g. like oss-security is not? Sure someone can ask to "please keep
this confidential", but if it's posted to the list that would be
ineffective. So what people sometimes do on public lists, Bugzillas,
GitHub issues, etc. is share private reproducers with individual
maintainers out-of-band, such as via direct e-mail, while keeping the
main discussion on the list, etc. I see no good reason why the same
can't be happening on a temporarily-private list. So the real problem
may be that (linux-)distros is misunderstood as permanently-private
rather than temporarily-private. Unfortunately, I don't know how to
address that reliably. Even with automated delayed publication, some
people would initially have the wrong idea... maybe unless they have to
pass through a web page with the public archives before finding the
posting address?
Alternatively, we may need to relax the policy.
Just thinking out loud.
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.
