Ubuntu Security Podcast

Get the App

Ubuntu Security Podcast

Alex Murray

A weekly podcast talking about the latest developments and updates from the Ubuntu Security team, including a summary of the security vulnerabilities and fixes from the last week as well as a discussion on some of the goings on in the wider Ubuntu Security community.

24 minutes

Episode 243
Overview

It’s the end of the year for official duties for the Ubuntu Security team so we take a look back on the security highlights of 2024 for Ubuntu and predict what is coming in 2025.

2024 Year in Review for Ubuntu Security (00:55)

full-disclosure necromancy with zombie CVEs
- full-disclosure spammed with zombie CVEs from Episode 217
Development of unprivileged user namespace restrictions for Ubuntu 24.04 LTS
- Updates for unprivileged user namespace restrictions in Ubuntu 24.04 LTS from Episode 218
Linux kernel becomes a CNA
- Linux kernel becomes a CNA from Episode 219
- Follow up to Linux kernel CNA from Episode 220
Ubuntu participates in Pwn2Own Vancouver
- Summary of Pwn2Own Vancouver 2024 results against Ubuntu 23.10 from Episode 223
xz-utils / SSH backdoor supply-chain attack
- xz-utils backdoor and Ubuntu from Episode 224
- Update on xz-utils from Episode 225
Linux Security Summit NA and EU
- Linux Security Summit NA 2024 from Episode 226
- Linux Security Summit Europe 2024 from Episode 237
Release of Ubuntu 24.04 LTS
- Ubuntu 24.04 LTS (Noble Numbat) released from Episode 227
regreSSHion remote unauthenticated code execution vulnerability in OpenSSH
- Deep-dive into regreSSHion - Remote Unauthenticated Code Execution Vulnerablity in OpenSSH from Episode 232
Various other high profile vulnerabilities
- Discussion of CVE-2024-5290 in wpa_supplicant from Episode 234
- Deep dive into needrestart local privilege escalation vulnerabilities from Episode 242
Ubuntu/Windows Dual-boot regression
- Reports of dual-boot Linux/Windows machines failing to boot from Episode 235
AppArmor-based snap file prompting experimental feature
- Ubuntu Security Center with snapd-based AppArmor home file access prompting preview from Episode 236
- Official announcement of Permissions Prompting in Ubuntu 24.10 from Episode 237
Predictions for 2025 (14:35)
- Increased use of AI to both spam projects with hallucinated CVEs (e.g. curl) but also to “aid” in dealing with that spam
  - as the shine wears of AI likely expect OSS projects to ban contributions generated with the aid of AI - whether CVE reports or code
  - but also expect companies to try and prove the worth of AI by finding novel vulns - e.g. apparent first 0-day discovered with AI doing vuln research https://googleprojectzero.blogspot.com/2024/06/project-naptime.html
  - also more expected uses of AI like automating tasks used in the process of security-related SW dev - automatically generating fuzz targets and then improving the fuzz targets via AI as well https://security.googleblog.com/2024/11/leveling-up-fuzzing-finding-more.html
- More malware targeting Linux
  - didn’t mention it earlier but we covered a number of Linux malware teardowns this year and expect that trend to increase as Linux keeps growing in popularity
- Full LSM stacking still won’t make it into the upstream Linux kernel
- Integrity of code and data will play more of a role
  - both in terms of software supply chain and integrity of distro repos etc, but also efforts to try and guarantee the integrity of a Linux system itself - whether via new IPE LSM or other mechanisms - mainstream distros will start to care about integrity more
- More collaboration across distros to aid in efforts to collectively handle deluge of CVEs
- More efforts to try and fund OSS to learn from lessons of Heartbleed and xz-utils
  - some more and less successful
- More interesting vulns in more software
  - During 2024 Qualys have done some of the most interesting vuln research on Linux - expect more from them and from others (whether aided by AI or not)
Get in contact
20 December 2024, 4:28 am
19 minutes 40 seconds

Episode 242
Overview

This week we dive into the details of a number of local privilege escalation vulnerablities discovered by Qualys in the needrestart package, covering topics from confused deputies to the inner workings of the /proc filesystem and responsible disclosure as well.

Deep dive into needrestart local privilege escalation vulnerabilities
- https://blog.qualys.com/vulnerabilities-threat-research/2024/11/19/qualys-tru-uncovers-five-local-privilege-escalation-vulnerabilities-in-needrestart
- https://www.qualys.com/2024/11/19/needrestart/needrestart.txt
- https://www.bleepingcomputer.com/news/security/ubuntu-linux-impacted-by-decade-old-needrestart-flaw-that-gives-root/
- Qualys contacted [email protected] on [2024-10-04 Fri] to notify of 3 different local privilege escalation vulnerablities in needrestart
- needrestart is system service, written in Perl, to automatically restart system services if one of the libraries or the service itself was updated
- installed by default on Ubuntu Server since 21.04 - so anyone using 22.04 LTS (jammy) or 24.04 LTS (noble) would be affected - and is integrated into apt so that it runs at the end of an apt install/upgrade/remove or via unattended-upgrades (which again is installed by default to install security updates automatically every 24 hours)
- since it runs via apt it runs as root so if an unprivileged user can influence it to execute code of their chosing, can achieve local privilege escalation the next time it runs
- Initially described these as:
  - trick needrestart into running the Python interpreter with an attacker controlled PYTHONPATH environment variable
  - win a race condition with needrestart to trick it into running with attacker controlled Python interpreter instead of the system-installed one
  - perl-related vuln in the ScanDeps module where would open a filename containing a pipe - which in turn causes Perl to execute a shell pipeline with the filename as input and hence code execution
- needrestart is written in Perl so why is Python relevant?
  - basic functionality of needrestart is to look at the shared objects mapped into memory of each process and match these against newly updated/installed packages - if it sees that one of the shared objects for a given process got updated it will then be restarted
  - back in 2014 introduced support for scanning files of interpreted languages for Java, Perl, Python and Ruby
    
    uses /proc/self/exe to first identify the interpreter as say python
    
    then looks at /proc/self/cmdline to determine the primary file being run by the interpreter and from that looks at import statements to determine which files are likely being used
    
    uses similar approaches for the other interpreters
- Interestingly it seems Qualys discovered this by accident - noticed the message “Scanning processes…” whilst doing and apt upgrade and wondered what that was - and if they controlled a process, whether they could then influence the behaviour of it
- For PYTHONPATH CVE, needrestart needs to replicate the behaviour of the Python interpreter when it imports files
  - PYTHONPATH env var allows to specify a custom path to import from - so needrestart looks this up from /proc/pid/environ and executes the Python interpreter with this same value to get it to resolve the imports to files on disk
  - But the unprivileged user is in control of this environment variable for their process - classic case of a Confused Deputy - lower privileged application is able to trick a higher privileged application into misusing its authority on the system - so can set their own PYTHONPATH, and since Python will happy load any __init__.so files from that path, the attacker controlled shared object is then executed by Python running as root via needrestart
- Initially Qualys suggested the Ruby implementation (which uses the RUBYLIB env var) may also be affected and subsequently confirmed this to be the case
- The second aforementioned vuln is also related to Python but instead of the PYTHONPATH used by the interpreter, is about the interpreter binary itself
  - Before we said needrestart identified a process as using say Python by looking at its /proc/pid/exe entry - matches this against a regex like /usr/bin/python - back in 2022 Jakub Wilk discovered a vuln where the regex was not anchored, so if a process was running via a attacker controlled interpreter (/home/amurray/usr/bin/python) this would match and needrestart would execute that interpreter directly as root - CVE-2022-30688
  - Hoewever, it turns out needrestart reads the processes /proc/pid/exe twice - once early on when collecting info on all processes, and then a second time to determine if it is say a Python application - but when needrestart goes and executes this interpreter to do the PYTHONPATH lookups etc, it uses the original value that it collected at the start of its run
  - Classic TOCTOU issue
  - So a malicious process can run with say its own malicious Python interpreter at startup, then wait for needrestart to probe that (using say inotify to be notified when it is accessed) and then quickly exec() the real system Python interpreter and hence change its /proc/self/exe to trick needrestart - which will then go and execute its original malicious interpreter binary
