Ubuntu Security Podcast

Episode 234


Episode Artwork
1.0x
0% played 00:00 00:00
Aug 09 2024 29 mins   56 1 0
Other Episodes

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


Download episode Share
Copy URL



Listen on Podcast Addict
Subscribe on Podcast Addict