Re: [MAINTAINERS SUMMIT] Handling of embargoed security issues -- security@korg vs. linux-distros@

Vegard Nossum
2023-08-16T18:38:18Z

On 8/16/23 00:17, Jiri Kosina wrote:
> On Tue, 15 Aug 2023, Greg KH wrote:
>
>> Why are they not just doing what the huge majority of Linux users doing
>> and taking the "feed of known issues that resolve problems before they
>> are public knowledge" that we provide today for free to them? Because
>> they somehow think that knowing a specific single bugfix is more special
>> than all of those other bugfixes, which honestly, is just loony.
>
> If you'd like me to turn this proposal into "What can we do to make sure
> that most major distros are eventually basing their kernels on -stable"
> discussion, I'd be happy to do that, but I believe this has been discussed
> quite extensively already.

I really think these are two different and orthogonal topics and we
ought to treat them separately: tracking stable vs. having advance
notice for some vulnerabilities.

(Regarding tracking stable, I fully agree that all distros should be
keeping up with stable and not just cherry-picking specific fixes or
whatever commits happen to have a CVE assigned. No contest there.)

This proposal is about embargoed security issues, issues that were
reported because somebody knows (or has good reason to suspect) that
an issue is exploitable and is planning to disclose that fact publicly.

I posit that there is objectively a difference between:

a) vulnerabilities that have been discovered and reported by a
security researcher and where a detailed analysis and/or PoCs/exploits
are certain to be made published publicly; and

b) patches that appear in mainline/stable with no vulnerability
analysis and no known exploit vector.

I agree that both categories of issues may be equally serious or
equally exploitable, so the difference is in the fact that somebody
has done a thorough analysis of specific bugs and/or is planning to
disclose that publicly.

If distros are only made aware of a vulnerability when it is
disclosed publicly by a security researcher, that leaves a window of
opportunity for attackers -- patches that appear in stable do not
immediately make it onto end-user systems for a variety of reasons:
the time it takes to backport the patch (as most distros carry at
least some out-of-tree patches), testing/validation (especially if
there were conflicts or other issues with the patch), and then of
course the time it takes end-user to upgrade.

I think several distros at this point are making use of live patching
technology -- for really critical vulnerabilities, this has the
potential to reduce that window to very close to zero: live patching
updates that are available and can be applied from the moment the
vulnerability is disclosed publicly.

So it really isn't a choice between one or the other -- the best
security for end users is when we do both.

(I should add that I don't think anybody is really asking for a private
feed of s@k.o -- IMHO the best solution would be for security
researchers to notify the distros list when s@k.o has a tentative or
final patch, before disclosing the vulnerability publicly. The best path
I see for that is: 1) relax the linux-distros policy to not require
posting more than what the reporter is comfortable disclosing, 2) fix
the kernel.org documentation to be clearer for reporters, 3) have a
person on s@k.o who can guide the reporter towards linux-distros if they
are planning to do a public disclosure anyway.)

Thanks,

Vegard