- Since had found issues in Python and Ruby parts of needrestart, Qualys went looking at the Perl parts
  - since needrestart is written in Perl though it doesn’t have to execute a Perl interpreter to resolve “imports” etc
  - instead uses a Perl library (ScanDeps) which analyses Perl scripts directly
  - Found this module was vulnerable to a very old Perl foot-gun, Pesky Pipe (coined in 1999 by rain.forest.puppy in Phrack)
    
    Perl has a feature where you can call open with a string that ends in a pipe (|) and it will instead execute that string as a shell command
    
    ScanDeps did exactly this - called open on any files that it finds along the way in its analysis - and since these filenames are controlled by the unprivileged attacker, can create a file which ends in a pipe character (e.g. /home/amurray/bin/pwned|) and Perl will then just execute that script directly
  - Also found cases in ScanDeps where it would call eval() on contents from these files as well - directly executing whatever strings found as Perl code
- Mark Esler on our team then liased with Qualys and got the upstream needrestart developer involved to coordinate on writing fixes and disclosing the issue - first to other distros via the distros mailing list and then eventually publicly via oss-security
- Patches to fix went through a number of revisions before being finalised
- To fix these, a number of changes were made:
  - ScanDeps was fixed to use an explicit call to open() to avoid Perl executing the argument as code and the uses of eval replaced with safer parsing
  - needrestart removed the use of ScanDeps entirely and instead replaced this with its own regex based parsing of perl files to look for use directives
  - needrestart modified to not set PYTHONPATH when running the Python interpreter and instead look inside the specified PYTHONPATH manually (to avoid having the Python interpreter possibly load untrusted shared objects from that path) - similarly for RUBYLIB
  - needrestart modified to use the original /proc/pid/exe path to match against when looking for interpreted processes to remove the TOCTOU race
- Unfortunately, testing for the patches upstream wasn’t complete and a minor regression was introduced in the original update which caused needrestart to misidentify processes within a container as being on the host and so would inadvertently kill them
- Sudhakar Verma (who handled the technical side of testing proposed patches plus preparing and releasing the final updates) liased with upstream to help get a fix developed and deployed as a regression fix for Ubuntu
- Interesting to consider, the info needrestart was using comes from /proc filesystem - this is a virtual filesystem managed by the kernel, representing information about processes in userspace
- Easy to assume the data it presents is trusted as it is populated by the kernel - and generally file permissions are read-only for these files - so a process can’t just directly write to them to modify them - BUT these values all come from the userspace process itself originally
  - perhaps needrestart could look at dropping privileges to those of the process in question before doing the evaluation as well - although this is tricky to do correctly - we’ve seen bugs in a number of applications which try and follow this pattern like snap-confine or apport which turn out to cause security issues as they don’t drop privileges completely etc
- Ryan Lee is looking to create an AppArmor profile for needrestart to help confine it to hopefully limit the damage any other similar bugs may cause
[USN-7117-1] needrestart and Module::ScanDeps vulnerabilities
- 5 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS), 24.10
  - 2 medium priority CVE(s)
  - 3 high priority CVE(s)
[USN-7117-2] needrestart regression
- 5 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS), 24.10
  - 2 medium priority CVE(s)
  - 3 high priority CVE(s)
Get in contact
29 November 2024, 1:24 am
18 minutes 16 seconds

Episode 241
Overview

This week we take a deep dive into the latest Linux malware, GoblinRAT to look at how malware is evolving to stay stealthy and evade detection and how malware authors are learning from modern software development along the way.

GoblinRAT Linux Malware teardown
- https://rt-solar.ru/solar-4rays/blog/4861/
- Solar 4RAYS team (Cyber Threat Research Center at SOLAR - Russian Cybersecurity firm) describes a new piece of Linux malware which they name GoblinRAT (RAT = Remote Access Trojan) 2023 when contacted by an IT company which provides services to (presumably) Russian government agencies - noticed system logs being deleted off one of their servers and a utility being downloaded to steal account passwords from a domain controller
- Found this malware masquerading as a legitimate process which takes quite careful steps to avoid detection - in fact most of the functionality within the malware is devoted to hiding its presence on the target system
- Doesn’t include automatic persistence but instead appears to be manually “installed” by the attackers with a unique name for each target where it would be named after an existing legitimate process on the target system - similarly even the names of its files and libraries were also unique per-system as well to avoid detection
  - e.g. in one case where zabbix was running, the malware named itself zabbix_agent and setup a new systemd service to launch itself at boot which looks identical to the real zabbix agent (except the real one is zabbix_agentd) and then once running it edits its own command-line arguments after startup to insert standard parameters expected by the real zabbix_agentd so that on a ps aux or similar output it appears basically identical to the real zabbix_agentd
  - in another case it named itself rhsmd to mimic the Red Hat subscription manager service again using systemd as the launcher, whilst for others as memcached using cron to launch
  - C2 uses DDNS (Dynamic DNS) and legitimate hacked sites to hide in noise of “normal” traffic - using DDNS attackers would use specifically named C2 machines per target host - in one case where it was named chrony_debug to mimic the chronyd time synchronisation service, it would connect to C2 a machine named chronyd.tftpd.net - attackers clearly went to a lot of work to hide this in plain sight
- Automatically deletes itself off the system if does not get pinged by the C2 operator after a certain period of time - and when it deletes itself it shreds itself to reduce the chance of being detected later via disk forensics etc
- Has 2 versions - a “server” and “client” - the server uses port-knocking to watching incoming connection requests on a given network interface and then only actually allowing a connection if the expected sequence of port numbers was tried - this allows the controller of the malware to connect into it without the malware actively listening on a given port and hence reduces the chance it is detected accidentally
- Client instead connects back to its specific C2 server
- Logs collected by 4RAYS team appear to show the commands executed by the malware were quite manual looking - invoking bash and then later invoking commands like systemctl to stop and replace an existing service, where the time lag between commands is in the order of seconds - minutes and so would seem like these were manually typed command rather than automatically driven by scripts
- Malware itself is implemented in Go and includes the ability to execute single commands as well as providing an interactive shell; also includes support for listing / copying / moving files including with compression; also works as a SOCKS5 proxy to allow it to proxy traffic to/from other hosts that may be behind more restrictive firewalls etc; and as detailed above the ability to mimic existing processes on the system to avoid detection
- To try and frustrate reverse engineering Gobfuscate was used to obfuscate the compiled code - odd choice though since this project was seemingly abandonded 3 years ago and nowadays garble seems to be the go-to tool for this (no pun intended)- but perhaps this is evidence of the time of the campaign since these samples were all found back in 2020 which this project was more active…
- Encrypts its configuration using AES-GCM and the config contains details like the shell to invoke, kill-switch delay and secret value to use to disable it, alternate process name to use plus the TLS certificate and keys to use when communicating with the C2 server
- Uses the yamux Go connection multiplexing library then to multiplex the single TLS connection to/from the C2 server
- Can then be instructed to perform the various actions like running commands / launching a shell / list files in a directory / reading files etc as discussed before
- Other interesting part is the kill switch / self-destruct functionality - if kill switch delay is specified in the encrypted configuration malware will automatically delete itself by invoking dd to overwrite itself with input from /dev/urandom 8 times; once more with 0 bytes and finally then removing the file from disk
- Overall 4 organisations were found to have been hacked with this and in each it was running with full admin rights - with some running for over 3 years - and various binaries show compilation dates and golang toolchain versions indicating this was developed since at least 2020
- But unlike other malware that we have covered, it does not appear to be a more widespread campaign since “other information security companies with global sensor networks” couldn’t find any similar samples in their own collections
- No clear evidence of origin - Solar 4RAYS asking for other cybersecurity companies to help contribute to their evidence to identify the attackers
- Interesting to see the evolution of malware mirrors that of normal software development - no longer using C/C++ etc but more modern languages like Go which provide exactly the sorts of functionality you want in your malware - systems-level programming functionality with built-in concurrency and memory safety - also Go binaries are statically linked so no need to worry about dependencies on the target system
Get in contact
14 November 2024, 12:29 pm
36 minutes 22 seconds

Episode 240
Overview

For the third and final part in our series for Cybersecurity Awareness Month, Alex is again joined by Luci as well as Diogo Sousa to discuss future trends in cybersecurity and the likely threats of the future.

Get in contact
31 October 2024, 3:17 pm
39 minutes 16 seconds

Episode 239
Overview

