OverviewThis week we detail the recently announced and long-awaited feature ofTPM-backed full-disk encryption for the upcoming Ubuntu 23.10 release, plus wecover security updates for elfutils, GitPython, atftp, BusyBox, Docker Registryand more.

This week in Ubuntu Security Updates93 unique CVEs addressed

[USN-6322-1] elfutils vulnerabilities (00:38)* 10 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS) + CVE-2021-33294 + CVE-2020-21047 + CVE-2019-7665 + CVE-2019-7150 + CVE-2019-7149 + CVE-2018-18521 + CVE-2018-18520 + CVE-2018-18310 + CVE-2018-16403 + CVE-2018-16062 * All the older CVEs (2018-2019) for Ubuntu 14.04 only - and all of these arejust DoS through OOB read / NULL ptr deref etc * OOB write / off-by-one + CPU-based DoS as well for more recent releases ->code execution / crash | DoS

[USN-6323-1] FRR vulnerability (01:40)* 1 CVEs addressed in Jammy (22.04 LTS), Lunar (23.04) + CVE-2023-31490 * Missing length check when handling particular options - would cause an OOBread and hence a crash of bgpd within frr - similar to recent issues like[USN-6136-1] FRR vulnerabilities from Episode 198

[USN-6326-1] GitPython vulnerability (02:11)* 1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Lunar (23.04) + CVE-2023-40267 * Incomplete fix for historical CVE-2022-24439 ([USN-5968-1] GitPython vulnerability from Episode 192) * Essentially allows to get RCE since calls git clone and doesn’t completelyvalidate the options and so leads to shell-command injection - thanks toSylvain Beucler from Debian LTS team for noticing this and pointing it out tothe upstream project

[USN-6333-1] Thunderbird vulnerabilities (03:00)* 9 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Lunar (23.04) + CVE-2023-4056 + CVE-2023-4055 + CVE-2023-4049 + CVE-2023-4048 + CVE-2023-4047 + CVE-2023-4050 + CVE-2023-4046 + CVE-2023-4045 + CVE-2023-3417 * 102.15.0

[USN-6334-1] atftp vulnerabilities (03:10)* 3 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS) + CVE-2021-46671 + CVE-2021-41054 + CVE-2020-6097 * TFTP server and client packages * All 3 issues in the atftpd server + assertion failure when handling crafted Multicast Read Request + buffer overflow when handling crafted request with multiple options + buffer overread when handling crafted options data - would read past thearray of options and into adjacent memory - according to the CVE this wouldthen be the data from /etc/group on the server but likely this is notdeterministic and would be whatever else was on the heap

[USN-6335-1] BusyBox vulnerabilities (05:20)* 2 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM) + CVE-2022-48174 + CVE-2021-28831 * Invalid free() on malformed gzip data - on error, sets bit 1 of a pointer toindicate that an error occurred - would then go and pass this pointer tofree() but now the pointer is 1-byte past where it should be - so need tounset this bit first * In shell handling of crafted input could trigger a stack overflow when parsingcertain arithmetic expressions -> crash / RCE - BUT since this is in parsingof shell expressions anyway could just easily pass actual shell code toevaluate surely?

[USN-6336-1] Docker Registry vulnerabilities (07:52)* 2 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Lunar (23.04) + CVE-2023-2253 + CVE-2017-11468 * Tools to pack and server docker images - ie. to stand up your own dockerregistry for serving OCI images * Two different DoS since didn’t place any bounds on the size of variousparameters in requests - so when handling a crafted request with a very largevalue, would try and allocate enough memory for that and then potentially runout of memory and crash * Even in languages like Go which are memory safe, we still run into real worldlimits like this - whilst in computing we like to have abstractions likeunlimited memory, and can generally program assuming this to be true, need tobe careful still when handling untrusted input

