Episode 226

Show Notes

Overview

John and Georgia are at the Linux Security Summit presenting on some long awaited developments in AppArmor and we give you all the details in a sneak peek preview as well as some of the other talks to look out for, plus we cover security updates for NSS, Squid, Apache, libvirt and more and we put out a call for testing of a pending AppArmor security fix too.

This week in Ubuntu Security Updates

86 unique CVEs addressed

[USN-6727-1, USN-6727-2] NSS vulnerabilities + regression (01:02)

3 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Mantic (23.10)
All various different timing side channels - two were effectively the same since the original fix was incomplete - mishandling of padding in PKCS#1 (RSA) certificate checks - possible to infer the length of the encrypted message and other properties to eventually infer secret key by sending a large number of attacker-chosen ciphertexts, the other when using various NIST curves (elliptic curve cryptography)
Original fix caused some issues with loading NSS security modules so published a second update to fix that on focal+jammy

[USN-6728-1, USN-6728-2] Squid vulnerabilities + regression (02:05)

5 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Mantic (23.10)
All found by the same researcher (Joshua Rogers) who performed a security audit of Squid back in 2021 - https://megamansec.github.io/Squid-Security-Audit/ - first mentioned by us in [USN-6500-1] Squid vulnerabilities in Episode 214 back in December 2023
Then we mentioned how squid was under-resourced and so hadn’t be able to fix all the identified issues - over time upstream has published fixes for more issues and we are now incorporating those into squid in Ubuntu
All of these were various DoS issues where could either cause squid to crash or stop responding
One of these fixes was problematic and caused squid to crash itself so was reverted

[USN-6729-1] Apache HTTP Server vulnerabilities (03:01)

3 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Mantic (23.10)
2 different issues that could result in HTTP request splitting attacks - similar to HTTP request smuggling which is a more specific version of this attack, relies on different parsing/interpretation of HTTP request messages by an intermediate (load balancer/proxy/WAF etc.) to split a single HTTP request into multiple HTTP requests at the backend - allowing to bypass restrictions along the way - usually involves the use of injected CR/LF/TAB/SPC etc in headers
Plus memory-based DoS in handling of HTTP/2 - client could just keep sending more headers, buffered by the server so it can generate an informative response, until it exhausts memory
- limit to just 100 headers before bailing with such an error

[USN-6730-1] Apache Maven Shared Utils vulnerability

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)
- CVE-2022-29599

[USN-6731-1] YARD vulnerabilities

3 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Mantic (23.10)

[USN-6732-1] WebKitGTK vulnerabilities

8 CVEs addressed in Jammy (22.04 LTS), Mantic (23.10)

[USN-6733-1] GnuTLS vulnerabilities (04:57)

2 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Mantic (23.10)
- CVE-2024-28835
- CVE-2024-28834
Timing side-channel in ECDSA
Crash when verifying crafted PEM bundles -> DoS

[USN-6734-1] libvirt vulnerabilities (05:13)

3 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Mantic (23.10)
off-by-one in handling of udev interface names - unpriv client could then abuse this to send crafted udev data to the libvirt daemon, triggering a crash -> DoS
NULL ptr deref in same code - race condition, need to detach a host interface whilst calling into the function
Crash in RPC handling - pass a negative length value, would then try and allocate a negative number of array indices - uses underlying g_new0() from glib which expects an unsigned value -> tries to allocate an extremely large amount of memory -> crash

[USN-6735-1] Node.js vulnerabilities

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

[USN-6736-1] klibc vulnerabilities (06:33)

4 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)
All old memory corruption issues in zlib - vendored within klibc

Goings on in Ubuntu Security Community

Linux Security Summit NA 2024 (07:22)

https://events.linuxfoundation.org/linux-security-summit-north-america/
Unprivileged Access Control in AppArmor - John Johansen & Georgia Garcia, Canonical
- https://static.sched.com/hosted_files/lssna24/97/AppArmor%20-%20Unprivileged%20Application%20Policy.pdf
- Friday 19th @ 9.15am PDT - live stream at https://www.youtube.com/watch?v=S-RQZGRoQFY
- AppArmor - MAC - sysadmin defines policy
- Allowing applications to define and load their own policy
  - APIs in libapparmor to allow this to be done from static policy OR to build up policy over time
  - policy is compiled in userspace and loaded into the kernel as usual
  - To then stop a compromised application from unloading its policy, can mark it immutable so it can’t be further modified / removed
  - Any further restrictions though can then be stacked against the immutable policy to say allow it to be confined futher
  - On kernel side
    - sysctl to allow/deny applications to load their own policy
    - checks on the amount of memory able to be used to avoid apps DoSing system
    - verification of compiled policy by kernel state machine
    - policy only applies to the task and its children
  - Various complexities in handling credentials/labels across tasks (ie. processes) and how these interact with the userspace processes/threads etc
  - Also still have to resolve whether to use prctl vs syscall as the interface since we can’t use the LSM syscalls
    - May result in an AppArmor specific syscall
    - But for now just using a prctl
  - Application profiles then stack against any relevant system policy
  - ie. if there is system policy, and policy loaded by the application itself is bounded by the system policy
- Demo of implementing pledge() and unveil() from OpenBSD
  - pledge is similar to seccomp() on linux - allows an application to restrict what it can do by declaring what subsystems it should be allowed access to “promises”
    - stdio, inet, bpf, unix, audio, video and many others
    - map these to equivalent AppArmor permissions (although this is not a perfect mapping but WIP)
    - also since this is at the LSM layer, we are not necessarily blocking syscalls as is done by pledge (since it is more akin to seccomp)
    - but can use seccomp to plug any gaps
    - to fully emulate this also need to emulate the return value - since on OpenBSD if the application violates the promise, deliver a SIGABRT - whereas LSMs return EACCES
    - can do this via a new profile flag called kill along with the associated signal to deliver
    - further complications to this since not always SIGABRT, sometimes is an errno (ENOSYS/EACCES) too
    - extend apparmor policy to allow to specify priorities of what action should be taken in various cases
    - can use the aforementioned immutable profile flag and stacking to then implement the promise reduction feature of pledge()
  - unveil is used to remove visibility of parts of the file-system
    - maps quite cleanly to apparmor file rules
- Full video of the session should be available soon
Lots of other interesting talks:
- Stacked LSMs and User Space - Casey Schaufler, The Smack Project
  - LSM syscalls and associated liblsm to provide an easier API plus emulation for older systems
  - https://static.sched.com/hosted_files/lssna24/1a/2024-04-LSSNA-liblsm.pdf
- Mitigating Integer Overflow in C - Kees Cook, Google
  - LKSPP - latest efforts to mitigate integer overflows within the kernel through the use of compiler sanitizers
  - https://static.sched.com/hosted_files/lssna24/fb/Mitigating%20Integer%20Overflow%20in%20C.pdf
- Enhancing Kernel Bug Discovery with Large Language Models - Zahra Tarkhani, Microsoft
- SandBox Mode (SBM) - New Execution Mode Between Kernel and User Space - Petr Tesarik, Self-employed