In the second part of our series for Cybersecurity Awareness Month, Luci is back with Alex, along with Eduardo Barretto to discuss our top cybersecurity best practices.

Get in contact
18 October 2024, 6:06 am
31 minutes 39 seconds

Episode 238
Overview

For the first in a 3-part series for Cybersecurity Awareness month, Luci Stanescu joins Alex to discuss the recent CUPS vulnerabilities as well as the evolution of cybersecurity since the origin of the internet.

Get in contact
4 October 2024, 4:04 am
16 minutes 16 seconds

Episode 237
Overview

John and Maximé have been talking about Ubuntu’s AppArmor user namespace restrictions at the the Linux Security Summit in Europe this past week, plus we cover some more details from the official announcement of permission prompting in Ubuntu 24.10, a new release of Intel TDX for Ubuntu 24.04 LTS and more.

This week in Ubuntu Security Updates (01:11)

613 unique CVEs addressed in the past fortnight

[USN-6989-1] OpenStack vulnerability
- 1 CVEs addressed in Jammy (22.04 LTS), Noble (24.04 LTS)
  - CVE-2024-44082
[USN-6990-1] znc vulnerability
- 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), Noble (24.04 LTS)
  - CVE-2024-39844
[USN-6992-1] Firefox vulnerabilities
- 8 CVEs addressed in Focal (20.04 LTS)
[USN-6993-1] Vim vulnerabilities
- 2 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), Noble (24.04 LTS)
  - CVE-2024-43374
  - CVE-2024-41957
[USN-6991-1] AIOHTTP vulnerability
- 1 CVEs addressed in Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS)
  - CVE-2024-23334
[USN-6995-1] Thunderbird vulnerabilities
- 10 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS)
[USN-6996-1] WebKitGTK vulnerabilities
- 6 CVEs addressed in Jammy (22.04 LTS), Noble (24.04 LTS)
[USN-6841-2] PHP vulnerability
- 1 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM)
  - CVE-2024-5458
[USN-6997-1, USN-6997-2] LibTIFF vulnerability
- 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), Noble (24.04 LTS)
  - CVE-2024-7006
[USN-6994-1] Netty vulnerabilities
- 2 CVEs addressed in Jammy (22.04 LTS)
  - CVE-2023-44487
  - CVE-2023-34462
- HTTP/2 DoS, seen exploited in the wild and listen on the CISA KEV
[USN-6998-1] Unbound vulnerabilities
- 2 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), Noble (24.04 LTS)
  - CVE-2024-43168
  - CVE-2024-43167
[USN-6999-1] Linux kernel vulnerabilities
- 220 CVEs addressed in Noble (24.04 LTS)
- Full CVE list elided - see USN for details
[USN-7003-1, USN-7003-2, USN-7003-3] Linux kernel vulnerabilities
- 85 CVEs addressed in Bionic ESM (18.04 ESM), Focal (20.04 LTS)
- Full CVE list elided - see USN for details
[USN-7004-1] Linux kernel vulnerabilities
- 221 CVEs addressed in Noble (24.04 LTS)
- Full CVE list elided - see USN for details
[USN-7005-1, USN-7005-2] Linux kernel vulnerabilities
- 219 CVEs addressed in Jammy (22.04 LTS), Noble (24.04 LTS)
- Full CVE list elided - see USN for details
[USN-7006-1] Linux kernel vulnerabilities
- 94 CVEs addressed in Focal (20.04 LTS)
- Full CVE list elided - see USN for details
[USN-7007-1] Linux kernel vulnerabilities
- 219 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS)
- Full CVE list elided - see USN for details
[USN-7008-1] Linux kernel vulnerabilities
- 222 CVEs addressed in Jammy (22.04 LTS)
- Full CVE list elided - see USN for details
[USN-7009-1] Linux kernel vulnerabilities
- 219 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS)
- Full CVE list elided - see USN for details
[USN-7019-1] Linux kernel vulnerabilities
- 429 CVEs addressed in Jammy (22.04 LTS)
- Full CVE list elided - see USN for details
[USN-7002-1] Setuptools vulnerability
- 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), Noble (24.04 LTS)
  - CVE-2024-6345
[USN-7000-1, USN-7000-2] Expat vulnerabilities
- 3 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), Noble (24.04 LTS)
[USN-7001-1, USN-7001-2] xmltok library vulnerabilities
- 2 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS)
  - CVE-2024-45491
  - CVE-2024-45490
[USN-6560-3] OpenSSH vulnerability
- 1 CVEs addressed in Xenial ESM (16.04 ESM)
  - CVE-2023-51385
[USN-7011-1, USN-7011-2] ClamAV vulnerabilities
- 2 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS)
  - CVE-2024-20506
  - CVE-2024-20505
[USN-7012-1] curl vulnerability
- 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS)
  - CVE-2024-8096
[USN-7013-1] Dovecot vulnerabilities
- 2 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS)
  - CVE-2024-23185
  - CVE-2024-23184
[USN-7014-1] nginx vulnerability
- 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS)
  - CVE-2024-7347
[USN-7015-1] Python vulnerabilities
- 5 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS)
[USN-7010-1] DCMTK vulnerabilities
- 9 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS)
[USN-7016-1] FRR vulnerability
- 1 CVEs addressed in Jammy (22.04 LTS), Noble (24.04 LTS)
  - CVE-2024-44070
[USN-7017-1] Quagga vulnerability
- 1 CVEs addressed in Focal (20.04 LTS)
  - CVE-2024-44070
[USN-7018-1] OpenSSL vulnerabilities
- 6 CVEs addressed in Trusty ESM (14.04 ESM)
Goings on in Ubuntu Security Community

Linux Security Summit Europe 2024 (03:44)
- https://events.linuxfoundation.org/linux-security-summit-europe/program/schedule/
- Sep 16-17 - Vienna, Austria
- John Johansen and Maxime Bélair from AppArmor team presented “Restricting Unprivileged User Namespaces in Ubuntu”
  - https://youtu.be/yCHGmdXpylA?t=1053
  - https://static.sched.com/hosted_files/lsseu2024/ed/Restricting%20Unprivileged%20User%20Namespaces%20In%20Ubuntu.pdf
- Other talks
  - Deep-dive into xz-utils supply chain attack
  - Internals of the SLUB memory allocator for exploit developers
  - Landlock update - including details of new IOCTL restrictions etc
  - systemd and TPM2 update
Official announcement of Permissions Prompting in Ubuntu 24.10 (09:00)
- https://discourse.ubuntu.com/t/ubuntu-desktop-s-24-10-dev-cycle-part-5-introducing-permissions-prompting/47963
- Ubuntu Security Center with snapd-based AppArmor home file access prompting preview in episode 236
- Even works for command-line applications etc - not just graphical
- Covers future developments as well:
  - Better default response suggestions based on user feedback.
  - Shell integration of the prompting pop-ups (eg full screen takeovers)
  - Improved rule management summaries and better messaging of overlapping or redundant prompts.
  - Expansion of the prompting system to cover additional snap interfaces such as camera and microphone access.
  - Smarter client side analysis of prompts, recommending additional options if multiple similar prompts are detected.
Version 2.1 of IntelⓇ TDX on Ubuntu 24.04 LTS Released (11:46)
- https://discourse.ubuntu.com/t/version-2-1-of-intel-tdx-on-ubuntu-24-04-lts-released/47918/1
- Confidential computing - using TDX to run VMs in confidential mode - runs workloads (VMs) in hardware-backed isolated execution environments (Trust Domains). VM memory isolation via encryption in hardware so can’t be accessed by the hypervisor, remote attestation etc (Confidential Computing with Ijlal Loutfi and Karen Horovitz from Episode 230)
- https://discourse.ubuntu.com/t/intel-tdx-1-0-technology-preview-available-on-ubuntu-23-10/40698
- Scripting to setup the required elements to use TDX on Ubuntu 24.04 host and then setup guest VMs to run in confidential mode
  - Install server image, run scripts, enable TDX in BIOS, create VM images etc
  - Can also configure remote attestation of VM too
- See full changes at https://github.com/canonical/tdx/releases/tag/2.1
Ubuntu 22.04.5 LTS released (13:45)
- https://discourse.ubuntu.com/t/jammy-jellyfish-point-release-changes/29835/8
  - Only covers changes in main and restricted, doesn’t list security updates either
