
Linux kernel security fixes spotted before release by mailing list data mining - Dotnaught
https://www.theregister.com/2020/09/04/linux_kernel_flaws/
======
davidhyde
> “The existence of such channels, shows that trusted individuals can easily
> infiltrate the project, and secretly introduce malicious artifacts”

That is like saying that trusted code can easily do malicious things. Of
course trusted people can do bad things, that’s why you have to trust them.
Even so, source control history means that a trusted person should be found
out if they introduce malicious artifacts.

------
jnurmine
"Linux kernel patches regularly get added in a way that bypasses public review
and discussion, a practice that opens at least a theoretical risk of
backdoored code"

I wonder about how theoretical this risk of backdoored code is and what kind
of backdoors the authors envision.

Security patches are discussed in private by some, if not most, of the same
technically capable people who would otherwise discuss the patches on public
mailing lists (like LKML).

After the code is committed, it is available for everyone to see and discuss.
All new code, including "backdoored code" would also get visibility and
attention.

Even if anyone can see the discussion on LKML it does not mean all those
people actively participate in the discussion, or even review the code.

~~~
jeffbee
There's really no reason to believe in the provenance of any of the code in
the Linux kernel. People mail around patchsets, claim they are "signed off by"
someone, and they get patched into various trees and merged here and there,
and eventually wind up in Linus's tree. It has all of the safety of email,
which is to say none at all. Compared to code review practices at software
companies, where diffs are reviewed and approved by identities authenticated
and authorized by secure computer systems, the linux kernel system is a
complete joke.

~~~
saagarjha
Oh, come on, the code review process at most companies is fairly easy to
bypass. Even at the company I'm sure you're going to bring up I would
seriously doubt it wouldn't be possible to slip something into a long patch,
even though I'm sure there are some sort of guidelines on who and how many
people should be reviewing things.

~~~
maccard
Ive said this before on here, but I'm 95% sure I could find two or three on my
team and say "hey I have a simple fix for X, needs to go in quick, can I tag
you in it?", and they would rubber stamp it knowing it comes from me.

------
vii
From the underlying paper there are several interesting snippets
[https://arxiv.org/pdf/2009.01694.pdf](https://arxiv.org/pdf/2009.01694.pdf)

> while maintainers are aware of that they sometimes intentionally bypass the
> process, they were surprised of the magnitude of unreviewed patches

Would love to see an analysis of these changes - are they just simple merge
style fixes or rearrangements, or more significant?

And then there is the hard to define distinction between a security bug and a
normal bug, which is then mixed into the the incredible productivity and pace
of kernel development:

> Koah-Hartman argues that only a small fraction of Linux kernel security
> fixes are assigned to CVE entries. From 2006-2018, 1005 CVEs were assigned
> to the kernel. He argues that, on average, bugs with CVE entries are 100
> days fixed in mainline before they get a CVE assigned.

Seems there is long lag between the bug being introduced and the exploit
discovered, so there must be many potential security exploits that are never
discovered before they are fixed - and so are not practically exploitable as
they never get into downstream distribution kernels.

------
seemslegit
Boffins ? I haven't realized theregister employs such classy people as Thomas
Claburn.

~~~
alblue
The word “boffin” is a colloquial British term for a smart person (conjuring
up an image of someone in a white lab coat and glasses) and is used in an
affectionate way. The British version of TheReg (.co.uk) often refers to
boffins in this way. It’s probable that this piece was written by the British
team and then reposted to the US site.

~~~
seemslegit
It's not affectionate, it's condescending - much like 'geek' when used
unironically and not by geeks to refer to themselves.

