OverviewThis week the Linux kernel project announced they will be assigning their ownCVEs so we discuss the possible implications and fallout from such a shift, pluswe cover vulnerabilities in the kernel, Glance_store, WebKitGTK, Bind and more.
This week in Ubuntu Security Updates64 unique CVEs addressed
[LSN-0100-1] Linux kernel vulnerability (00:56)* 5 CVEs addressed in Jammy (22.04 LTS), Focal (20.04 LTS), Bionic ESM (18.04 ESM), Xenial ESM (16.04 ESM), Trusty ESM (14.04 ESM) + CVE-2023-6932 + CVE-2023-6817 + CVE-2023-6176 + CVE-2023-6040 + CVE-2023-5345 * UAF in IGMP protocol ([USN-6601-1] Linux kernel vulnerability from Episode 217) * UAF in netfilter ([USN-6606-1] Linux kernel (OEM) vulnerabilities from Episode 217) * UAF in SMB client implementation - local crash / privesc ([USN-6607-1] Linux kernel (Azure) vulnerabilities from Episode 217) * NULL ptr deref in kernel TLS offload implementation - allows a userspaceapplication to request that the kernel do TLS by providing it the key etc -internally the kernel then takes the data to be sent from userspace and framesit into a scatter list (describes the regions in memory containing the data tobe sent) - uses the kernel crypto API which is asynchronous + userspace can construct an invalid initial sequence number to trigger thekernel to enter a code path where the network packet is freed before it hasfinished being processed by the crypto API -> UAF
| 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
[USN-6624-1] Linux kernel vulnerabilities* 9 CVEs addressed in Jammy (22.04 LTS), Mantic (23.10)
+ CVE-2024-0641
+ CVE-2023-6622
+ CVE-2023-6531
+ CVE-2023-6176
+ CVE-2023-5972
+ CVE-2023-46862
+ CVE-2023-46813
+ CVE-2023-35827
+ CVE-2023-34324
[USN-6625-1] Linux kernel vulnerabilities* 4 CVEs addressed in Bionic ESM (18.04 ESM), Focal (20.04 LTS) + CVE-2023-46343 + CVE-2023-45863 + CVE-2023-35827 + CVE-2023-34324
[USN-6626-1] Linux kernel vulnerabilities* 10 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS) + CVE-2024-0641 + CVE-2023-6622 + CVE-2023-6176 + CVE-2023-6039 + CVE-2023-46813 + CVE-2023-35827 + CVE-2023-34324 + CVE-2023-32257 + CVE-2023-32252 + CVE-2023-32250
[USN-6625-2] Linux kernel (GCP) vulnerabilities* 4 CVEs addressed in Bionic ESM (18.04 ESM), Focal (20.04 LTS) + CVE-2023-46343 + CVE-2023-45863 + CVE-2023-35827 + CVE-2023-34324
[USN-6628-1] Linux kernel (Intel IoTG) vulnerabilities* 16 CVEs addressed in Jammy (22.04 LTS) + CVE-2024-0641 + CVE-2024-0193 + CVE-2023-6932 + CVE-2023-6931 + CVE-2023-6817 + CVE-2023-6622 + CVE-2023-6606 + CVE-2023-6176 + CVE-2023-6040 + CVE-2023-6039 + CVE-2023-46813 + CVE-2023-35827 + CVE-2023-34324 + CVE-2023-32257 + CVE-2023-32252 + CVE-2023-32250
[USN-6626-2] Linux kernel vulnerabilities* 10 CVEs addressed in Jammy (22.04 LTS) + CVE-2024-0641 + CVE-2023-6622 + CVE-2023-6176 + CVE-2023-6039 + CVE-2023-46813 + CVE-2023-35827 + CVE-2023-34324 + CVE-2023-32257 + CVE-2023-32252 + CVE-2023-32250
[USN-6608-2] Linux kernel (NVIDIA) vulnerabilities* 5 CVEs addressed in Jammy (22.04 LTS) + CVE-2024-0193 + CVE-2023-6932 + CVE-2023-6931 + CVE-2023-6817 + CVE-2023-6606
[USN-6635-1] Linux kernel (GCP) vulnerabilities* 13 CVEs addressed in Jammy (22.04 LTS) + CVE-2024-0193 + CVE-2023-6932 + CVE-2023-6931 + CVE-2023-6817 + CVE-2023-6606 + CVE-2023-5717 + CVE-2023-5178 + CVE-2023-5158 + CVE-2023-42754 + CVE-2023-39193 + CVE-2023-39192 + CVE-2023-39189 + CVE-2023-37453
[USN-6627-1] libde265 vulnerabilities (04:10)* 18 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS) + CVE-2022-1253 + CVE-2022-43253 + CVE-2022-43252 + CVE-2022-43248 + CVE-2022-43243 + CVE-2022-43240 + CVE-2022-43239 + CVE-2022-43237 + CVE-2022-43236 + CVE-2022-43235 + CVE-2021-36410 + CVE-2021-36409 + CVE-2021-36408 + CVE-2022-43242 + CVE-2022-43241 + CVE-2022-43238 + CVE-2021-36411 + CVE-2021-35452 * Open H.265 video codec implementation - used by gstreamer and hence Videos(totem) in particular * Lots of the usual sorts of issues - a lot appear to have been found by acouple different researchers fuzzing - assertion failure, NULL ptr derefs, OOBreads, UAF, OOB writes etc - impact then ranging from DoS to possible codeexecution
[USN-6630-1] Glance_store vulnerability (05:26)* 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Mantic (23.10)
+ CVE-2024-1141
* OpenStack Image Service store library - library for interacting with assets(images) via different storage technologies (local file-system, HTTP, RBD,Swift, S3 and others)
* S3 backend would log the access_key if logging configured at DEBUG level - anyuser then able to read the logs could see the access key and hence potentiallyget access to the S3 bucket (would also need the secret key too and this wasnever logged so impact minimal)
[USN-6631-1] WebKitGTK vulnerabilities (06:26)* 3 CVEs addressed in Jammy (22.04 LTS), Mantic (23.10) + CVE-2024-23222 + CVE-2024-23213 + CVE-2024-23206 * Minimal info as with all webkit issues + “improved memory handling to fix possible arbitrary code execution when processing crafted web content” + “improved access restrictions to fix user fingerprinting from a crafted web page” + “improved checks to fix a type confusion issue able to be triggered fromcrafted web content - possibly exploited in the wild”
[USN-6632-1] OpenSSL vulnerabilities (07:13)* 2 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM) + CVE-2024-0727 + CVE-2023-5678 * [USN-6622-1] OpenSSL vulnerabilities from Episode 218
[USN-6633-1] Bind vulnerabilities (07:33)* 5 CVEs addressed in Jammy (22.04 LTS), Mantic (23.10) + CVE-2023-5679 + CVE-2023-5517 + CVE-2023-50868 + CVE-2023-50387 + CVE-2023-4408 * Range of issues including 2 different CPU-based DoS - one in handling ofregular DNS queries / responses, the other in DNSSEC - “KeyTrap” - alsoaffects resolvers not just servers (so any client system as well that is doinglookups) - affects the DNSSEC standard itself and hence affects various otherimplementations as well * Attack works by having an attacker create a DNS zone with many RRSIG andDNSKEY records - these contain a cryptographic signature and public keyrespectively - so when trying to validate the DNSSEC record need both - and sowill end up trying every possible RRSIG with every possible DNSKEY to find amatch - with no bound on the computation time (and if implemented in a singlethreaded manner) - can completely DoS the server / client etc. * Plus a similar issue in the NSEC3 proof of non-existence in DNSSEC
[USN-6634-1] .NET vulnerabilities (09:47)* 2 CVEs addressed in Jammy (22.04 LTS), Mantic (23.10) + CVE-2024-21404 + CVE-2024-21386 * Updates for dotnet 6, 7 and 8 * DoS when parsing X509 certificates if using OpenSSL (as is the case in Ubuntu)and a DoS in the SignalR library (allows a server to send asynchronousnotifications to client-side web applications) able to be triggered by amalicious client
[USN-6629-1, USN-6629-2] UltraJSON vulnerabilities (10:34)* 3 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS) + CVE-2022-31117 + CVE-2022-31116 + CVE-2021-45958 * Fast JSON encoder/decoder for Python * Is actually implemented in C with Python bindings - so has usual issues - UAF,memory corruption, stack buffer overflow
Goings on in Ubuntu Security CommunityLinux kernel becomes a CNA (11:25)* Earlier this week, Greg Kroah-Hartman (one of the more famous Linux kerneldevelopers - responsible for the various stable kernel trees / releases plusvarious subsystems within the kernel - also wrote one of the most popularbooks on Linux Kernel Driver development - even if it is woefully outdatednowadays) announced that the Linux kernel project itself has been accepted asa CNA by MITRE and would start issues CVEs for the vulnerabilities foundwithin the kernel itself * Historically the upstream kernel developers and Greg himself have been quitedisparaging of the CVE process / ecosystem and essentially saying that CVEsfor the kernel are meaningless since that all bugs are potentially securityissues and there are so many fixes that go into the kernel of which thesecurity impact is not clear, that the only way to stay secure is to track oneof the supported upstream stable kernel trees - otherwise CVEs would be issuedfor basically every commit that goes into one of the stable trees
+ Whilst in Ubuntu we tend to agree that the only way to maintain a kernel isto use the stable trees (and hence the Ubuntu Kernel team continuouslyincorporates all the fixes from the upstream stable kernel trees into thedifferent Ubuntu kernels) we still see a lot of value in the CVE ecosystem -and also we do not agree that all fix commits warrant a CVE
Note, due to the layer at which the Linux kernel is in a system, almost anybug might be exploitable to compromise the security of the kernel, but thepossibility of exploitation is often not evident when the bug isfixed. Because of this, the CVE assignment team is overly cautious and assignCVE numbers to any bugfix that they identify.
- This led many (including us) to fear that the kernel CNA would be issuing anextremely high volume of CVEs which would effectively overwhelm the CVEprocess and make it unworkable - for instance, LWN calculated that for the 6.1stable kernel has had over 12,000 fixes applied to it over the past year. Sothis leaves a huge scope for many CVEs to be possibly assigned - and as acomparison in total across all software / hardware devices etc in 2023 therewas 29,000 CVEs assigned. So that could mean the kernel itself would possiblybecome 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 talkwhere he suggested one way the kernel community could help fix the issue ofCVEs being erroneously assigned against the kernel would be to start doingexactly this and assigning a CVE for every fix applied to the kernel and henceoverwhelm 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 fixesfor the stable trees and assigning them GSD IDs - as perhttps://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, heclarified in a follow-up email that this would not be the case, and insteadthat CVEs will only be assigned for commits which appear to have a securityrelevant impact. How they actually do that remains to be seen, and his commentthat “we (will) know it when we see it” doesn’t exactly put me at ease (sinceit is very easy to miss the security implications of any particular commit) atleast this helps allay the fears that there would be a tidal wave of CVEsbeing assigned.
- One outstanding issue which I directly asked Greg about is how they areactually tracking fixes for CVEs - since in their model, a CVE is equivalentto the commit which fixes the issue - however for lots of existing kernel CVEsthat get assigned by other CNAs like Canonical or Red Hat etc, the fixcomprises multiple commits
- Greg says the whole process is quite complex and whilst their existing scriptswant a one-to-one mapping from CVEs to commits they do plan to fix this in thefuture.
- So will be interesting to see what things they will end up assigningCVEs. Also will be interesting to see how the interaction with securityresearchers plays out. Since their process is heavily skewed to the CVEcorresponding to the fix commit AND they state that this must be in one of thestable trees for a CVE to be assigned, it doesn’t leave a lot of room forresponsible disclosure. They do say they can assign a CVE for an issue beforeit is resolved with a commit to one of the stable trees, but ideally thesedetails would get disclosed to distros and others ahead of the CVE detailsbeing released to the public. I also asked Greg about this but am awaiting aresponse.
Get in contact* security@ubuntu.com * #ubuntu-security on the Libera.Chat IRC network * ubuntu-hardened mailing list * Security section on discourse.ubuntu.com * @ubuntusecurity@fosstodon.org, @ubuntu_sec on twitter