Linux kernel security fixes spotted before release by mailing list data mining
theregister.com
theregister.com
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.
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.
https://github.com/openssl/openssl/commit/bd6941cfaa31ee8a3f...
The author managed to get it in and it lay undiscovered for several years.
So even though this bug had the visibility and attention it wasn’t discovered in the field until several years later.
It may be that the bug was intentionally added or it may have been a simple coding mistake, but either way it’s an example of something innocuous looking being added to a project which could have been used covertly for much longer than it was publicly known about.
I don't think anyone says that open source code makes bugs impossible, but it definitely makes it harder to insert intentional backdoors.
Stuff like this goes uncovered all the time. The Ring 0 RISC exploit from 2018 comes to mind at first. It wasn't a whole two years after Shellshock and heartbleed that Google releases their Fuzzing service.
What you are asking for is that developers should have to prove their real-life identity and authenticate to a public SCM system and that somehow makes it more secure, when hidden exploits could as easily be sent as a PR on GitHub and merged by someone who didn't know better or who can just play dumb.
As for testing, there is kernelci.org, LTP, Syzbot, LKFT and so on. It's not just a bunch people in basements booting up the latest Linux and calling it testing.
https://groups.google.com/forum/m/#!forum/syzkaller-bugs
Isn't testing supposed to find bugs? And aren't fuzzers identifying issues that /might/ exist in theory but dont manifest in practice?
From your assessment I'm surprised my Linux boxen don't crash every day and really surprised I had one stay online for five years - but, many things things about Linux surprise me.
The fact is that people discover and fix bugs, and then years later someone else commits the same mistake again, and nothing prevents this because the kernel has literally zero pre-commit unit tests. Here's an example (thread by the author of syzkaller). https://twitter.com/dvyukov/status/1169544165023240194
> 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.