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)
[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)
- 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
[USN-6724-2] Linux kernel vulnerabilities
- 12 CVEs addressed in Jammy (22.04 LTS), Mantic (23.10)
[USN-6725-2] Linux kernel (AWS) vulnerabilities
- 46 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS)
[USN-6726-2] Linux kernel (IoT) vulnerabilities
- 23 CVEs addressed in Focal (20.04 LTS)
[USN-6726-3] Linux kernel (Xilinx ZynqMP) vulnerabilities
- 23 CVEs addressed in Focal (20.04 LTS)
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:
Upcoming AppArmor Security update for CVE-2016-1585
Get in contact