Overview
After a well-deserved break, we’re is back looking at the recent Ubuntu 23.10
release and the significant security technologies it introduces along with a
call for testing of unprivileged user namespace restrictions, plus the details
of security updates for curl, Samba, iperf3, CUE and more.
This week in Ubuntu Security Updates
26 unique CVEs addressed
- 1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM)
- for Ubuntu Pro users
- under rare circumstances, possible that an application using libcurl would
potentially load cookies from a crafted file on disk - allowing a local
attacker to inject arbitrary cookies into a connection - although requires the
application to use the
curl_easy_duphandle()
function
- 2 CVEs addressed in Mantic (23.10)
- cookie issue above, plus a possible heap buffer overflow when using a SOCKS5
proxy, if the specified hostname was longer than 255 bytes
[USN-6425-3] Samba vulnerabilities (02:38)
- 4 CVEs addressed in Mantic (23.10)
- Various logic issues which could result in a range of effects, from attackers
being able to truncate read-only files, or cause Samba to stop responding and
hence DoS through to the ability to obtain all domain secrets
[USN-6425-2] Samba regression (03:06)
- 4 CVEs addressed in Focal (20.04 LTS)
- Previous security update for focal was miscompiled and resulted in an issue
when handling the
%U
directive in smb.conf - if specified a path to be shared
like /home/%U/FILES
the %U
would seemingly be ignored and not replaced with
the username as expected - and hence the share would fail - this same issue
actually occurred previously in January this year - have now added a
regression test specifically to try and ensure we do not introduce this same
issue in the future again
[USN-6430-1] FFmpeg vulnerabilities (04:25)
- 6 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS)
- Most just memory leaks in handling of various crafted files -> DoS
- One heap buffer overflow - possible RCE but likely just DoS
- One integer overflow in FPS calculation
- 1 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Lunar (23.04)
- Integer overflow -> heap buffer overflow -> RCE / crash - essentially, when
parsing a frame, would allocate memory for the frame, plus 1 extra byte for a
trailing NUL - if frame length was
MAX_UINT
adding 1 then wraps the integer
around back to zero - and so no memory gets allocated - and when copying into
the subsequent memory get a buffer overflow
- When preparing this update, Jorge discovered he could cause the iperf3 server
to hang indefinitely on crafted input as well - reported this upstream and
included that fix here as well
[USN-6432-1] Quagga vulnerabilities (06:26)
- 2 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS)
- 2 different DoS vulns - both OOB reads on crafted input -> crash
[USN-6436-1] FRR vulnerabilities (06:38)
- 3 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Lunar (23.04)
- FRR is the new Quagga
[USN-6394-2] Python vulnerability (06:52)
- 1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM)
- Possible UAF in heapq module (aka priority queue implementation)
[USN-6423-2] CUE vulnerability (07:04)
- 1 CVEs addressed in Mantic (23.10)
- OOB write discovered by Kevin Backhouse from Github - allows for a one-click
RCE on GNOME desktop due to the use of libcue by tracker - when a crafted CUE
file is downloaded, will get automatically indexed by tracker and hence parsed
by libcue triggering this bug -> RCE
- Interestingly, tracker employed a seccomp sandbox which should have limited
the impact for this kind of issue (ie restricting what the exploit could do)
but Kevin found a way to bypass this since the seccomp filter was only applied
to the thread used to parse the file - not the main thread - so Kevin could
simply delegate the code execution to the main thread to bypass this
- Upstream GNOME developers were already aware of this as a possible weakness in
the sandbox, and so worked to ensure this is then applied to all threads
within tracker, not just the one spawned to parse the particular file
[USN-6433-1] Ghostscript vulnerability (10:18)
- 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Lunar (23.04)
- Possible sandbox escape via a crafted PS document since it could modify the
specified IJS server parameter binary to execute some other binary instead
[USN-6396-3] Linux kernel (Azure) vulnerabilities (10:55)
- 6 CVEs addressed in Trusty ESM (14.04 ESM)
- Various issues covered previously - 2 different UAFs - network packet
classifier and bluetooth subsystems, recent speculative execution vulns in AMD
and Intel processors and more
[USN-6434-1] PMIx vulnerability (11:24)
- 1 CVEs addressed in Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS)
- OpenPMIx implementiation - Process Management Interface Exascale Standard -
API used in HPC environments
- Possible privilege escalation via race condition - library sets ownership of
various files but would follow symlinks when doing this - so if a user could
race it to swap a symlink out then could get it to set the ownership of a root
owned file to themselves and gain the ability to read it etc
Goings on in Ubuntu Security Community
Ubuntu 23.10 (Mantic Minotaur) Released (12:41)
- https://ubuntu.com/blog/canonical-releases-ubuntu-23-10-mantic-minotaur
- Culmination of the last 6 months of work - this release in particular has a
strong focus on raising the bar for security, and setting the stage for the
next LTS (24.04)
- Two preview features - TPM-backed FDE on Ubuntu Desktop, and unprivileged user
namespace restrictions via AppArmor
- Covered both of these in previous episodes
Call for testing of Unprivileged User Namespace Restrictions on Mantic
-
The hope is to get this enabled by default in 24.04 LTS - but we need as much
testing as we can get to find anything else which is not working as expected
beforehand - easy to do via a new sysctl
- Can either do it immediately:
sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=1
- Or can set this to be applied at boot via a new file in
/etc/sysctl.d
, e.g.:
create a file /etc/sysctl.d/60-apparmor.conf
with the following contents:
kernel.apparmor_restrict_unprivileged_userns = 1
-
Then if you do find something which is not working as expected, you can create
a simple AppArmor profile which will allow it to use unprivileged user
namespaces without any additional restrictions, e.g:
abi <abi/4.0>,
include <tunables/global>
/opt/google/chrome/chrome flags=(unconfined) {
userns,
# Site-specific additions and overrides. See local/README for details.
include if exists <local/opt.google.chrome.chrome>
}
- From a defensive security point of view, also is useful to enable an
additional sysctl to ensure that anything which is unconfined can’t just abuse
these profiles by
aa-exec
‘ing themselves via that profile - so then also need
to enable the kernel.apparmor_restrict_unprivileged_unconfined = 1
sysctl too
- One application that we are aware of that is impacted is LXD - which, to avoid
issues, is currently disabling this automatically at startup - so for now you
have to keep manually re-enabling this restriction until the LXD devs land a
change to stop this https://github.com/canonical/lxd-pkg-snap/pull/187
- Also all applications based on chromium (ie all electron apps) may likely have
issues since the chromium sandbox uses unprivileged user namespaces by
default - we have already created profiles for the various ones in the Ubuntu
archive that we are aware of, and for some third party ones too (Brave,
Vivaldi etc) but we expect there will be others - in that case, let us know
- File a bug against apparmor:
ubuntu-bug apparmor
or visit
https://bugs.launchpad.net/ubuntu/+source/apparmor/+filebug
Get in contact