[USN-6321-1] Linux kernel vulnerabilities (09:21)* 10 CVEs addressed in Lunar (23.04) + CVE-2023-4015 + CVE-2023-4004 + CVE-2023-3995 + CVE-2023-3777 + CVE-2023-3776 + CVE-2023-3611 + CVE-2023-3610 + CVE-2023-3609 + CVE-2023-20593 + CVE-2022-40982 * 6.2 for StarFive and GCP * Covered previously in [USN-6315-1] Linux kernel vulnerabilities from Episode 207

[USN-6325-1] Linux kernel vulnerabilities* 11 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS) + CVE-2023-4015 + CVE-2023-4004 + CVE-2023-3995 + CVE-2023-3777 + CVE-2023-3776 + CVE-2023-3611 + CVE-2023-3610 + CVE-2023-3609 + CVE-2023-21400 + CVE-2023-20593 + CVE-2022-40982 * 5.15 GKEOP, Intel IoTG

[USN-6324-1] Linux kernel (GKE) vulnerabilities* 5 CVEs addressed in Focal (20.04 LTS) + CVE-2023-3776 + CVE-2023-3611 + CVE-2023-3609 + CVE-2023-20593 + CVE-2022-40982 * 5.4 for GKE

[USN-6327-1] Linux kernel (KVM) vulnerabilities* 6 CVEs addressed in Xenial ESM (16.04 ESM) + CVE-2023-3776 + CVE-2023-3611 + CVE-2023-3567 + CVE-2023-31084 + CVE-2023-2985 + CVE-2023-2269

[USN-6328-1] Linux kernel (Oracle) vulnerabilities* 10 CVEs addressed in Lunar (23.04) + CVE-2023-4015 + CVE-2023-4004 + CVE-2023-3995 + CVE-2023-3777 + CVE-2023-3776 + CVE-2023-3611 + CVE-2023-3610 + CVE-2023-3609 + CVE-2023-20593 + CVE-2022-40982

[USN-6329-1] Linux kernel vulnerabilities* 5 CVEs addressed in Bionic ESM (18.04 ESM) + CVE-2023-3776 + CVE-2023-3611 + CVE-2023-3609 + CVE-2023-20593 + CVE-2022-40982

[USN-6330-1] Linux kernel (GCP) vulnerabilities* 11 CVEs addressed in Focal (20.04 LTS) + CVE-2023-4015 + CVE-2023-4004 + CVE-2023-3995 + CVE-2023-3777 + CVE-2023-3776 + CVE-2023-3611 + CVE-2023-3610 + CVE-2023-3609 + CVE-2023-21400 + CVE-2023-20593 + CVE-2022-40982

[USN-6331-1] Linux kernel (Azure) vulnerabilities* 21 CVEs addressed in Focal (20.04 LTS) + CVE-2023-3776 + CVE-2023-3611 + CVE-2023-3609 + CVE-2023-33203 + CVE-2023-3141 + CVE-2023-3111 + CVE-2023-30772 + CVE-2023-28466 + CVE-2023-2194 + CVE-2023-2124 + CVE-2023-20593 + CVE-2023-1990 + CVE-2023-1855 + CVE-2023-1611 + CVE-2023-0590 + CVE-2022-4269 + CVE-2022-40982 + CVE-2022-27672 + CVE-2022-1184 + CVE-2022-0168 + CVE-2020-36691

[USN-6332-1] Linux kernel (Azure) vulnerabilities* 35 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS) + CVE-2023-4015 + CVE-2023-4004 + CVE-2023-3995 + CVE-2023-3777 + CVE-2023-3776 + CVE-2023-3611 + CVE-2023-3610 + CVE-2023-3609 + CVE-2023-35829 + CVE-2023-35828 + CVE-2023-35824 + CVE-2023-35823 + CVE-2023-33288 + CVE-2023-33203 + CVE-2023-3268 + CVE-2023-32248 + CVE-2023-3141 + CVE-2023-30772 + CVE-2023-28466 + CVE-2023-23004 + CVE-2023-2269 + CVE-2023-2235 + CVE-2023-2194 + CVE-2023-2163 + CVE-2023-21400 + CVE-2023-2124 + CVE-2023-20593 + CVE-2023-2002 + CVE-2023-1990 + CVE-2023-1855 + CVE-2023-1611 + CVE-2023-0597 + CVE-2022-48502 + CVE-2022-4269 + CVE-2022-40982

