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 whichshould 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 thegenerated 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 issuesPossible UAF in SSL_free_buffers API - requires an application to directlycall 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 calledwith 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 practiceCPU-based DoS when validating long / crafted DSA keyssimply check if using to large a modulus and error in that caseIf had set the SSL_OP_NO_TICKET option would possibly get into a state wherethe 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 attackercontrolled 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 theMIME 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 DBMSMostly written in C++ so not surprisingly has various memory safety issuesAll in the the LZ4 compression codec - uses an attacker controlled 16-bitunsiged 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 verifythe 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 Goudasnaps are squashfs images - in general they are just mounted but certainfiles 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 thefile-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 sandboxhome interface allows snaps to read/write to your home directoryOn Ubuntu, if the bin directory exists, it gets automatically added to your PATHAppArmor policy for snapd took this into account and would stop snaps fromwriting 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’talready 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 DoSDidn’t restrict the number of resource recordsfor 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 nameRemoved support DNSSEC SIG(0) transaction signatures since they could beabused 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 liststo tag mails which come from these domains as possible spam
stack buffer overflow through the use of strncat() during loggingwould concatenate a list of parameters as string into a fixed size buffer onthe 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 eithercrash 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 - wouldpotentially 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.htmloption 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 variousDoS - 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 getwpa_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 largerdisclosure of various security issues they had found
Issue specific to Debian and Ubuntu - includes patch to the dbus policy forwpa_supplicant to allow various methods to be called by users in the netdev
group
historical hangover before we had network manager etc to do thisnowadays, Network Manager allows the user who is logged in to control access to wireless networks etchistorically though, Debian had the netdev group instead - so you would addyour 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 interfaceDBus API includes a method called CreateInterfacetakes an argument called ConfigFile which specifies the path to a configuration file using the format of wpa_supplicant.confconfig file includes a parameter for opensc_engine_path or similarly PKCS11 engine and module pathsthese are shared object which then get dynamically loaded into memory by wpa_supplicanthence could overwrite existing functions and therefore get code execution asroot - since wpa_supplicant runs as root
upstream actually includes a patch to hard-code these values at compile-timeand 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: #2067613Is not an issue for upstream since the upstream policy only allows root touse this dbus method so there is no privilege escalation
Could allow-list various paths but was not clear which ones to useLukas from Foundations team (and maintainer of Netplan) tried searchingfor 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 breaktheir setups
Or could tighten up the DBus policy for the netdev group to NOT includeaccess 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 usedthe wpa_supplicant DBus interface - none appear to make use of the netdev
group
Considered dropping support entirely for this feature which allows thenetdev 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 clearwhat the possible regression potential would be
Or we could patch wpa_supplicant to check that the specified module wasowned 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 theproof-of-concept and was able to block it
However, Rory came back with some excellent research showing it could bebypassed 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 usercreate a new user and mount namespace through unsharewithin that (since you are “root”) mount an overlay filesystem using the FUSE fsSpecify the path to this file using the special root link inside theproc 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 suggestedmanually 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 TOCTOUrace
Finally Marc proposed to simply allow-list anything under /usr/lib - sinceanything 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 regressionYes if using a non-standard location like /opt would now fail BUT if youcan 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 realone 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 thechance of regressions
None reported so far anyway ;)Demonstrates the careful balance between security and possible regressionsAlso the team effort of both the security team and other Ubuntu teamsThanks to Marc, Luci, Mark E, and Sudhakar on our side, and Lukas fromFoundations, 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 networkubuntu-hardened mailing listSecurity section on discourse.ubuntu.com@[email protected], @ubuntu_sec on twitter