- https://discourse.ubuntu.com/t/jammy-jellyfish-release-notes/24668
AppArmor security update for CVE-2016-1585 published (14:23)
- Upcoming AppArmor Security update for CVE-2016-1585 from Episode 226
- https://discourse.ubuntu.com/t/upcoming-apparmor-security-update-for-cve-2016-1585/44268/3
- Now published to -updates pocket for 20.04 LTS and 22.04 LTS
- Will be published to -security pocket next week
Get in contact
20 September 2024, 2:27 am
18 minutes 23 seconds

Episode 236
Overview

The long awaited preview of snapd-based AppArmor file prompting is finally seeing the light of day, plus we cover the recent 24.04.1 LTS release and the podcast officially moves to a fortnightly cycle.

This week in Ubuntu Security Updates

45 unique CVEs addressed

[USN-6972-4] Linux kernel (Oracle) vulnerabilities
- 18 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM)
[USN-6982-1] Dovecot vulnerabilities
- 2 CVEs addressed in Noble (24.04 LTS)
  - CVE-2024-23185
  - CVE-2024-23184
[USN-6983-1] FFmpeg vulnerability
- 1 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS)
  - CVE-2024-32230
[USN-6984-1] WebOb vulnerability
- 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS)
  - CVE-2024-42353
[USN-6973-4] Linux kernel (Raspberry Pi) vulnerabilities
- 9 CVEs addressed in Bionic ESM (18.04 ESM)
[USN-6981-2] Drupal vulnerabilities
- 3 CVEs addressed in Trusty ESM (14.04 ESM)
- 2 of these are in the CISA KEV - Discussion of CISA KEV from Episode 231
[USN-6986-1] OpenSSL vulnerability
- 1 CVEs addressed in Jammy (22.04 LTS), Noble (24.04 LTS)
  - CVE-2024-6119
[USN-6987-1] Django vulnerabilities
- 2 CVEs addressed in Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS)
  - CVE-2024-45231
  - CVE-2024-45230
[USN-6988-1] Twisted vulnerabilities
- 2 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), Noble (24.04 LTS)
  - CVE-2024-41810
  - CVE-2024-41671
[USN-6985-1] ImageMagick vulnerabilities
- 11 CVEs addressed in Trusty ESM (14.04 ESM)
Goings on in Ubuntu Security Community

Ubuntu 24.04.1 LTS released (02:55)
- On 29th August - https://lists.ubuntu.com/archives/ubuntu-announce/2024-August/000304.html
- https://discourse.ubuntu.com/t/ubuntu-24-04-lts-noble-numbat-release-notes/39890
- Discussed high level features previously in Ubuntu 24.04 LTS (Noble Numbat) released from Episode 227
  - New security features / improvements:
    
    Unprivileged user namespace restrictions
    
    Binary hardening
    
    AppArmor 4
    
    Disabling of old TLS versions
    
    Upstream Kernel Security Features
    
    Intel shadow stack support
    
    Secure virtualisation with AMD SEV-SNP and Intel TDX
    
    Strict compile-time bounds checking
- Initially offered upgrades from 22.04 but this has been pulled just recently due to reports of a critical bug in the ubuntu-release-upgrader package and its interaction with the apt solver - essentially resulting in packages like linux-headers being in an broken state since it would remove some packages that were seen as obsolete but which were still required due to other packages depending on them
  - likely will not be fixed until early next week
Ubuntu Security Center with snapd-based AppArmor home file access prompting preview (05:45)
- https://news.itsfoss.com/ubuntu-security-center-near-stable/
- Details the new Desktop Security Center application
  - Written by the Ubuntu Desktop team - new application built using Flutter + Dart etc and published a snap
  - Eventually this will allow to manage various security related things like full-disk encryption, enabling/usage of Ubuntu Pro, Firewall control and finally for snap permission prompting
    
    this last feature is the only one currently supported - has a single toggle which is to enable “snaps to ask for system permissions” - aka. snapd-based AppArmor prompting
    
    and then once this is enabled, allows the specific permissions to be futher fine-tuned
- What is AppArmor?
- AppArmor policies - and MAC systems in general are static - policy defined by sysadmin etc
- Not well suited for dynamic applications that are controlled by a user - like desktop / CLI etc - can’t know in advance every possible file a user may want to open in say Firefox so have to grant access to all files in home directory just in case
- Ideally system would only allow files that the user explicitly chooses - number of ways this can be done, XDG Portals one such way - using Powerbox concept pioneered in tools from the object-capability based security community like CapDesk/Polaris and Plash (principle of least-authority shell) - access is mediated by a privileged component that acts with the users whole authority to then delegate some of that authority to the application - seen say in the file-chooser dialog with portals - this runs outside of the scope of the application itself and so has the full, unrestricted access to the system to allow a file to be chosen - then the application is then just given a file-descriptor to the file to grant it the access (or similar)
- This only works in the case of applications that open files interactively - can’t allow the user to explicitly grant access to the configuration file that gets loaded from a well-known path at startup in a server application etc
- One way to handle that case is to alert the user and explicitly prompt them for that access - and this is currently how this new prompting feature works
- When the feature is enabled, the usual broad-based access rules for the home interface in snapd get tagged with a prompt attribute - any access then which would normally be allowed is instead delegated to a trusted helper application which displays a dialog to the user asking them to explicitly allow such access
- since this happens directly in the system-call path within the kernel, the application itself is unaware that this is happening - but is just suspended whilst waiting for the users response - and then assuming they grant the access it proceeds as normal (or if they deny then the application gets a permission denied error)
- Completely transparent to the application and supports any kind of file-access regardless of which API might be used (unlike portals which only support the regular file-chooser scenario)
- Allows tighter control of what files a snap is granted access to - and can be managed by the user in the Security Center later to revoke any such permission that they granted
- Has been in development for a long time, and is certainly not a new concept - seccomp has supported this via the seccomp_unotify interface - allows to delegate seccomp decisions to userspace in a very similar manner - existed since the 5.5 kernel released in January 2020
- Even before that, prototype LSMs existed which implemented this kind of functionality (https://sourceforge.net/projects/pulse-lsm/ / https://crpit.scem.westernsydney.edu.au/confpapers/CRPITV81Murray.pdf)
- Can test this now on an up-to-date 24.04 or 24.10 install
  - Need to use snapd from the latest/edge channel and then install both the desktop-security-center snap as well as the prompting-client snap
  - Launch Security Center and toggle the option
- Note this is experimental but has undergone a fair amount of internal testing
- Very exciting to see this finally available in this pre-release stage - has been talked about since at least 2018
- Give it a spin and provide feedback - I would suggest to use the link in the security center application itself for this but it is not working currently - instead report via a Github issue on the desktop-security-center project
Get in contact
6 September 2024, 10:20 am
17 minutes 40 seconds

Episode 235
Overview

A recent Microsoft Windows update breaks Linux dual-boot - or does it? This week we look into reports of the recent Windows patch-Tuesday update breaking dual-boot, including a deep-dive into the technical details of Secure Boot, SBAT, grub, shim and more, plus we look at a vulnerability in GNOME Shell and the handling of captive portals as well.

This week in Ubuntu Security Updates

135 unique CVEs addressed

[USN-6960-1] RMagick vulnerability
- 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS)
  - CVE-2023-5349
[USN-6951-2] Linux kernel (Azure) vulnerabilities
- 83 CVEs addressed in Focal (20.04 LTS)
[USN-6961-1] BusyBox vulnerabilities
- 4 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS)
[USN-6962-1] LibreOffice vulnerability
- 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS)
  - CVE-2024-6472
[USN-6963-1] GNOME Shell vulnerability (01:03)
- 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS)
  - CVE-2024-36472
- Captive portal detection would spawn an embedded webkit browser automatically to allow user to login etc
- But the page the user gets directed to is controlled by the attacker and can contain arbitrary javascript etc
- Upstream bug report claimed could then get a reverse shell etc - not clear this is the case since would still be constrained by the webkitgtk browser so would also need a sandbox escape etc.
- This update then includes a change to both not automatically open the captive portal page (instead it will show a notification and the user needs to click that) BUT to also disable the use of the webkitgtk-based embedded browser and instead use the users regular browser
[USN-6909-3] Bind vulnerabilities
- 2 CVEs addressed in Xenial ESM (16.04 ESM)
  - CVE-2024-1975
  - CVE-2024-1737
