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

Ubuntu Security Podcast

Episode 200

20 min • 23 juni 2023

Overview

For our 200th episode, we discuss the impact of Red Hat’s decision to stop publicly releasing the RHEL source code, plus we cover security updates for libX11, GNU SASL, QEMU, VLC, pngcheck, the Linux kernel and a whole lot more.

This week in Ubuntu Security Updates

73 unique CVEs addressed

[USN-6163-1] pano13 vulnerabilities (01:08)

  • 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)
  • use by hugin-tools for stitching together photos into a panorama
  • format-string vuln in PTcrop utility which could be abused to execute arbitrary code etc
  • OOB read (looks more like a NULL ptr deref from the upstream patch…) when parsing TIFF images

[USN-6168-1, USN-6168-2] libx11 vulnerability (01:55)

  • 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), Kinetic (22.10), Lunar (23.04)
  • libx11 mishandled various Request, Event and Error IDs - these IDs get used as indexes into various arrays and so can be used to trigger OOB writes up - these IDs get supplied back from the X server to the X client - if were tricked into connecting to a malicious X server, could then either crash X client -> DoS or get code execution - in general, it is highly unlikely to be tricked into connecting to a malicious X server due to the nature of the X protocol (as the X server usually runs on the local machine)

[USN-6169-1] GNU SASL vulnerability (03:22)

  • 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)
  • library and CLI application for the Simple Authentication and Security Layer (SASL) framework - used by network servers like IMAP/XMPP etc and to authenticate clients etc
    • e.g. mutt and neomutt both use this
  • Possible OOB read on server side if client provides crafted auth data -> DoS / info leak against the server

[USN-6155-2] Requests vulnerability (04:02)

[USN-6166-2] libcap2 vulnerability (04:21)

[USN-6083-2] cups-filters vulnerability (04:30)

[USN-6156-2] SSSD regression (04:40)

  • Affecting Focal (20.04 LTS)
  • [USN-6156-1] SSSD vulnerability from Episode 199
  • possible issue if were to install only some of the newer binary packages from the previous security update - fixed by adding more specific dependency info in the package metadata but ideally users should just run apt upgrade or use unattended-upgrades to install security updates as this will upgrade all installed binary packages to all the newer versions, and not say just apt install sssd which would only pull in some of the binary packages

[USN-6167-1] QEMU vulnerabilities (05:31)

  • 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), Kinetic (22.10), Lunar (23.04)
  • All various memory management issues in different guest drivers, which could allow a malicious guest to cause QEMU on the host to crash - not really surprising as the boundary between unprivileged and privileged components is the literal attack surface in this case and so is where security issues of this nature will likely be found

[USN-6176-1] PyPDF2 vulnerability (05:57)

  • 1 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS)
  • Library for handling PDF files
  • Possible infinite loop if input PDF was malformed and finished without containing an expected terminating element - would just keep trying to read even though there was nothing more to read

[USN-6170-1] Podman vulnerabilities (06:26)

  • Affecting Jammy (22.04 LTS)
  • When using podman play kube to create containers / pods / volumes based on a k8s yaml, it would always pull in the k8s.gcr.io/pause image - this is not necessary and it not necessarily maintained and so could present a security issue as a result

[USN-6177-1, USN-6179-1] Jettison vulnerabilities (07:01)

  • 4 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
  • 1 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10), Lunar (23.04)
  • Java library for converting between XML and JSON
  • 3 different stack overflows due to recursive parsing implementation for JSON - so could simply create a JSON structure that had a very deeply nested object to trigger this - plus an associated memory leak -> OOM - fixed by counting number of recursions and bailing if get too deep

[USN-6178-1] SVG++ library vulnerabilities (07:37)

[USN-6180-1] VLC media player vulnerabilities (09:58)

