This week the Linux kernel project announced they will be assigning their own CVEs so we discuss the possible implications and fallout from such a shift, plus we cover vulnerabilities in the kernel, Glance_store, WebKitGTK, Bind and more.
64 unique CVEs addressed
Kernel type | 22.04 | 20.04 | 18.04 | 16.04 | 14.04 |
---|---|---|---|---|---|
aws | 100.1 | 100.1 | 100.1 | 100.1 | — |
aws-5.15 | — | 100.1 | — | — | — |
aws-5.4 | — | — | 100.1 | — | — |
aws-6.2 | 100.1 | — | — | — | — |
aws-hwe | — | — | — | 100.1 | — |
azure | 100.1 | 100.1 | — | 100.1 | — |
azure-4.15 | — | — | 100.1 | — | — |
azure-5.4 | — | — | 100.1 | — | — |
azure-6.2 | 100.1 | — | — | — | — |
gcp | 100.1 | 100.1 | — | 100.1 | — |
gcp-4.15 | — | — | 100.1 | — | — |
gcp-5.15 | — | 100.1 | — | — | — |
gcp-5.4 | — | — | 100.1 | — | — |
gcp-6.2 | 100.1 | — | — | — | — |
generic-4.15 | — | — | 100.1 | 100.1 | — |
generic-4.4 | — | — | — | 100.1 | 100.1 |
generic-5.15 | — | 100.1 | — | — | — |
generic-5.4 | — | 100.1 | 100.1 | — | — |
gke | 100.1 | 100.1 | — | — | — |
gke-5.15 | — | 100.1 | — | — | — |
gkeop | — | 100.1 | — | — | — |
hwe-6.2 | 100.1 | — | — | — | — |
ibm | 100.1 | 100.1 | — | — | — |
ibm-5.15 | — | 100.1 | — | — | — |
linux | 100.1 | — | — | — | — |
lowlatency-4.15 | — | — | 100.1 | 100.1 | — |
lowlatency-4.4 | — | — | — | 100.1 | 100.1 |
lowlatency-5.15 | — | 100.1 | — | — | — |
lowlatency-5.4 | — | 100.1 | 100.1 | — | — |
To check your kernel type and Livepatch version, enter this command:
canonical-livepatch status
access_key
if logging configured at DEBUG level - any
user then able to read the logs could see the access key and hence potentially
get access to the S3 bucket (would also need the secret key too and this was
never logged so impact minimal)Earlier this week, Greg Kroah-Hartman (one of the more famous Linux kernel developers - responsible for the various stable kernel trees / releases plus various subsystems within the kernel - also wrote one of the most popular books on Linux Kernel Driver development - even if it is woefully outdated nowadays) announced that the Linux kernel project itself has been accepted as a CNA by MITRE and would start issues CVEs for the vulnerabilities found within the kernel itself
Historically the upstream kernel developers and Greg himself have been quite disparaging of the CVE process / ecosystem and essentially saying that CVEs for the kernel are meaningless since that all bugs are potentially security issues and there are so many fixes that go into the kernel of which the security impact is not clear, that the only way to stay secure is to track one of the supported upstream stable kernel trees - otherwise CVEs would be issued for basically every commit that goes into one of the stable trees
It was not then surprising to see that in the initial announcement there was a statement that:
Note, due to the layer at which the Linux kernel is in a system, almost any bug might be exploitable to compromise the security of the kernel, but the possibility of exploitation is often not evident when the bug is fixed. Because of this, the CVE assignment team is overly cautious and assign CVE numbers to any bugfix that they identify.
This led many (including us) to fear that the kernel CNA would be issuing an extremely high volume of CVEs which would effectively overwhelm the CVE process and make it unworkable - for instance, LWN calculated that for the 6.1 stable kernel has had over 12,000 fixes applied to it over the past year. So this leaves a huge scope for many CVEs to be possibly assigned - and as a comparison in total across all software / hardware devices etc in 2023 there was 29,000 CVEs assigned. So that could mean the kernel itself would possibly become responsible for at least a quarter of all CVEs in the future.
Greg has some prior form in this space as well since in 2019 he gave a talk where he suggested one way the kernel community could help fix the issue of CVEs being erroneously assigned against the kernel would be to start doing exactly this and assigning a CVE for every fix applied to the kernel and hence overwhelm the CVE ecosystem to (in his words) “burn it down”.
Also the GSD project (Global Security Database - set up as an alternate / competitor to CVE) was doing exactly this - tracking a huge number of fixes for the stable trees and assigning them GSD IDs - as per https://osv.dev/list?ecosystem=Linux it tracks 13573 issues
Thankfully though, this plan seems to have moderated over the past few days - after Greg posted a patch set to the LKML documenting the process, he clarified in a follow-up email that this would not be the case, and instead that CVEs will only be assigned for commits which appear to have a security relevant impact. How they actually do that remains to be seen, and his comment that “we (will) know it when we see it” doesn’t exactly put me at ease (since it is very easy to miss the security implications of any particular commit) at least this helps allay the fears that there would be a tidal wave of CVEs being assigned.
One outstanding issue which I directly asked Greg about is how they are actually tracking fixes for CVEs - since in their model, a CVE is equivalent to the commit which fixes the issue - however for lots of existing kernel CVEs that get assigned by other CNAs like Canonical or Red Hat etc, the fix comprises multiple commits
Greg says the whole process is quite complex and whilst their existing scripts want a one-to-one mapping from CVEs to commits they do plan to fix this in the future.
So will be interesting to see what things they will end up assigning CVEs. Also will be interesting to see how the interaction with security researchers plays out. Since their process is heavily skewed to the CVE corresponding to the fix commit AND they state that this must be in one of the stable trees for a CVE to be assigned, it doesn’t leave a lot of room for responsible disclosure. They do say they can assign a CVE for an issue before it is resolved with a commit to one of the stable trees, but ideally these details would get disclosed to distros and others ahead of the CVE details being released to the public. I also asked Greg about this but am awaiting a response.