[USN-6964-1] ORC vulnerability
- 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS)
  - CVE-2024-40897
[USN-6837-2] Rack vulnerabilitie
- 3 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)
[USN-6966-1] Firefox vulnerabilities
- 13 CVEs addressed in Focal (20.04 LTS)
[USN-6966-2] Firefox regressions
- 13 CVEs addressed in Focal (20.04 LTS)
[USN-6951-3] Linux kernel (Azure) vulnerabilities
- 83 CVEs addressed in Bionic ESM (18.04 ESM)
[USN-6968-1] PostgreSQL vulnerability
- 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS)
  - CVE-2024-7348
[USN-6967-1] Intel Microcode vulnerabilities
- 5 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS)
[LSN-0106-1] Linux kernel vulnerability
- 3 CVEs addressed in
[USN-6969-1] Cacti vulnerabilities
- 10 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), Noble (24.04 LTS)
[USN-6970-1] exfatprogs vulnerability
- 1 CVEs addressed in Jammy (22.04 LTS)
  - CVE-2023-45897
[USN-6944-2] curl vulnerability
- 1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM)
  - CVE-2024-7264
[USN-6965-1] Vim vulnerabilities
- 5 CVEs addressed in Trusty ESM (14.04 ESM)
Goings on in Ubuntu Security Community

Reports of dual-boot Linux/Windows machines failing to boot (04:30)
- https://arstechnica.com/security/2024/08/a-patch-microsoft-spent-2-years-preparing-is-making-a-mess-for-some-linux-users/
- https://msrc.microsoft.com/update-guide/en-US/advisory/CVE-2022-2601
- https://discourse.ubuntu.com/t/sbat-self-check-failed-mitigating-the-impact-of-shim-15-7-revocation-on-the-ubuntu-boot-process-for-devices-running-windows/47378
- Microsoft released an update for Windows on 13th August 2024 - revoking old versions of grub that were susceptible to CVE-2022-2601
- How do you revoke grub?
  - Secure Boot relies on each component in the boot chain verifying that the next component is signed with a valid signature before it is then loaded
    
    UEFI BIOS validates shim
    
    shim validates grub
    
    grub validates kernel
    
    kernel validates kernel modules etc
  - UEFI specification has effectively a CRL - list of hashes of binaries which shouldn’t be trusted
  - BUT there is only limited space in the UEFI storage - after the original BootHole vulnerabilities revoked a huge number of grub binaries from many different distros, some devices failed to boot as the NVRAM was too full
  - Microsoft and Red Hat and other maintainers of shim decided on a new scheme, called SBAT - Secure Boot Advanced Targeting
    
    maintains a generation number for each component in the boot chain
    
    when say shim or grub gets updated to fix a bunch more security vulnerabilities, upstream bumps the generation number
    
    shim/grub then embeds the generation number within itself
    
    Signed UEFI variable then lists which generation numbers are acceptable
  - shim checks the generation number of a binary (grub/fwupd etc) against this list and if it is too old refuses to load it
- In Ubuntu this was patched back in Jan 2023 and was documented on the Ubuntu Discourse - in this case we updated shim to a newer version which itself revoked an older grub, grub,1
- Now Microsoft’s update revokes grub,2, ie sets the minimum generation number for grub to 3
- You can inspect the SBAT policy by either directly reading the associated EFI variable or using mokutil --list-sbat-revocations
cat /sys/firmware/efi/efivars/SbatLevelRT-605dab50-e046-4300-abb6-3dd810dd8b23 mokutil --list-sbat-revocations sbat,1,2023012900 shim,2 grub,3 grub.debian,4 objdump -j .sbat -s /boot/efi/EFI/ubuntu/grubx64.efi | xxd -r sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md grub,4,Free Software Foundation,grub,2.12,https://www.gnu.org/software/grub/ grub.ubuntu,2,Ubuntu,grub2,2.12-5ubuntu4,https://www.ubuntu.com/ grub.peimage,2,Canonical,grub2,2.12-5ubuntu4,https://salsa.debian.org/grub-team/grub/-/blob/master/debian/patches/secure-boot/efi-use-peimage-shim.patch rm -rf grub2-signed mkdir grub2-signed pushd grub2-signed >/dev/null || exit for rel in focal jammy noble; do mkdir $rel pushd $rel >/dev/null || exit pull-lp-debs grub2-signed $rel-security 1>/dev/null 2>/dev/null || pull-lp-debs grub2-signed $rel-release 1>/dev/null 2>/dev/null dpkg-deb -x grub-efi-amd64-signed*.deb grub2-signed echo $rel echo ----- find . -name grubx64.efi.signed -exec objdump -j .sbat -s {} \; | tail -n +5 | xxd -r popd >/dev/null || exit done popd >/dev/null focal ----- sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md grub,4,Free Software Foundation,grub,2.06,https://www.gnu.org/software/grub/ grub.ubuntu,1,Ubuntu,grub2,2.06-2ubuntu14.4,https://www.ubuntu.com/ jammy ----- sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md grub,4,Free Software Foundation,grub,2.06,https://www.gnu.org/software/grub/ grub.ubuntu,1,Ubuntu,grub2,2.06-2ubuntu14.4,https://www.ubuntu.com/ noble ----- sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md grub,4,Free Software Foundation,grub,2.12,https://www.gnu.org/software/grub/ grub.ubuntu,2,Ubuntu,grub2,2.12-1ubuntu7,https://www.ubuntu.com/ grub.peimage,2,Canonical,grub2,2.12-1ubuntu7,https://salsa.debian.org/grub-team/grub/-/blob/master/debian/patches/secure-boot/efi-use-peimage-shim.patch
- So if all the current LTS releases have a grub with a generation number higher than this, why are so many machines failing to boot?
  - It is not just grub that is the issue - shim itself also got revoked in the same update https://msrc.microsoft.com/update-guide/en-US/advisory/CVE-2023-40547 - so shim 15.8 (ie. 4th SBAT generation of shim) is now required
  - Unfortunately, the related updates for this shim in Ubuntu are still in the process of being released - https://bugs.launchpad.net/ubuntu/+source/shim/+bug/2051151
rm -rf shim-signed mkdir shim-signed pushd shim-signed >/dev/null || exit for rel in focal jammy noble; do mkdir $rel pushd $rel >/dev/null || exit pull-lp-debs shim-signed $rel-security 1>/dev/null 2>/dev/null || pull-lp-debs shim-signed $rel-release 1>/dev/null 2>/dev/null dpkg-deb -x shim-signed*.deb shim-signed echo $rel echo ----- find . -name shimx64.efi.signed.latest -exec objdump -j .sbat -s {} \; | tail -n +5 | xxd -r popd >/dev/null || exit done popd >/dev/null focal ----- sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md shim,3,UEFI shim,shim,1,https://github.com/rhboot/shim shim.ubuntu,1,Ubuntu,shim,15.7-0ubuntu1,https://www.ubuntu.com/ jammy ----- sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md shim,3,UEFI shim,shim,1,https://github.com/rhboot/shim shim.ubuntu,1,Ubuntu,shim,15.7-0ubuntu1,https://www.ubuntu.com/ noble ----- sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md shim,4,UEFI shim,shim,1,https://github.com/rhboot/shim shim.ubuntu,1,Ubuntu,shim,15.8-0ubuntu1,https://www.ubuntu.com/
- only noble has a new-enough shim in the security/release pocket - both focal and jammy have the older one - but the new 4th generation shim is currently undergoing testing in the -proposed pocket and will be released next week
- until then, if affected, need to disable secure boot in BIOS then can either wait until the new shim is released OR just reboot twice in this mode and shim will automoatically reset the SBAT policy to the previous version, allowing the older shim to still be used
- then can re-enable Secure Boot in BIOS
- Once new shim is released it will reinstall the new SBAT policy to revoke its older version
- One other thing, this also means the old ISOs won’t boot either
  - 24.04.1 will be released on 29th August
  - upcoming 22.04.5 release will also have this new shim too
  - no further ISO spins planned for 20.04 - so if you really want to install this release on new hardware, would need to disable secure boot first, do the install, then install updates to get the new shim, and re-enable secure boot
Get in contact
23 August 2024, 5:14 am
29 minutes 11 seconds

Episode 234
Overview

