Sveriges mest populära poddar
Start / Ubuntu Security Podcast / Episode 208

Ubuntu Security Podcast

Episode 208

25 min • 8 september 2023

Overview

This week we detail the recently announced and long-awaited feature of TPM-backed full-disk encryption for the upcoming Ubuntu 23.10 release, plus we cover security updates for elfutils, GitPython, atftp, BusyBox, Docker Registry and more.

This week in Ubuntu Security Updates

93 unique CVEs addressed

[USN-6322-1] elfutils vulnerabilities (00:38)

[USN-6323-1] FRR vulnerability (01:40)

[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)
  • 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 completely validate the options and so leads to shell-command injection - thanks to Sylvain Beucler from Debian LTS team for noticing this and pointing it out to the upstream project

[USN-6333-1] Thunderbird vulnerabilities (03:00)

[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)
  • 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 the array of options and into adjacent memory - according to the CVE this would then be the data from /etc/group on the server but likely this is not deterministic 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)
  • Invalid free() on malformed gzip data - on error, sets bit 1 of a pointer to indicate that an error occurred - would then go and pass this pointer to free() but now the pointer is 1-byte past where it should be - so need to unset this bit first
  • In shell handling of crafted input could trigger a stack overflow when parsing certain arithmetic expressions -> crash / RCE - BUT since this is in parsing of shell expressions anyway could just easily pass actual shell code to evaluate 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)
  • Tools to pack and server docker images - ie. to stand up your own docker registry for serving OCI images
  • Two different DoS since didn’t place any bounds on the size of various parameters in requests - so when handling a crafted request with a very large value, would try and allocate enough memory for that and then potentially run out of memory and crash
  • Even in languages like Go which are memory safe, we still run into real world limits like this - whilst in computing we like to have abstractions like unlimited memory, and can generally program assuming this to be true, need to be careful still when handling untrusted input

[USN-6321-1] Linux kernel vulnerabilities (09:21)

[USN-6325-1] Linux kernel vulnerabilities

[USN-6324-1] Linux kernel (GKE) vulnerabilities

[USN-6327-1] Linux kernel (KVM) vulnerabilities

[USN-6328-1] Linux kernel (Oracle) vulnerabilities

[USN-6329-1] Linux kernel vulnerabilities

[USN-6330-1] Linux kernel (GCP) vulnerabilities

[USN-6331-1] Linux kernel (Azure) vulnerabilities

[USN-6332-1] Linux kernel (Azure) vulnerabilities

[USN-6337-1] Linux kernel (Azure) vulnerabilities

[USN-6338-1] Linux kernel vulnerabilities

[USN-6339-1] Linux kernel vulnerabilities

[USN-6340-1] Linux kernel vulnerabilities

[USN-6341-1] Linux kernel vulnerabilities

[USN-6342-1] Linux kernel vulnerabilities

[USN-6343-1] Linux kernel (OEM) vulnerabilities

[USN-6344-1] Linux kernel (Azure) vulnerabilities

Goings on in Ubuntu Security Community

TPM-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 early research, design and implementation
  • Ubuntu has traditionally offered FDE via LUKS on-top of LVM since 6.06 - back then it was via an alternate install image but in 12.10 got integrated into the 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 removed it cannot be compromised
  • Windows has long supported this via BitLocker - uses a hardware component called the Trusted Platform Module (TPM) to essentially store an encryption key which is only made available if the machine is booting the expected operating system under the expected BIOS etc
  • As I said earlier, this is a feature that has high demand in the IoT space, so back in 2019 work was started to design and implement a similar solution for Ubuntu Core
  • Debuted in Ubuntu Core 20 and has seen ongoing development through Ubuntu Core 22 and more since
  • To ensure that the expected + trusted BIOS and OS is running, use the TPM to essentially 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 the system is in the expected state by looking at the chain of hashes to make sure they match the one that was used when the key was locked into the TPM in the first 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 other machine 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 general Linux 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 by such 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 the kernel snap was updated to use unified kernel images which contain both the kernel and initrd (plus some other components) into a single UEFI binary - this allows them to be signed like existing kernel EFI binaries and hence verified during the boot process and measured by the TPM to support this use-case. Similarly, the gadget snap contains the bootloader and UEFI configuration etc - so this can also be measured and verified at boot to ensure the system is in the required state (ie. UEFI Secure Boot is enabled etc).
  • Unlike Ubuntu Core, traditional or classic Ubuntu however uses debs for the kernel and shim etc, and so is not easily amenable to this same solution - also as mentioned above, components like the initrd and bootloader configuration are generated locally and so can’t easily be signed and hence verified at boot
  • As such, to support this same use-case on traditional Ubuntu, the snap-based approach was reused - in this model, instead of deb packages providing kernel and shim + grub etc, snaps are used. As such, snapd is then also used to manage the TPM as described above - ie. calculate the expected hashes when a new kernel / bootloader is installed and re-seal the encryption key based on this
  • 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 like BitLocker on Windows, you won’t have to enter a passphrase on boot but you still get full disk encryption - and the kernel and bootloader are delivered as 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 bypassed reasonably easily - in fact there was a recent blog from Pulse Security describing this kind of thing https://pulsesecurity.co.nz/advisories/tpm-luks-bypass
    • In this case, the systemd emergency.service unit is still enabled which allows the usual boot checks to be bypassed
    • Chris considered this in the original design for Ubuntu Core and so this is disabled
    • Crucially, when using something like Clevis, the initrd is not verified, so an attacker can just replace the initrd with one of their own choosing to subvert the usual trusted boot process as well
    • Interestingly the folks from Linux Matters were recently talking about TPM-backed FDE - mentioned systemd-cryptenroll - this can provide a more comprehensive solution since you can choose to have it verify more of the boot components BUT it still requires a lot of manual work to get running and won’t be as comprehensive in the end - also won’t necessarily auto-update when new kernels are installed etc
  • Intended to be a holistic solution the provides robust protection against various online and offline attacks, whilst providing strong guarantees that things like Secure Boot is not bypassed and that the key from the TPM can’t be easily sniffed from the bus etc.
  • Thanks again to Chris for leading this work
  • Try it out, provide feedback

Get in contact

Kategorier
PoddarTeknologi
Förekommer på
Teknik
00:00 -00:00
Hur lyssnar jag på podcast?

En liten tjänst av I'm With Friends. Finns även på engelska.