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

This week in Ubuntu Security Updates185 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 - anattacker instead could POST to this with arbitrary JavaScript which would thenget 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 issues + Possible UAF in SSL_free_buffers API - requires an application to directlycall this function - across the entire Ubuntu package ecosystem theredoesn’t appear to be any packages that do this so highly unlikely to be anissue 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 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 wherethe session cache would not be flushed and so would grow unbounded - memorybased 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 bedelivered 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-bitunsiged value as the offset to read from the compressed data - then thisvalue is also used when copying the data but there is no check on the upperbound 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 Gouda + snaps are squashfs images - in general they are just mounted but certainfiles from the squashfs get extracted by snapd and placed on the regularfile-system (ie. desktop files and icons for launchers etc) - as such, snapdwould read the contents of these files and then write them out - if the filewas 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 readthe contents of the other file and write it out - recall these are desktopfiles etc so they get written to /usr/share/applications which isworld-readable - so if the symlink pointed to /etc/shadow then you would geta copy of this written out as world-readable - so an unprivileged user onthe 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 fromwriting files into this directory (and hence say creating a shell scriptthat 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 DoS + Didn’t restrict the number of resource recordsfor a given hostname - if an attacker could arrange so a large number of RRsthen could degrade the performace of bind due to it having to performexpensive 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 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 logging + would concatenate a list of parameters as string into a fixed size buffer onthe stack but would pass the entire buffer size as the length argumentrather 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 ofa 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 ofmemory 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 CommunityDiscussion 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 netdevgroup + 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 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 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 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 inUbuntu since it was only introduced recently (so not all Ubuntu releasesinclude it) but regardless, we want to support setups where these modules maylive 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 touse 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 searchingfor any users of these config parameters but couldn’t find anything in thearchive - 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 usingthe 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 netdevgroup - Considered dropping support entirely for this feature which allows thenetdev group access since in general this should be done withNetworkManager 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 creatingtheir 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 incombination 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 theproc filesystem - which points to the actual root directory of thatprocess - and since the FUSE fs lies about the UID it looks like rootowned + 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 simplycall realpath() directly on the provided path name and if it doesn’t startwith /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 youcan write to /opt then you can write to somewhere in /usr/lib - so is easyto 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 towork 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 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 fromFoundations, but most importantly to Rory from Snyk for both reporting thevuln but also in their help evaluating the various proposed solutions

Get in contact* security@ubuntu.com * #ubuntu-security on the Libera.Chat IRC network * ubuntu-hardened mailing list * Security section on discourse.ubuntu.com * @ubuntusecurity@fosstodon.org, @ubuntu_sec on twitter