This week we take a deep dive behind-the-scenes look into how the team handled a recent report from Snyk’s Security Lab of a local privilege escalation vulnerability in wpa_supplicant plus we cover security updates in Prometheus Alertmanager, OpenSSL, Exim, snapd, Gross, curl and more.

This week in Ubuntu Security Updates

185 unique CVEs addressed

[USN-6935-1] Prometheus Alertmanager vulnerability (01:08)
- 1 CVEs addressed in Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS)
  - CVE-2023-40577
- Stored XSS via the Alertmanager UI - alerts API allows to specify a URL which should be able to be called interactively by the user from the UI - an attacker instead could POST to this with arbitrary JavaScript which would then get included in the generated HTML and hence run on users when viewing the UI
- Fixed to validate this field is actually a URL before including in the generated UI page
[USN-6938-1] Linux kernel vulnerabilities (02:05)
- 31 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM)
- 4.4 - generic, AWS, KVM, Low Latency, Virtual
[USN-6922-2] Linux kernel vulnerabilities
- 4 CVEs addressed in Jammy (22.04 LTS)
- 6.5 lowlatency
[USN-6926-2] Linux kernel vulnerabilities
- 30 CVEs addressed in Trusty ESM (14.04 ESM), Bionic ESM (18.04 ESM)
- 4.15 Azure
[USN-6895-4] Linux kernel vulnerabilities
- 100 CVEs addressed in Jammy (22.04 LTS)
- 6.5 OEM
[USN-6937-1] OpenSSL vulnerabilities (03:04)
- 4 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS)
- Four low priority issues
  - Possible UAF in SSL_free_buffers API - requires an application to directly call this function - across the entire Ubuntu package ecosystem there doesn’t appear to be any packages that do this so highly unlikely to be an issue in practice
  - Similarly, in another rarely used function SSL_select_next_proto - if called with an empty buffer list would read other private memory - ie OOB read - and potentially then either crash or return private data
    
    but again this is not expected to occur in practice
  - CPU-based DoS when validating long / crafted DSA keys
    
    simply check if using to large a modulus and error in that case
  - If had set the SSL_OP_NO_TICKET option would possibly get into a state where the session cache would not be flushed and so would grow unbounded - memory based DoS
[USN-6913-2] phpCAS vulnerability (04:51)
- 1 CVEs addressed in Xenial ESM (16.04 ESM)
  - CVE-2022-39369
- [USN-6913-1] phpCAS vulnerability from Episode 233
[USN-6936-1] Apache Commons Collections vulnerability (05:03)
- 1 CVEs addressed in Trusty ESM (14.04 ESM)
  - CVE-2015-4852
- Unsafe deserialisation - could allow to overwrite an object with an attacker controlled version containing code to be executed - RCE
[USN-6939-1] Exim vulnerability (05:31)
- 1 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS)
  - CVE-2024-39929
- Mishandles multiline filename header and so a crafted value could bypass the MIME type extension blocking mechanism - allowing executables etc to be delivered to users
[USN-6933-1] ClickHouse vulnerabilities (06:00)
- 5 CVEs addressed in Focal (20.04 LTS)
- real-time analytics DBMS
- Mostly written in C++ so not surprisingly has various memory safety issues
  - All in the the LZ4 compression codec - uses an attacker controlled 16-bit unsiged value as the offset to read from the compressed data - then this value is also used when copying the data but there is no check on the upper bound so could index outside of the data
  - Also a heap buffer overflow during this same data copy since doesn’t verify the size of the destination either
[USN-6940-1] snapd vulnerabilities (06:55)
- 3 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS)
- 2 quite similar issues discovered by one of the engineers on the snapd team - Zeyad Gouda
  - snaps are squashfs images - in general they are just mounted but certain files from the squashfs get extracted by snapd and placed on the regular file-system (ie. desktop files and icons for launchers etc) - as such, snapd would read the contents of these files and then write them out - if the file was actually a named pipe, snapd would block forever - DoS
  - similarly, if the file was a symlink that pointed to an existing file on the file-system, when opening that file (which is a symlink) snapd would read the contents of the other file and write it out - recall these are desktop files etc so they get written to /usr/share/applications which is world-readable - so if the symlink pointed to /etc/shadow then you would get a copy of this written out as world-readable - so an unprivileged user on the system could then possibly escalate their privileges
- 3rd issue was AppArmor sandbox
  - home interface allows snaps to read/write to your home directory
  - On Ubuntu, if the bin directory exists, it gets automatically added to your PATH
  - AppArmor policy for snapd took this into account and would stop snaps from writing files into this directory (and hence say creating a shell script that you would then execute later, outside of the snap sandbox)
  - BUT it did not prevent a snap from creating this directory if it didn’t already exist
[USN-6941-1] Python vulnerability (11:15)
- 1 CVEs addressed in Noble (24.04 LTS)
  - CVE-2024-4032
- [USN-6928-1] Python vulnerabilities from Episode 233
[USN-6909-2] Bind vulnerabilities (11:30)
- 2 CVEs addressed in Bionic ESM (18.04 ESM)
  - CVE-2024-1975
  - CVE-2024-1737
- 2 different CPU-based DoS
  - Didn’t restrict the number of resource records for a given hostname - if an attacker could arrange so a large number of RRs then could degrade the performace of bind due to it having to perform expensive lookups across all the records
    
    introduce a limit of 100 RRs for a given name
  - Removed support DNSSEC SIG(0) transaction signatures since they could be abused to perform a CPU-based DoS
[USN-6943-1] Tomcat vulnerabilities (12:26)
- 5 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS)
[USN-6942-1] Gross vulnerability (12:33)
- 1 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS)
  - CVE-2023-52159
- greylisting server used in MTA setup to minimise spam - uses DNS block lists to tag mails which come from these domains as possible spam
- stack buffer overflow through the use of strncat() during logging
  - would concatenate a list of parameters as string into a fixed size buffer on the stack but would pass the entire buffer size as the length argument rather than accounting for the remaining space in the buffer
  - as these parameters can be controlled by an attacker can be used to either crash grossd or get RCE
[USN-6944-1] curl vulnerability (13:55)
- 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS)
  - CVE-2024-7264
- Possible OOB read through crafted ASN.1 Generalized Time field when parsing TLS certificate chain - would potentially use a negative length value and hence try calculate the length of a string but pointing to the wrong memory region - crash / info leak
- Need to specifically use the https://curl.se/libcurl/c/CURLINFO_CERTINFO.html option though to be vulnerable
[USN-6200-2] ImageMagick vulnerabilities (14:52)
- 20 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS)
- [USN-6200-1] ImageMagick vulnerabilities from Episode 202
[USN-6946-1] Django vulnerabilities (15:04)
- 4 CVEs addressed in Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS)
- SQL injection via crafted JSON in methods on the QuerySet class, and various DoS - one via very large inputs of Unicode characters in certain input fields, another through floatformat template filter - would use a large amount of memory if given a number in scientific notation with a large exponent
[USN-6945-1] wpa_supplicant and hostapd vulnerability (15:42)
- 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), Noble (24.04 LTS)
  - CVE-2024-5290
- Possible privilege escalation through abuse of DBus method to get wpa_supplicant to load an attacker controlled shared object into memory
Goings on in Ubuntu Security Community

Discussion of CVE-2024-5290 in wpa_supplicant (16:10)
- Reported privately to us by Rory McNamara from Snyk as part of a larger disclosure of various security issues they had found
- Issue specific to Debian and Ubuntu - includes patch to the dbus policy for wpa_supplicant to allow various methods to be called by users in the netdev group
  - historical hangover before we had network manager etc to do this
  - nowadays, Network Manager allows the user who is logged in to control access to wireless networks etc
  - historically though, Debian had the netdev group instead - so you would add your user to this group to allow them to configure network settings etc
  - so makes sense to allow that group to control wpa_supplicant via its dbus interface
- DBus API includes a method called CreateInterface
  - takes an argument called ConfigFile which specifies the path to a configuration file using the format of wpa_supplicant.conf
  - config file includes a parameter for opensc_engine_path or similarly PKCS11 engine and module paths
  - these are shared object which then get dynamically loaded into memory by wpa_supplicant
