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

Ubuntu Security Podcast

Episode 218

18 min • 9 februari 2024

Overview

AppArmor unprivileged user namespace restrictions are back on the agenda this week as we survey the latest improvements to this hardening feature in the upcoming Ubuntu 24.04 LTS, plus we discuss SMTP smuggling in Postfix, runC container escapes and Qualys’ recent disclosure of a privilege escalation exploit for GNU libc and more.

This week in Ubuntu Security Updates

39 unique CVEs addressed

[USN-6591-2] Postfix update (00:48)

  • 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), Mantic (23.10)
  • On 18th December (during the holiday break), SEC Consult published a report about a new technique for email spoofing, which they dubbed SMTP Smuggling
    • Similar to HTTP Request Smuggling - relies on exploiting differences in how SMTP protocol is interpreted by outbound (originating) vs inbound (receiving) SMTP servers. In particular the end-of-data sequence <CR><LF>.<CR><LF> gets interpreted loosely so that it is possible to include extra SMTP commands within the message data which would then go on to be interpreted as an additional SMTP commands to be executed by the receiving server and to cause it to receive two emails when only one was sent in the first place, and where the usual SPF checks get bypassed for this second email - so can bypass SPF/DMARC policies to spoof emails from various domains
  • Affected a number of projects including postfix - Upstream postfix released version 3.8.4 with an initial fix on 22nd December
  • We then released USN-6591-1 with that fix
  • Then on 21st January released a more robust fix with an additional config option to increase interoperability whilst still preventing SMTP smuggling
  • This second update includes the reworked fix

[USN-6619-1] runC vulnerability (03:22)

  • 1 CVEs addressed in Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Mantic (23.10)
  • “Internal file descriptor leak” - using a specially crafted container image, allows an attacker to cause a newly spawned container to have a working directory within the host filesystem namespace which in turn can allow the attacker to escape the container - various ways this can be attacked, full details on the upstream advisory https://github.com/opencontainers/runc/security/advisories/GHSA-xr7r-f8xq-vfvv

[USN-6620-1] GNU C Library vulnerabilities (04:17)

  • 3 CVEs addressed in Mantic (23.10)
  • Latest round of vulnerabilities from Qualys
  • Affect the syslog() system call
  • Heap buffer overflow, off-by-one buffer overflow and integer overflow
  • Of these the heap buffer overflow is the most severe - Qualys were able to demonstrate they could exploit and up-to-date default install of Fedora 38 to escalate privileges from a local unprivileged user to root.
    • uses the value of argv[0] in a call to snprintf() into a fixed size buffer allocated on the stack - snprintf() won’t overflow this but will return a value larger than the fixed size buffer - as a result a heap buffer to then contain this string would only get allocated with a size of 1 byte but then the full expected data would get copied into it - and since the attacker controls this value they can write arbitrary data to the heap by just using a crafted program name (which is easy to do via the the exec command built in to bash etc)
  • Various setuid binaries like /usr/bin/su call syslog() internally and so can be abused in this way

[USN-6587-4] X.Org X Server regression (07:14)

[USN-6621-1] ImageMagick vulnerability (07:28)

  • 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)
  • ImageMagick is in universe, so these updates are available via Ubuntu Pro
  • Heap UAF in BMP decoder - likely DoS but possible code-execution via a crafted BMP file

[USN-6622-1] OpenSSL vulnerabilities (08:07)

  • 4 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Mantic (23.10)
  • Two CPU-based DoS issues where OpenSSL would spend an excessive amount of time trying to check an invalid RSA or X9.42 DH keys
  • NULL ptr deref when parsing a malicious PKCS12 file
  • Issue specific to PowerPC (ppc64el arch in Ubuntu) - possible to corrupt application state since the POLY1305 MAC implementation (hand-coded assembly) saves the contents of the vector registers in a different order than when they get restored - so some registers will be corrupted when returning to the caller
    • Only relevant on newer PowerPC processors which support the PowerISA 2.07 instructions

[USN-6592-2] libssh vulnerabilities (09:27)

  • 2 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM)
  • Recent libssh update now also available for Ubuntu Pro users on older releases

[USN-6623-1] Django vulnerability (09:34)

  • 1 CVEs addressed in Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Mantic (23.10)
  • ReDoS when using the intcomma template

[USN-6609-3] Linux kernel (Oracle) vulnerabilities (09:45)

[USN-6610-2] Firefox regressions (09:57)

Goings on in Ubuntu Security Community

Updates for unprivileged user namespace restrictions in Ubuntu 24.04 LTS (10:32)

  • Previously mentioned this work a few times on the podcast (Call for testing of Unprivileged User Namespace Restrictions on Mantic in Episode 211 and Unprivileged user namespace restrictions via AppArmor in Ubuntu in Episode 205)
  • Both those times was about user namespace restrictions in Ubuntu 23.10 (the current interim release)
  • For those not familiar - user namespaces provide a mechanism for operating as a different UID on a Linux system - in particular, can operate as uid 0 within a namespace which is then constrained by the original parent namespace - ie. as a normal unprivileged user, I could create a new user namespace and map my UID to 0 within that namespace, which can then allow me to have say CAP_NET_ADMIN within that namespace and so create firewall rules etc that only affect applications within that namespace and not the host system
    • Can also be used for isolation etc
    • However, since within the namespace my unprivieleged user now has extra privileges, exposes additional kernel attack surface - various bugs have been found in differetn kernel subsystems that allow an unprivileged user to exploit the kernel as a result
  • Want a way to provide fine grained controls over unprivileged user namespaces
  • Previously, used AppArmor to deny the ability to create a new user namespace unless an application was explicitly tagged via an associated AppArmor profile
  • John and Georgia from the AppArmor team have made a number of enhancements, in particular adding a new default functionality where you can define in AppArmor policy a different AppArmor profile which an application should transition into when it creates a user namespace
  • In particular, we can now do this even for the “unconfined” profile - and then ship a default “unconfined_userns” profile which allows an application to create a userns but to not gain any additional capabilities within that by default
  • Various sandboxing frameworks behave much more sensibly with this - so instead of just failing when they try and create the userns, they instead are able to create one but then if they try and gain additional capabilities (like CAP_NET_ADMIN etc as mentioned before) this is then denied
  • This also matches the semantics which we want to achieve since it is not really the user namespace itself that is the original issue, it is the ability to gain additional capabilities within that which the unprivileged user did not have originally
  • In addition, Georgia has been busy testing various applications within the archive and across the Linux ecosystem to ensure we ship any required profiles for them out-of-the-box so as many pieces of software continue to work as expected with these restrictions in place
  • AppArmor in noble is already enabling this restriction and these updates are now in the apparmor package in noble-proposed pocket
    • Expect to be available in noble within the next few days once automated testing completes
  • Requires some additional kernel support - Kernel Team has merged this into their current linux-unstable kernel (available via the Kernel Team’s unstable PPA) which will land eventually land in 24.04 proper
  • On track to have this additional security hardening feature enabled by default for 24.04 LTS at release so we can close off one of the more prevalent sources of kernel privilege escalation bugs in the past few years

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.