Sveriges mest populära poddar
Start / Ubuntu Security Podcast / Episode 234

Ubuntu Security Podcast

Episode 234

29 min • 9 augusti 2024

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)
  • 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)

[USN-6922-2] Linux kernel vulnerabilities

[USN-6926-2] Linux kernel vulnerabilities

[USN-6895-4] Linux kernel vulnerabilities

[USN-6937-1] OpenSSL vulnerabilities (03:04)

  • 4 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS)
  • Four low priority issues
    • Possible UAF in SSL_free_buffers API - requires an application to directly call this function - across the entire Ubuntu package ecosystem there doesn’t appear to be any packages that do this so highly unlikely to be an issue in practice
    • Similarly, in another rarely used function SSL_select_next_proto - if called with an empty buffer list would read other private memory - ie OOB read - and potentially then either crash or return private data
      • but again this is not expected to occur in practice
    • CPU-based DoS when validating long / crafted DSA keys
      • simply check if using to large a modulus and error in that case
    • If had set the SSL_OP_NO_TICKET option would possibly get into a state where the session cache would not be flushed and so would grow unbounded - memory based DoS

[USN-6913-2] phpCAS vulnerability (04:51)

[USN-6936-1] Apache Commons Collections vulnerability (05:03)

  • 1 CVEs addressed in Trusty ESM (14.04 ESM)
  • 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)
  • Mishandles multiline filename header and so a crafted value could bypass the MIME type extension blocking mechanism - allowing executables etc to be delivered to users

[USN-6933-1] ClickHouse vulnerabilities (06:00)

  • 5 CVEs addressed in Focal (20.04 LTS)
  • real-time analytics DBMS
  • Mostly written in C++ so not surprisingly has various memory safety issues
    • All in the the LZ4 compression codec - uses an attacker controlled 16-bit unsiged value as the offset to read from the compressed data - then this value is also used when copying the data but there is no check on the upper bound so could index outside of the data
    • Also a heap buffer overflow during this same data copy since doesn’t verify the size of the destination either

[USN-6940-1] snapd vulnerabilities (06:55)

  • 3 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS)
  • 2 quite similar issues discovered by one of the engineers on the snapd team - Zeyad Gouda
    • snaps are squashfs images - in general they are just mounted but certain files from the squashfs get extracted by snapd and placed on the regular file-system (ie. desktop files and icons for launchers etc) - as such, snapd would read the contents of these files and then write them out - if the file was actually a named pipe, snapd would block forever - DoS
    • similarly, if the file was a symlink that pointed to an existing file on the file-system, when opening that file (which is a symlink) snapd would read the contents of the other file and write it out - recall these are desktop files etc so they get written to /usr/share/applications which is world-readable - so if the symlink pointed to /etc/shadow then you would get a copy of this written out as world-readable - so an unprivileged user on the system could then possibly escalate their privileges
  • 3rd issue was AppArmor sandbox
    • home interface allows snaps to read/write to your home directory
    • On Ubuntu, if the bin directory exists, it gets automatically added to your PATH
    • AppArmor policy for snapd took this into account and would stop snaps from writing files into this directory (and hence say creating a shell script that you would then execute later, outside of the snap sandbox)
    • BUT it did not prevent a snap from creating this directory if it didn’t already exist

[USN-6941-1] Python vulnerability (11:15)

[USN-6909-2] Bind vulnerabilities (11:30)

  • 2 CVEs addressed in Bionic ESM (18.04 ESM)
  • 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)

[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)
  • 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)
  • 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)

[USN-6946-1] Django vulnerabilities (15:04)

  • 4 CVEs addressed in Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS)
  • SQL injection via crafted JSON in methods on the QuerySet class, and various DoS - one via very large inputs of Unicode characters in certain input fields, another through floatformat template filter - would use a large amount of memory if given a number in scientific notation with a large exponent

[USN-6945-1] wpa_supplicant and hostapd vulnerability (15:42)

  • 1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS)
  • 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

Kategorier
PoddarTeknologi
Förekommer på
Teknik
00:00 -00:00
Hur lyssnar jag på podcast?

En liten tjänst av I'm With Friends. Finns även på engelska.