- hence could overwrite existing functions and therefore get code execution as root - since wpa_supplicant runs as root
- upstream actually includes a patch to hard-code these values at compile-time and not allow them to be specified in the config file BUT we don’t use this in Ubuntu since it was only introduced recently (so not all Ubuntu releases include it) but regardless, we want to support setups where these modules may live in different locations
- Discussed how to possibly fix this in LP: #2067613
  - Is not an issue for upstream since the upstream policy only allows root to use this dbus method so there is no privilege escalation
  - Could allow-list various paths but was not clear which ones to use
    
    Lukas from Foundations team (and maintainer of Netplan) tried searching for any users of these config parameters but couldn’t find anything in the archive
    
    However, users may still be configuring things so don’t want to break their setups
  - Or could tighten up the DBus policy for the netdev group to NOT include access to this method - but this may break existing things that are using the netdev group and this method
    
    Marc from our team then tried looking for anything in Ubuntu which used the wpa_supplicant DBus interface - none appear to make use of the netdev group
    
    Considered dropping support entirely for this feature which allows the netdev group access since in general this should be done with NetworkManager or netplan nowadays anyway
    
    But this is such a long-standing piece of functionality it wasn’t clear what the possible regression potential would be
  - Or we could patch wpa_supplicant to check that the specified module was owned by root - this should then stop an unprivileged user from creating their own module and specifying it as it wouldn’t be owned by root
    
    This looked promising and a patch was drafted and tested against the proof-of-concept and was able to block it
    
    However, Rory came back with some excellent research showing it could be bypassed by some quite creative use of a crafted FUSE filesystem in combination with overlayfs inside an unprivileged user namespace (ie. unpriv userns strikes again)
    
    create a FUSE which lies about the uid of a file to say it is 0 (root)
    
    mount this as an unprivileged user
    
    create a new user and mount namespace through unshare
    
    within that (since you are “root”) mount an overlay filesystem using the FUSE fs
    
    Specify the path to this file using the special root link inside the proc filesystem - which points to the actual root directory of that process - and since the FUSE fs lies about the UID it looks like root owned
  - So at this point we were running out of ideas - Luci from our team suggested manually walking the path to the specified file akin to how realpath works (which should block the ability to read it via the proc symlink)
    
    but this was considered too complicated and possibly prone to a TOCTOU race
  - Finally Marc proposed to simply allow-list anything under /usr/lib - since anything installed from the archive would live here - in this case we simply call realpath() directly on the provided path name and if it doesn’t start with /usr/lib then deny loading of the module
  - No way to race against this and would seem to have the least chance of regression
    
    Yes if using a non-standard location like /opt would now fail BUT if you can write to /opt then you can write to somewhere in /usr/lib - so is easy to fix as well
  - Was tested significantly both with a dummy PKCS11 provider as well as a real one to ensure works as expected (both to prevent the exploit but also to work as intended)
- Eventual solution then was both secure but also would appear to minimise the chance of regressions
  - None reported so far anyway ;)
- Demonstrates the careful balance between security and possible regressions
- Also the team effort of both the security team and other Ubuntu teams
  - Thanks to Marc, Luci, Mark E, and Sudhakar on our side, and Lukas from Foundations, but most importantly to Rory from Snyk for both reporting the vuln but also in their help evaluating the various proposed solutions
Get in contact
9 August 2024, 9:52 am
24 minutes 7 seconds

Episode 233
Overview

This week we take a look at the recent Crowdstrike outage and what we can learn from it compared to the testing and release process for security updates in Ubuntu, plus we cover details of vulnerabilities in poppler, phpCAS, EDK II, Python, OpenJDK and one package with over 300 CVE fixes in a single update.

This week in Ubuntu Security Updates

462 unique CVEs addressed

[USN-6915-1] poppler vulnerability (01:35)
- 1 CVEs addressed in Jammy (22.04 LTS), Noble (24.04 LTS)
  - CVE-2024-6239
- Installed by default in Ubuntu due to use by cups
- PDF document format describes a Catalog which has a tree of destinations - essentially hyperlinks within the document. These can be either a page number etc or a named location within the document. If open a crafted document with a missing name property for a destination - name would then be NULL and would trigger a NULL ptr deref -> crash -> DoS
[USN-6913-1] phpCAS vulnerability (02:26)
- 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS)
  - CVE-2022-39369
- Authentication library for PHP to allow PHP applications to authenticates users against a Central Authentication Server (ie. SSO).
- When used for SSO, a client who is trying to use a web application gets directed to the CAS. The CAS then authenticates the user and returns a service ticket - the client then needs to validate this ticket with the CAS since it could have possibly been injected via the application. To do this, pass the ticket along with its own service identifier to CAS - and if this succeeds is provided with the details of which user was authenticated etc.
- For clients, previously would use HTTP headers to determine where the CAS server was to authenticate the ticket. Since these can be manipulated by a malicious application, could essentially redirect the client to send the ticket to the attacker who could then use that to impersonate the client and login as the user.
- Fix requires a refactor to include an additional API parameter which specifies either a fixed CAS server for the client to use, or a mechanism to auto-discover this in a secure way - either way, applications using phpCAS now need to be updated.
[USN-6914-1] OCS Inventory vulnerability
- 1 CVEs addressed in Jammy (22.04 LTS)
  - CVE-2022-39369
- Same as above since has an embedded copy of phpCAS
[USN-6916-1] Lua vulnerabilities (04:44)
- 2 CVEs addressed in Jammy (22.04 LTS)
  - CVE-2022-33099
  - CVE-2022-28805
- Heap buffer over-read and a possible heap buffer over-flow via recursive error handling - looks like both require to be interpreting malicious code
[USN-6920-1] EDK II vulnerabilities (05:04)
- 5 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM)
- UEFI firmware implementation in qemu etc
- Various missing bounds checks -> stack and heap buffer overflows -> DoS or code execution in BIOS context -> privilege escalation within VM
[USN-6928-1] Python vulnerabilities (05:49)
- 2 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS)
  - CVE-2024-4032
  - CVE-2024-0397
- Memory race in the ssl module - can call into various functions to get certificate information at the same time as certs are loaded if happening to be doing a TLS handshake with a certificate directory configured - all via different threads. Python would then possibly return inconsistent results leading to various issues
- Occurs since ssl module is implemented in C to interface with openssl and did not properly lock access to the certificate store
[USN-6929-1, USN-6930-1] OpenJDK 8 and OpenJDK 11 vulnerabilities (06:52)
- 6 CVEs addressed in Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS)
- Latest upstream releases of OpenJDK 8 and 11
- 8u422-b05-1, 11.0.24+8
- Fixes various issues in the Hotspot and Concurrency components
[USN-6931-1, USN-6932-1] OpenJDK 17 and OpenJDK 21 vulnerabilities (07:11)
- 5 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS)
- Latest upstream releases of OpenJDK 17 and 21
- 17.0.12+7, 21.0.4+7
- Fixes the same issues in the Hotspot component
[USN-6934-1] MySQL vulnerabilities (07:29)
- 15 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS)
- Also latest upstream release
- 8.0.39
- Bug fixes, possible new features and incompatible changes - consult release notes:
[USN-6917-1] Linux kernel vulnerabilities (07:57)
- 156 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS)
- 5.15 - Azure + FDE (CVM)
[USN-6918-1] Linux kernel vulnerabilities
- 180 CVEs addressed in Noble (24.04 LTS)
- 6.8 - Oracle
[USN-6919-1] Linux kernel vulnerabilities
- 304 CVEs addressed in Jammy (22.04 LTS)
- 5.15 - Raspi
[USN-6922-1] Linux kernel vulnerabilities
- 4 CVEs addressed in Jammy (22.04 LTS)
- 6.5 - NVIDIA
[USN-6923-1, USN-6923-2] Linux kernel vulnerabilities
- 6 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS)
- 5.15 - generic, AWS, GCP, GKE, HWE, Intel-IOTG, KVM, LowLatency, NVIDIA, Oracle, IBM, Raspi
[USN-6921-1, USN-6921-2] Linux kernel vulnerabilities
- 7 CVEs addressed in Noble (24.04 LTS)
- 6.8 - generic, AWS, GCP, GKE, IBM, NVIDIA, OEM, Raspi, LowLatency
[USN-6924-1, USN-6924-2] Linux kernel vulnerabilities
- 7 CVEs addressed in Bionic ESM (18.04 ESM), Focal (20.04 LTS)
- 5.4 - generic, AWS, Azure, Bluefield, GCP, GKE, HWE, IBM, IOT, KVM, Raspi, Xilinx-ZynqMP
[USN-6925-1] Linux kernel vulnerability
- 1 CVEs addressed in Trusty ESM (14.04 ESM)
  - CVE-2024-26882
