Episode 214

Posted on Friday, Dec 1, 2023
This week we take a deep dive into the Reptar vuln in Intel processors plus we look into some relic vulnerabilities in Squid and OpenZFS and finally we detail new hardening measures in tracker-miners to keep your desktop safer.

Show Notes

Overview

This week we take a deep dive into the Reptar vuln in Intel processors plus we look into some relic vulnerabilities in Squid and OpenZFS and finally we detail new hardening measures in tracker-miners to keep your desktop safer.

This week in Ubuntu Security Updates

115 unique CVEs addressed

[USN-6481-1] FRR vulnerabilities (01:21)

  • 2 CVEs addressed in Jammy (22.04 LTS), Lunar (23.04), Mantic (23.10)
  • Two different crashes reported by network pentester from Amazon - appears to be fuzzing frr -> DoS

[USN-6482-1] Quagga vulnerabilities (01:42)

[USN-6483-1] HTML Tidy vulnerability (02:05)

  • 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Lunar (23.04), Mantic (23.10)
  • Implemented parser as a recursive algorithm - so on deeply nested documents, could end up exhausting the stack and causing memory corruption etc.
  • Fixed by reimplementing the parser as an iterative loop with a heap-based stack

[USN-6480-1] .NET vulnerabilities (02:42)

[USN-6484-1] OpenVPN vulnerabilities (02:51)

  • 2 CVEs addressed in Lunar (23.04), Mantic (23.10)
  • Two issues which only affected more recent versions of OpenVPN (>= =2.6.0) - one UAF and the other a possible divide by zero -> DoS

[USN-6485-1] Intel Microcode vulnerability (03:13)

  • 1 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Lunar (23.04), Mantic (23.10)
  • Tavis Ormandy’s latest processor bug - “Reptar” - found again using the same technique as he used to find Zenbleed (AMD) but this time in Intel processors - essentially can be thought of as akin to fuzzing but instead of generating random input to find unexpected behaviour, generate some random input in the form of a set of processor instructions, and then also generate an equivalent version of this by adding random alignment, serialization and memory fence instructions etc. These extra instructions shouldn’t change the behaviour of the program being executed, so if a difference is observed then can likely assume the hardware has behaved incorrectly - perhaps some underlying microarchitectural behaviour has been triggered - but either way could indicate the presence of a hardware bug which could in turn be exploited as a vulnerability to cause undesired affects
  • In this case, found a sequence of instructions that in general should be ignored but which could instead cause the processor to hit a machine check exception and halt - even from an unprivileged guest VM - this is the kind of things that cloud providers worry about
  • Theorised that since they can cause MCEs by corrupting various internal state of the processor, they could potentially get privilege escalation if they could control that corruption with enough precision but since it is not really possible to debug the microarchitectural state of the processor it is not easy to develop such a PoC
  • Reported the issue to Intel who released a microcode update to fix this, and Tavis released a PoC tool to test for and reproduce the basic issue

[USN-6486-1] iniParser vulnerability (06:25)

  • 1 CVEs addressed in Jammy (22.04 LTS), Lunar (23.04), Mantic (23.10)
  • Possible NULL ptr deref on crafted input

[USN-6487-1] Avahi vulnerabilities (06:36)

  • 5 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), Lunar (23.04), Mantic (23.10)
  • Various assertions were able to be triggered through crafted input - so a local attacker on your network could cause your local avahi daemon to crash

[USN-6489-1] Tang vulnerability (07:09)

  • 1 CVEs addressed in Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Lunar (23.04)
  • Race condition when generating keys - would write to a file and then set permissions so only root could read them - small time window then where another process could possibly read the key before the more restrictive permissions are set - fixed by setting a restrictive umask before creating the file such that it gets created with the restrictive permissions from the start

[USN-6488-1] strongSwan vulnerability (07:59)

  • 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Lunar (23.04), Mantic (23.10)

[USN-6490-1] WebKitGTK vulnerabilities

[USN-6491-1] Node.js vulnerabilities

[USN-6493-1, USN-6493-2] hibagent update

  • Affecting Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Lunar (23.04), Mantic (23.10)

[USN-6492-1] Mosquitto vulnerabilities (08:06)

  • 6 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Lunar (23.04)
  • Multiple memory leaks which can be triggered through crafted packets -> DoS
  • Excessive CPU usage when parsing a connect request from a client with a large number of user-properties -> DoS
  • Logic bug - failed to revoke existing subscriptions when a topic subscription is revoked in some cases - would still get notified after the fact - info / privacy leak

[USN-6498-1] FRR vulnerabilities (08:55)

[USN-6499-1] GnuTLS vulnerability (09:13)

  • 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Lunar (23.04), Mantic (23.10)
  • Timing side-channel during RSA-PSK ClientKeyExchange - response time would vary if given malformed ciphertext compared to when using correct PKCS#1 v1.5 padding - very similar to historical CVE-2023-0361 ([USN-5901-1] GnuTLS vulnerability from Episode 189) - in that case the same issue was fixed for regular RSA - but no-one noticed that the same problematic code existed for this other case as well
  • Old adage - if you want to find a vuln, look near other previous vulns - and by the same token, if a project has a vuln reported, go looking to see if perhaps there are other instances of the same vuln in the code base
  • Lots of projects have lots of copy-pasted or duplicated code within themselves