[USN-6337-1] Linux kernel (Azure) vulnerabilities* 16 CVEs addressed in Bionic ESM (18.04 ESM) + CVE-2023-33203 + CVE-2023-3141 + CVE-2023-3111 + CVE-2023-30772 + CVE-2023-28466 + CVE-2023-2194 + CVE-2023-2124 + CVE-2023-1990 + CVE-2023-1855 + CVE-2023-1611 + CVE-2023-0590 + CVE-2022-4269 + CVE-2022-27672 + CVE-2022-1184 + CVE-2022-0168 + CVE-2020-36691

[USN-6338-1] Linux kernel vulnerabilities* 11 CVEs addressed in Jammy (22.04 LTS), Lunar (23.04) + CVE-2023-38429 + CVE-2023-38428 + CVE-2023-38426 + CVE-2023-32258 + CVE-2023-32257 + CVE-2023-32252 + CVE-2023-32250 + CVE-2023-32247 + CVE-2023-31084 + CVE-2023-2898 + CVE-2023-21255

[USN-6339-1] Linux kernel vulnerabilities* 8 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS) + CVE-2023-38429 + CVE-2023-38428 + CVE-2023-38426 + CVE-2023-3212 + CVE-2023-31084 + CVE-2023-2898 + CVE-2023-21255 + CVE-2022-48425

[USN-6340-1] Linux kernel vulnerabilities* 9 CVEs addressed in Bionic ESM (18.04 ESM), Focal (20.04 LTS) + CVE-2023-35828 + CVE-2023-35824 + CVE-2023-35823 + CVE-2023-3268 + CVE-2023-31084 + CVE-2023-2269 + CVE-2023-2163 + CVE-2023-21255 + CVE-2023-2002

[USN-6341-1] Linux kernel vulnerabilities* 5 CVEs addressed in Trusty ESM (14.04 ESM) + CVE-2023-3776 + CVE-2023-3611 + CVE-2023-3567 + CVE-2023-3159 + CVE-2023-0458

[USN-6342-1] Linux kernel vulnerabilities* 6 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM) + CVE-2023-3776 + CVE-2023-3611 + CVE-2023-31084 + CVE-2023-2985 + CVE-2023-2269 + CVE-2023-20593

[USN-6343-1] Linux kernel (OEM) vulnerabilities* 7 CVEs addressed in Jammy (22.04 LTS) + CVE-2023-4273 + CVE-2023-4194 + CVE-2023-4155 + CVE-2023-4128 + CVE-2023-40283 + CVE-2023-34319 + CVE-2023-1206

[USN-6344-1] Linux kernel (Azure) vulnerabilities* 11 CVEs addressed in Lunar (23.04) + CVE-2023-38429 + CVE-2023-38428 + CVE-2023-38426 + CVE-2023-32258 + CVE-2023-32257 + CVE-2023-32252 + CVE-2023-32250 + CVE-2023-32247 + CVE-2023-31084 + CVE-2023-2898 + CVE-2023-21255