- 3.13 - generic, lowlatency, server, virtual
[USN-6926-1] Linux kernel vulnerabilities
- 30 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM)
- 4.15 - generic, AWS, HWE, GCP, KVM, Oracle
[USN-6927-1] Linux kernel vulnerabilities
- 161 CVEs addressed in Focal (20.04 LTS)
- 5.15 - GCP
Goings on in Ubuntu Security Community

Discussion of testing for security updates in light of CrowdStrike (11:20)
- Recent outage of over 8 million Windows machines running CrowdStrike Falcon
  - https://www.crowdstrike.com/falcon-content-update-remediation-and-guidance-hub/
- Initially very little information on what happened - CS have now released more details about the apparent testing that was done but clearly were never actually testing the combination of Windows + Falcon + Rapid Response Content otherwise would have observed this failure immediately
- Also clearly didn’t have any kind of staged/phased update process in place either
  - If you want to read a good analysis of the response from CS, https://verse.systems/blog/post/2024-07-25-parsing-crowdstrikes-post/
    
    Toby Murray (full disclosure, my brother) - Associate Professor and Co-Lead of Computer Science Research Group at School of Computing and Information Systems, University of Melbourne, Director, Defence Science Institute (Vic & Tas)
  - Future plans from CS now include gradual deployment of rules with “canaries” etc and then increased testing:
    
    Local dev testing, content update testing, stress, fuzz, fault-injection, stability and interface testing
    
    Toby (not surprisingly as an expert in formal software verification) advocates for a formal approach to validating rules and in-kernel code etc
- What can we learn from this for Ubuntu?
  - Formal methods might be tractable for a large company like CS who is developing a single, specific product like Falcon (particularly if they can reduce the size of their kernel module), this is not the case for a Linux distribution like Ubuntu which collates over 30,000 different open source software projects
    
    over 4TB of source code across the various releases
- Instead have to take the pragmatic approach of thorough testing
  - For regular SRUs - detailed review by SRU team including a thorough test plan, cross-package testing via Autopkgtest plus a minimum 7 day “soak” testing in the proposed pocket of the release before being pushed into the -updates pocket
  - Once in -updates, Phased Updates implements the gradual deployment model - you can check the progress of various updates at https://ubuntu-archive-team.ubuntu.com/phased-updates.html
    
    Watches for increased error reports via errors.ubuntu.com (captured via apport/whoopsie) and if detected stops the release of the package to users
- Compare that to the process for Security updates
  - Separate -security pocket in the archive which packages get published to immediately
    
    No standardised review by separate team
    
    instead adhoc reviews within the security team
    
    No documented test plan per update
    
    instead thorough test procedures including:
    
    checking for any changes in the build log (e.g. new compiler warnings/errors) and comparing the difference between the generated binaries (e.g. new / changed / missing symbols - ABI breaks)
    
    testing of the patched code including stepping through it with a debugger
    
    running any existing PoC or creating one if none exists and is feasible
    
    running any existing unit/integration tests within the package (including dep8/autopkgtests)
    
    test apt upgrade of the package is smooth
    
    QA regression testing scripts - maintained by the security team, implement various regression tests and system-level tests for different packages to exercise them in various different configurations
    
    Cross-package testing via security-britney - instance of the autopkgtest infrastructure that runs against the public Ubuntu Security Proposed PPA (and we have a similar internal instance for the different private PPAs we use for embargoed updates or ESM etc)
    
    No phased updates - instead immediate updates via specific security.ubuntu.com archive, combined with unattended-upgrades
    
    designed to deliver security updates as soon as possible to remediate issues
- In general, I would argue that the process we have in place results in more thorough testing for security updates - particularly checking for anything anomalous like new compiler warnings / symbols / unexpected changes in binaries etc as well as more thorough, standardised testing for packages through the QA Regression Testing repo scripts
- However, the lack of phased/progressive updates combined with the separate security.ubuntu.com archive and unattended-upgrades on by default, means any security update is delivered to Ubuntu users within 24 hours (on average) - BUT then any regression is also rolled out to all users in 24 hours as well
- As such, kicking off discussions around possible changes to our deployment strategy to potentially introduce some more guard rails on the deployment side
- If you have any thoughts, please let us know
Get in contact
2 August 2024, 7:35 am
More Episodes? Get the App

Ubuntu Security Podcast

Alex Murray

Overview

2024 Year in Review for Ubuntu Security (00:55)

full-disclosure necromancy with zombie CVEs

Development of unprivileged user namespace restrictions for Ubuntu 24.04 LTS

Linux kernel becomes a CNA

Ubuntu participates in Pwn2Own Vancouver

xz-utils / SSH backdoor supply-chain attack

Linux Security Summit NA and EU

Release of Ubuntu 24.04 LTS

regreSSHion remote unauthenticated code execution vulnerability in OpenSSH

Various other high profile vulnerabilities

Ubuntu/Windows Dual-boot regression

AppArmor-based snap file prompting experimental feature

Predictions for 2025 (14:35)

Get in contact

Overview

Deep dive into needrestart local privilege escalation vulnerabilities

[USN-7117-1] needrestart and Module::ScanDeps vulnerabilities

[USN-7117-2] needrestart regression

Get in contact

Overview

GoblinRAT Linux Malware teardown

Get in contact

Overview

Get in contact

Overview

Get in contact

Overview

Get in contact

Overview

This week in Ubuntu Security Updates (01:11)

[USN-6989-1] OpenStack vulnerability

[USN-6990-1] znc vulnerability

[USN-6992-1] Firefox vulnerabilities

[USN-6993-1] Vim vulnerabilities

[USN-6991-1] AIOHTTP vulnerability

[USN-6995-1] Thunderbird vulnerabilities

[USN-6996-1] WebKitGTK vulnerabilities

[USN-6841-2] PHP vulnerability

[USN-6997-1, USN-6997-2] LibTIFF vulnerability

[USN-6994-1] Netty vulnerabilities

[USN-6998-1] Unbound vulnerabilities

[USN-6999-1] Linux kernel vulnerabilities

[USN-7003-1, USN-7003-2, USN-7003-3] Linux kernel vulnerabilities

[USN-7004-1] Linux kernel vulnerabilities

[USN-7005-1, USN-7005-2] Linux kernel vulnerabilities

[USN-7006-1] Linux kernel vulnerabilities

[USN-7007-1] Linux kernel vulnerabilities

[USN-7008-1] Linux kernel vulnerabilities

[USN-7009-1] Linux kernel vulnerabilities

[USN-7019-1] Linux kernel vulnerabilities

[USN-7002-1] Setuptools vulnerability

[USN-7000-1, USN-7000-2] Expat vulnerabilities

[USN-7001-1, USN-7001-2] xmltok library vulnerabilities

[USN-6560-3] OpenSSH vulnerability

[USN-7011-1, USN-7011-2] ClamAV vulnerabilities

[USN-7012-1] curl vulnerability

[USN-7013-1] Dovecot vulnerabilities

[USN-7014-1] nginx vulnerability

[USN-7015-1] Python vulnerabilities

[USN-7010-1] DCMTK vulnerabilities

[USN-7016-1] FRR vulnerability

[USN-7017-1] Quagga vulnerability

[USN-7018-1] OpenSSL vulnerabilities

Goings on in Ubuntu Security Community

Linux Security Summit Europe 2024 (03:44)

Official announcement of Permissions Prompting in Ubuntu 24.10 (09:00)

Version 2.1 of IntelⓇ TDX on Ubuntu 24.04 LTS Released (11:46)

Ubuntu 22.04.5 LTS released (13:45)

AppArmor security update for CVE-2016-1585 published (14:23)

Get in contact

Overview

This week in Ubuntu Security Updates

[USN-6972-4] Linux kernel (Oracle) vulnerabilities

[USN-6982-1] Dovecot vulnerabilities

[USN-6983-1] FFmpeg vulnerability

[USN-6984-1] WebOb vulnerability

[USN-6973-4] Linux kernel (Raspberry Pi) vulnerabilities