[USN-6500-1] Squid vulnerabilities (10:20)

  • 5 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Lunar (23.04), Mantic (23.10)
  • Back in early 2021 a security audit was performed on Squid which found 55 vulnerabilities - these were reported to the upstream project and some CVEs were assigned but a lot went without any fix
  • Unfortunately the Squid project is understaffed and hasn’t had the resources to fix all the issues
  • Researchers eventually got tired of waiting (approx 900 days so not surprising) - so released details publicly of all their findings
  • https://megamansec.github.io/Squid-Security-Audit/
  • A mix of CVEs and GHSAs have been assigned for some, but not all issues, so some are still unfixed
  • This update contains fixes for all the CVEs which have been assigned so far - expect more updates in the future

[USN-6494-1] Linux kernel vulnerabilities

[USN-6495-1] Linux kernel vulnerabilities

[USN-6496-1] Linux kernel vulnerabilities

[USN-6497-1] Linux kernel (OEM) vulnerabilities (11:50)

  • 3 CVEs addressed in Jammy (22.04 LTS)
  • Logic issue in handling of x2AVIC MSR in KVM nested virtualisation on AMD processors - could allow an attacker in a guest VM to cause a crash on the host kernel and hence a DoS against the whole host

[USN-6502-1] Linux kernel vulnerabilities

[USN-6502-2] Linux kernel (Oracle) vulnerabilities

[USN-6502-3] Linux kernel (NVIDIA) vulnerabilities

[USN-6503-1] Linux kernel vulnerabilities

[USN-6516-1] Linux kernel (Intel IoTG) vulnerabilities

[USN-6520-1] Linux kernel (StarFive) vulnerabilities

[LSN-0099-1] Linux kernel vulnerability (12:49)

Kernel type 22.04 20.04 18.04 16.04 14.04
aws 99.2 99.1 99.1 99.1 —
aws-5.15 — 99.2 — — —
aws-5.4 — — 99.1 — —
aws-6.2 99.2 — — — —
aws-hwe — — — 99.1 —
azure 99.2 99.1 — 99.1 —
azure-4.15 — — 99.1 — —
azure-5.4 — — 99.1 — —
azure-6.2 99.2 — — — —
gcp 99.2 99.1 — 99.1 —
gcp-4.15 — — 99.1 — —
gcp-5.15 — 99.2 — — —
gcp-5.4 — — 99.1 — —
gcp-6.2 99.2 — — — —
generic-4.15 — — 99.1 99.1 —
generic-4.4 — — — 99.1 99.1
generic-5.15 — 99.2 — — —
generic-5.4 — 99.1 99.1 — —
gke 99.2 99.1 — — —
gke-5.15 — 99.2 — — —
gkeop — 99.1 — — —
hwe-6.2 99.2 — — — —
ibm 99.2 99.1 — — —
ibm-5.15 — 99.2 — — —
ibm-5.4 — — 99.1 — —
linux 99.2 — — — —
lowlatency-4.15 — — 99.1 99.1 —
lowlatency-4.4 — — — 99.1 99.1
lowlatency-5.15 — 99.2 — — —
lowlatency-5.4 — 99.1 99.1 — — 
canonical-livepatch status

[USN-6501-1] RabbitMQ vulnerability

  • 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Lunar (23.04), Mantic (23.10)

[USN-6504-1] tracker-miners vulnerability (13:30)

  • 1 CVEs addressed in Jammy (22.04 LTS), Lunar (23.04), Mantic (23.10)
  • Hardening of the seccomp sandbox in tracker
  • [USN-6423-2] CUE vulnerability (07:04) from Episode 211 - libcue vuln from Kevin Backhouse at Github exploited this weakness in the existing seccomp sandbox to be able to mount their attack for that vulnerability
  • At the time I discussed how the tracker developers were deploying additional hardening to ensure all threads used by tracker-miners were sandboxed - this is that fix

[USN-6505-1] nghttp2 vulnerability (15:20)

[USN-6506-1] Apache HTTP Server vulnerabilities (15:27)

  • 3 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Lunar (23.04), Mantic (23.10)
  • DoS against HTTP/2 implemtation - very similar to historical Slow Loris attack - fixing required backporting the entire version of the http/2 module from 2.0.10 back to earlier releases - thanks to Marc for this herculean effort

[USN-6507-1] GlusterFS vulnerability

  • 1 CVEs addressed in Jammy (22.04 LTS), Lunar (23.04), Mantic (23.10)

[USN-6509-1] Firefox vulnerabilities (16:17)

[USN-6508-1, USN-6508-2] poppler vulnerabilities

[USN-6511-1] OpenZFS vulnerability (17:21)

  • 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Lunar (23.04)
  • Oldest CVE patched in a while - was originally reported to openzfs project back in November 2013 - over 10 years ago
  • When sharing over IPv6 would expose to everyone, not just the intended IPv6 address but to everyone
  • Issue languished, eventually a CVE was assigned in Feb 2021 and then fixed in October 2021

[USN-6510-1] Apache HTTP Server vulnerability

  • 1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM)

[USN-6512-1] LibTIFF vulnerabilities

  • 2 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-6513-1] Python vulnerabilities

[USN-6514-1] Open vSwitch vulnerability (18:18)

  • 1 CVEs addressed in Bionic ESM (18.04 ESM), Focal (20.04 LTS)
  • Failed to properly handle OpenFlow rules for ICMPv6 Neighbour Advertisements - in some circumstances would match against the wrong rules and so could allow an attacker who could load certain rules to then cause other traffic to be redirected contrary to expectations - this would then result in an info leak

[USN-6515-1] Thunderbird vulnerabilities (18:46)

[USN-6517-1] Perl vulnerabilities

[USN-6402-2] LibTomMath vulnerability

[USN-6513-2] Python vulnerability

[USN-6518-1] AFFLIB vulnerability

  • 1 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM)

[USN-6519-1] EC2 hibagent update

  • Affecting Bionic ESM (18.04 ESM)

Get in contact