[USN-5948-2] Werkzeug vulnerabilities (10:16)

  • 2 CVEs addressed in Lunar (23.04)
  • various utilities for WSGI applications in python
  • one issue in cookie parsing which could allow a remote attacker to shadow other cookies, another CPU-based DoS via unlimited number of multipart form data parts - since each consumes only a small number of bytes but takes a reasonable amount of CPU time to parse (and also consumes RAM too)

[USN-6143-3] Firefox regressions (11:09)

[USN-6181-1] Ruby vulnerabilities (11:24)

  • 3 CVEs addressed in Kinetic (22.10), Lunar (23.04)
  • 2 different ReDoS, 1 issue in handling of responses in the cgi gem could allow an attacker to modify the response that would then be received by the user via a HTTP response splitting attack

[USN-6182-1] pngcheck vulnerabilities (11:51)

  • 2 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS)
  • Used to verify the integrity of PNG and associated files (used by the forensics-extra package which contains various forensics and ethical hacking tools etc)
  • Ironically this contained a buffer overflow which could be triggered on a crafted file

[USN-6171-1] Linux kernel vulnerabilities (12:29)

[USN-6172-1] Linux kernel vulnerabilities (13:02)

[USN-6173-1] Linux kernel (OEM) vulnerabilities (13:32)

[USN-6174-1] Linux kernel (OEM) vulnerabilities

[USN-6175-1] Linux kernel vulnerabilities (14:11)

[LSN-0095-1] Linux kernel vulnerability (14:25)

Kernel type 22.04 20.04 18.04
aws 95.4 95.4 —
aws-5.15 — 95.4 —
aws-5.4 — — 95.4
azure 95.4 95.4 —
azure-5.4 — — 95.4
gcp 95.4 95.4 —
gcp-5.15 — 95.4 —
gcp-5.4 — — 95.4
generic-5.4 — 95.4 95.4
gke 95.4 95.4 —
gke-5.15 — 95.4 —
gke-5.4 — — 95.4
gkeop — 95.4 —
gkeop-5.4 — — 95.4
ibm 95.4 95.4 —
ibm-5.4 — — 95.4
linux 95.4 — —
lowlatency 95.1 — —
lowlatency-5.4 — 95.4 95.4

To check your kernel type and Livepatch version, enter this command:

canonical-livepatch status

Goings on in Linux Security Community

Red Hat to stop publicly releasing source code for RHEL (14:59)

  • https://www.redhat.com/en/blog/furthering-evolution-centos-stream
    • Previously would release sources for RHEL to git.centos.org - the repo which was used for the previous CentOS Linux - a freely available repackaging of RHEL, more like a downstream - was discontinued at the end of 2021 in favour of CentOS Stream which is positioned more as an upstream of RHEL now.
    • By pushing these sources public, allowed others to inspect their work, but also to create competitor products based off that work - AlmaLinux / Rocky etc - both of which aim to be community versions of RHEL, bug-for-bug compatible etc
    • https://almalinux.org/blog/impact-of-rhel-changes/
    • https://rockylinux.org/news/2023-06-22-press-release/
    • This change first occurred last week, noticed by the AlmaLinux developers - RHEL then released the public statement above
  • Red Hat say CentOS Stream will now be the only public repo for RHEL-related source code - but this does not necessarily contain all the patches and updates that end up in the various RHEL packages
    • AlmaLinux plans to then use CentOS Stream to base their security updates off - as this is still public
    • Rocky Linux is not so open about how they plan to deal with this - also looks like they will use CentOS Stream as their upstream - but will this then be bug-for-bug compatible with RHEL as they claim?
  • Red Hat also say the sources for RHEL will be available to customers and partners via their usual customer portal - however the standard RHEL license agreement prohibits these from being used to develop competitor products etc
  • Doesn’t have a huge impact on Ubuntu as in general we take our patches direct from the upstream projects - and when we have to backport these to older versions, they are not necessarily the same version as used in RHEL anyway so we don’t often use patches from RHEL
  • Will be interesting to see what impact this does have on AlmaLinux and Rocky Linux

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.