Goings on in Ubuntu Security CommunityTPM-backed Full Disk Encryption is coming to Ubuntu (10:48)* https://ubuntu.com/blog/tpm-backed-full-disk-encryption-is-coming-to-ubuntu * Ijlal Loutfi (Product Manager for Security Technologies) * Technical work has been led by Chris Coulson from our team - from earlyresearch, design and implementation * Ubuntu has traditionally offered FDE via LUKS on-top of LVM since 6.06 - backthen it was via an alternate install image but in 12.10 got integrated intothe main install image * Uses a passphrase which is manually typed in at boot to unlock the disk * Not very useful in environments which don’t have a user to do this -ie. servers or IoT etc * Demand for an ability to have FDE without having to enter a passphrase -particularly for IoT - so that if a device is stolen and the disk is removedit cannot be compromised * Windows has long supported this via BitLocker - uses a hardware componentcalled the Trusted Platform Module (TPM) to essentially store an encryptionkey which is only made available if the machine is booting the expectedoperating system under the expected BIOS etc * As I said earlier, this is a feature that has high demand in the IoT space, soback in 2019 work was started to design and implement a similar solution forUbuntu Core * Debuted in Ubuntu Core 20 and has seen ongoing development through Ubuntu Core22 and more since * To ensure that the expected + trusted BIOS and OS is running, use the TPM toessentially store a chain of hashes of each component in the boot chain -ie. BIOS, bootloader (shim + grub), kernel (including the kernel command-line)and initrd etc * When the TPM is asked to unlock the encryption key, it will check that thesystem is in the expected state by looking at the chain of hashes to make surethey match the one that was used when the key was locked into the TPM in thefirst place. If this is as expected, it will unlock the key, but if not(ie. the system is booting some other OS or the disk is running on some othermachine etc) then the state won’t match the disk won’t be able to be unlocked * This has traditionally been quite hard to do on traditional Ubuntu and generalLinux systems since things like the initrd are composed on the local machine(see update-initramfs) - and so they can’t easily be signed and verified bysuch a system. * But Ubuntu Core is a different beast, not subject to these same constraints -built on snaps for more specialised use-cases - so for Ubuntu Core 20 thekernel snap was updated to use unified kernel images which contain both thekernel and initrd (plus some other components) into a single UEFI binary -this allows them to be signed like existing kernel EFI binaries and henceverified during the boot process and measured by the TPM to support thisuse-case. Similarly, the gadget snap contains the bootloader and UEFIconfiguration etc - so this can also be measured and verified at boot toensure the system is in the required state (ie. UEFI Secure Boot is enabledetc). * Unlike Ubuntu Core, traditional or classic Ubuntu however uses debs for thekernel and shim etc, and so is not easily amenable to this same solution -also as mentioned above, components like the initrd and bootloaderconfiguration are generated locally and so can’t easily be signed and henceverified at boot * As such, to support this same use-case on traditional Ubuntu, the snap-basedapproach was reused - in this model, instead of deb packages providing kerneland shim + grub etc, snaps are used. As such, snapd is then also used tomanage the TPM as described above - ie. calculate the expected hashes when anew kernel / bootloader is installed and re-seal the encryption key based onthis * This is then all provided via a new experimental option in the installer:

  • Can list the recovery key once booted via:

snap recovery --show-keys * Otherwise is intended to function like a regular Ubuntu install - but likeBitLocker on Windows, you won’t have to enter a passphrase on boot but youstill get full disk encryption - and the kernel and bootloader are deliveredas snaps:

  • Now you may ask, how is this different than existing solutions like Clevis?
    • Clevis only verifies the bootloader and kernel and hence can be bypassedreasonably easily - in fact there was a recent blog from Pulse Securitydescribing this kind of thinghttps://pulsesecurity.co.nz/advisories/tpm-luks-bypass
    • In this case, the systemd emergency.service unit is still enabled whichallows the usual boot checks to be bypassed
    • Chris considered this in the original design for Ubuntu Core and so this isdisabled
    • Crucially, when using something like Clevis, the initrd is not verified, soan attacker can just replace the initrd with one of their own choosing tosubvert the usual trusted boot process as well
    • Interestingly the folks from Linux Matters were recently talking aboutTPM-backed FDE - mentioned systemd-cryptenroll - this can provide a morecomprehensive solution since you can choose to have it verify more of theboot components BUT it still requires a lot of manual work to get runningand won’t be as comprehensive in the end - also won’t necessarilyauto-update when new kernels are installed etc
  • Intended to be a holistic solution the provides robust protection againstvarious online and offline attacks, whilst providing strong guarantees thatthings like Secure Boot is not bypassed and that the key from the TPM can’t beeasily sniffed from the bus etc.
  • Thanks again to Chris for leading this work
  • Try it out, provide feedback

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

See All 242 Episodes of "Ubuntu Security Podcast"