Ubuntu Security Podcast

By Ubuntu Security TeamTechnology

Ubuntu Security Podcast episodes

December 20, 2024Episode 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
[email protected]
#ubuntu-security on the Libera.Chat IRC network
ubuntu-hardened mailing list
Security section on discourse.ubuntu.com
@[email protected], @ubuntu_sec on twitter
24 min
November 29, 2024Episode 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
[email protected]
#ubuntu-security on the Libera.Chat IRC network
ubuntu-hardened mailing list
Security section on discourse.ubuntu.com
@[email protected], @ubuntu_sec on twitter
20 min
November 14, 2024Episode 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
#ubuntu-security on the Libera.Chat IRC network
ubuntu-hardened mailing list
Security section on discourse.ubuntu.com
@[email protected], @ubuntu_sec on twitter
19 min
October 31, 2024Episode 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
[email protected]
#ubuntu-security on the Libera.Chat IRC network
ubuntu-hardened mailing list
Security section on discourse.ubuntu.com
@[email protected], @ubuntu_sec on twitter
37 min
October 18, 2024Episode 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
[email protected]
#ubuntu-security on the Libera.Chat IRC network
ubuntu-hardened mailing list
Security section on discourse.ubuntu.com
@[email protected], @ubuntu_sec on twitter
40 min
October 04, 2024Episode 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
[email protected]
#ubuntu-security on the Libera.Chat IRC network
ubuntu-hardened mailing list
Security section on discourse.ubuntu.com
@[email protected], @ubuntu_sec on twitter
32 min
September 20, 2024Episode 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)
CVE-2024-8385
CVE-2024-8384
CVE-2024-8381
CVE-2024-8389
CVE-2024-8387
CVE-2024-8386
CVE-2024-8383
CVE-2024-8382
[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)
CVE-2024-8384
CVE-2024-8381
CVE-2024-7525
CVE-2024-7522
CVE-2024-7519
CVE-2024-8382
CVE-2024-7529
CVE-2024-7527
CVE-2024-7526
CVE-2024-7521
[USN-6996-1] WebKitGTK vulnerabilities
6 CVEs addressed in Jammy (22.04 LTS), Noble (24.04 LTS)
CVE-2024-4558
CVE-2024-40789
CVE-2024-40782
CVE-2024-40780
CVE-2024-40779
CVE-2024-40776
[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)
CVE-2024-45492
CVE-2024-45491
CVE-2024-45490
[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)
CVE-2024-8088
CVE-2024-7592
CVE-2024-6923
CVE-2024-6232
CVE-2023-27043
[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)
CVE-2024-34509
CVE-2024-34508
CVE-2024-28130
CVE-2022-43272
CVE-2022-2121
CVE-2021-41690
CVE-2021-41689
CVE-2021-41688
CVE-2021-41687
[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)
CVE-2024-0727
CVE-2023-3446
CVE-2022-2068
CVE-2022-1292
CVE-2021-23840
CVE-2020-1968
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
[email protected]
#ubuntu-security on the Libera.Chat IRC network
ubuntu-hardened mailing list
Security section on discourse.ubuntu.com
@[email protected], @ubuntu_sec on twitter
17 min
September 06, 2024Episode 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)
CVE-2023-52470
CVE-2024-26687
CVE-2024-36901
CVE-2024-26654
CVE-2024-26679
CVE-2024-39484
CVE-2023-52806
CVE-2023-52760
CVE-2024-35955
CVE-2023-52629
CVE-2024-26600
CVE-2024-36940
CVE-2024-39292
CVE-2023-52644
CVE-2024-35835
CVE-2024-26903
CVE-2024-24860
CVE-2024-22099
[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)
CVE-2023-52760
CVE-2023-52629
CVE-2021-46926
CVE-2024-26921
CVE-2024-26929
CVE-2024-36901
CVE-2024-39484
CVE-2024-26830
CVE-2024-24860
[USN-6981-2] Drupal vulnerabilities
3 CVEs addressed in Trusty ESM (14.04 ESM)
CVE-2020-28949
CVE-2020-28948
CVE-2020-13671
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)
CVE-2019-12979
CVE-2019-12978
CVE-2019-12976
CVE-2019-12975
CVE-2019-12974
CVE-2019-11598
CVE-2019-11597
CVE-2019-11472
CVE-2019-11470
CVE-2019-10650
CVE-2019-10131
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
[email protected]
#ubuntu-security on the Libera.Chat IRC network
ubuntu-hardened mailing list
Security section on discourse.ubuntu.com
@[email protected], @ubuntu_sec on twitter
19 min
August 23, 2024Episode 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)
CVE-2022-48674
CVE-2024-39471
CVE-2024-39292
CVE-2024-36270
CVE-2024-36904
CVE-2024-38618
CVE-2024-36014
CVE-2024-36941
CVE-2024-38637
CVE-2024-38613
CVE-2024-36286
CVE-2024-36902
CVE-2024-38599
CVE-2024-39301
CVE-2024-39475
CVE-2024-36954
CVE-2024-33621
CVE-2024-38552
CVE-2024-36950
CVE-2024-38582
CVE-2024-36015
CVE-2023-52434
CVE-2024-38659
CVE-2024-36940
CVE-2024-38607
CVE-2024-39480
CVE-2024-38583
CVE-2023-52882
CVE-2024-39467
CVE-2024-39489
CVE-2024-38601
CVE-2024-27019
CVE-2023-52752
CVE-2024-36960
CVE-2024-38549
CVE-2024-38567
CVE-2024-38587
CVE-2024-38635
CVE-2024-38598
CVE-2024-38612
CVE-2024-38579
CVE-2024-27401
CVE-2024-36946
CVE-2024-36017
CVE-2022-48772
CVE-2024-36905
CVE-2024-35947
CVE-2024-38381
CVE-2024-38565
CVE-2024-38589
CVE-2024-36939
CVE-2024-38661
CVE-2024-39488
CVE-2024-36883
CVE-2024-38621
CVE-2024-37353
CVE-2024-38780
CVE-2024-36964
CVE-2024-38627
CVE-2024-36971
CVE-2024-38615
CVE-2024-38559
CVE-2024-31076
CVE-2024-26886
CVE-2024-39493
CVE-2024-27398
CVE-2024-36886
CVE-2024-38633
CVE-2024-36959
CVE-2024-38634
CVE-2024-38560
CVE-2024-38558
CVE-2023-52585
CVE-2024-37356
CVE-2024-35976
CVE-2024-36919
CVE-2024-36933
CVE-2024-38596
CVE-2024-39276
CVE-2024-27399
CVE-2024-38600
CVE-2024-38578
CVE-2024-36934
[USN-6961-1] BusyBox vulnerabilities
4 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS)
CVE-2023-42365
CVE-2023-42364
CVE-2023-42363
CVE-2022-48174
[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)
CVE-2024-26146
CVE-2024-26141
CVE-2024-25126
[USN-6966-1] Firefox vulnerabilities
13 CVEs addressed in Focal (20.04 LTS)
CVE-2024-7525
CVE-2024-7522
CVE-2024-7520
CVE-2024-7519
CVE-2024-7531
CVE-2024-7530
CVE-2024-7529
CVE-2024-7528
CVE-2024-7527
CVE-2024-7526
CVE-2024-7524
CVE-2024-7521
CVE-2024-7518
[USN-6966-2] Firefox regressions
13 CVEs addressed in Focal (20.04 LTS)
CVE-2024-7525
CVE-2024-7522
CVE-2024-7520
CVE-2024-7519
CVE-2024-7531
CVE-2024-7530
CVE-2024-7529
CVE-2024-7528
CVE-2024-7527
CVE-2024-7526
CVE-2024-7524
CVE-2024-7521
CVE-2024-7518
[USN-6951-3] Linux kernel (Azure) vulnerabilities
83 CVEs addressed in Bionic ESM (18.04 ESM)
CVE-2022-48674
CVE-2024-39471
CVE-2024-39292
CVE-2024-36270
CVE-2024-36904
CVE-2024-38618
CVE-2024-36014
CVE-2024-36941
CVE-2024-38637
CVE-2024-38613
CVE-2024-36286
CVE-2024-36902
CVE-2024-38599
CVE-2024-39301
CVE-2024-39475
CVE-2024-36954
CVE-2024-33621
CVE-2024-38552
CVE-2024-36950
CVE-2024-38582
CVE-2024-36015
CVE-2023-52434
CVE-2024-38659
CVE-2024-36940
CVE-2024-38607
CVE-2024-39480
CVE-2024-38583
CVE-2023-52882
CVE-2024-39467
CVE-2024-39489
CVE-2024-38601
CVE-2024-27019
CVE-2023-52752
CVE-2024-36960
CVE-2024-38549
CVE-2024-38567
CVE-2024-38587
CVE-2024-38635
CVE-2024-38598
CVE-2024-38612
CVE-2024-38579
CVE-2024-27401
CVE-2024-36946
CVE-2024-36017
CVE-2022-48772
CVE-2024-36905
CVE-2024-35947
CVE-2024-38381
CVE-2024-38565
CVE-2024-38589
CVE-2024-36939
CVE-2024-38661
CVE-2024-39488
CVE-2024-36883
CVE-2024-38621
CVE-2024-37353
CVE-2024-38780
CVE-2024-36964
CVE-2024-38627
CVE-2024-36971
CVE-2024-38615
CVE-2024-38559
CVE-2024-31076
CVE-2024-26886
CVE-2024-39493
CVE-2024-27398
CVE-2024-36886
CVE-2024-38633
CVE-2024-36959
CVE-2024-38634
CVE-2024-38560
CVE-2024-38558
CVE-2023-52585
CVE-2024-37356
CVE-2024-35976
CVE-2024-36919
CVE-2024-36933
CVE-2024-38596
CVE-2024-39276
CVE-2024-27399
CVE-2024-38600
CVE-2024-38578
CVE-2024-36934
[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)
CVE-2024-25939
CVE-2024-24980
CVE-2024-24853
CVE-2023-49141
CVE-2023-42667
[LSN-0106-1] Linux kernel vulnerability
3 CVEs addressed in
CVE-2024-36016
CVE-2024-26585
CVE-2023-52620
[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)
CVE-2024-34340
CVE-2024-34360
CVE-2024-31460
CVE-2024-31459
CVE-2024-31458
CVE-2024-31445
CVE-2024-31444
CVE-2024-31443
CVE-2024-29894
CVE-2024-25641
[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)
CVE-2021-4069
CVE-2021-4019
CVE-2021-3984
CVE-2021-3974
CVE-2021-3973
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
[email protected]
#ubuntu-security on the Libera.Chat IRC network
ubuntu-hardened mailing list
Security section on discourse.ubuntu.com
@[email protected], @ubuntu_sec on twitter
18 min
August 09, 2024Episode 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)
CVE-2024-35978
CVE-2024-35984
CVE-2024-35997
CVE-2024-26840
CVE-2024-27020
CVE-2023-52752
CVE-2021-47194
CVE-2021-46960
CVE-2024-26884
CVE-2024-36016
CVE-2023-52436
CVE-2024-36902
CVE-2024-26886
CVE-2023-52469
CVE-2024-26923
CVE-2023-52444
CVE-2023-52620
CVE-2021-46933
CVE-2024-35982
CVE-2023-52449
CVE-2024-26934
CVE-2024-26882
CVE-2024-26857
CVE-2021-46932
CVE-2024-26901
CVE-2024-25739
CVE-2024-24859
CVE-2024-24858
CVE-2024-24857
CVE-2023-46343
CVE-2022-48619
4.4 - generic, AWS, KVM, Low Latency, Virtual
[USN-6922-2] Linux kernel vulnerabilities
4 CVEs addressed in Jammy (22.04 LTS)
CVE-2024-25739
CVE-2024-24859
CVE-2024-24858
CVE-2024-24857
6.5 lowlatency
[USN-6926-2] Linux kernel vulnerabilities
30 CVEs addressed in Trusty ESM (14.04 ESM), Bionic ESM (18.04 ESM)
CVE-2023-52620
CVE-2023-52444
CVE-2024-26901
CVE-2023-52449
CVE-2024-27013
CVE-2024-26934
CVE-2024-35978
CVE-2024-27020
CVE-2023-52469
CVE-2024-35982
CVE-2024-35997
CVE-2023-52443
CVE-2024-36902
CVE-2024-26857
CVE-2024-36016
CVE-2023-52436
CVE-2023-52752
CVE-2024-26886
CVE-2024-35984
CVE-2023-52435
CVE-2024-26840
CVE-2024-26923
CVE-2024-26882
CVE-2024-26884
CVE-2024-25744
CVE-2024-25739
CVE-2024-24859
CVE-2024-24858
CVE-2024-24857
CVE-2023-46343
4.15 Azure
[USN-6895-4] Linux kernel vulnerabilities
100 CVEs addressed in Jammy (22.04 LTS)
CVE-2024-26802
CVE-2024-26664
CVE-2023-52880
CVE-2024-26695
CVE-2024-27416
CVE-2024-26714
CVE-2024-26603
CVE-2024-26920
CVE-2024-26736
CVE-2024-26593
CVE-2024-26922
CVE-2024-26600
CVE-2024-26702
CVE-2024-26782
CVE-2024-26685
CVE-2024-26691
CVE-2024-26734
CVE-2024-26822
CVE-2024-35833
CVE-2024-26792
CVE-2024-26674
CVE-2024-26889
CVE-2024-26712
CVE-2024-26917
CVE-2024-26919
CVE-2023-52637
CVE-2024-26700
CVE-2024-26661
CVE-2024-26926
CVE-2023-52631
CVE-2024-26679
CVE-2024-26798
CVE-2024-26667
CVE-2024-26689
CVE-2024-26681
CVE-2024-26910
CVE-2024-26828
CVE-2024-26790
CVE-2024-26606
CVE-2024-26825
CVE-2024-26677
CVE-2024-26722
CVE-2024-26923
CVE-2024-26803
CVE-2024-26898
CVE-2023-52642
CVE-2024-26660
CVE-2024-26716
CVE-2023-52645
CVE-2024-26602
CVE-2024-26711
CVE-2024-26826
CVE-2024-26601
CVE-2024-26890
CVE-2024-26698
CVE-2024-26693
CVE-2024-26665
CVE-2024-26676
CVE-2024-26824
CVE-2024-26838
CVE-2024-26720
CVE-2024-26666
CVE-2024-26718
CVE-2024-26723
CVE-2024-26675
CVE-2024-26680
CVE-2024-26642
CVE-2024-26710
CVE-2024-26696
CVE-2024-26748
CVE-2024-26717
CVE-2024-26735
CVE-2024-26916
CVE-2024-26697
CVE-2024-26829
CVE-2024-26715
CVE-2024-26694
CVE-2024-26830
CVE-2024-26726
CVE-2024-26719
CVE-2024-26820
CVE-2024-26707
CVE-2024-26818
CVE-2024-26733
CVE-2024-26688
CVE-2023-52643
CVE-2024-26703
CVE-2024-26831
CVE-2024-26789
CVE-2024-26662
CVE-2024-26663
CVE-2024-26708
CVE-2024-26659
CVE-2024-26684
CVE-2023-52638
CVE-2024-24861
CVE-2024-23307
CVE-2024-1151
CVE-2024-0841
CVE-2023-6270
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)
CVE-2024-5535
CVE-2024-4741
CVE-2024-4603
CVE-2024-2511
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)
CVE-2021-42388
CVE-2021-43305
CVE-2021-43304
CVE-2021-42387
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)
CVE-2024-29069
CVE-2024-29068
CVE-2024-1724
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)
CVE-2022-29885
CVE-2022-23181
CVE-2021-41079
CVE-2021-25122
CVE-2020-9484
[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)
CVE-2023-34151
CVE-2023-3195
CVE-2023-1289
CVE-2023-3428
CVE-2023-1906
CVE-2021-3610
CVE-2022-32547
CVE-2022-32546
CVE-2022-32545
CVE-2022-28463
CVE-2021-39212
CVE-2021-20313
CVE-2021-20312
CVE-2021-20246
CVE-2021-20309
CVE-2021-20244
CVE-2021-20243
CVE-2021-20241
CVE-2021-20224
CVE-2020-29599
[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)
CVE-2024-42005
CVE-2024-41991
CVE-2024-41990
CVE-2024-41989
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
[email protected]
#ubuntu-security on the Libera.Chat IRC network
ubuntu-hardened mailing list
Security section on discourse.ubuntu.com
@[email protected], @ubuntu_sec on twitter
30 min

About Ubuntu Security Podcast

From the publisher's feed

A fortnightly podcast talking about the latest developments and updates from the Ubuntu Security team, including a summary of recent security vulnerabilities and fixes as well as a discussion on some…

Share Ubuntu Security Podcast

Sign up to save your podcasts

Ubuntu Security Podcast

Ubuntu Security Podcast episodes

About Ubuntu Security Podcast