Sign up to save your podcasts
Or
Share Episode 200
Share to email
Share to Facebook
Share to X
Share to email
Share to Facebook
Share to X
Or
Episode 200
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)
parsing TIFF images
[USN-6168-1, USN-6168-2] libx11 vulnerability (01:55)
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)
(SASL) framework - used by network servers like IMAP/XMPP etc and to
authenticate clients etc
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)
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)
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)
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)
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)
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)
still assigned CVSS 6.5 for NULL ptr deref in demo code - shows the limits of
CVSS as a metric - Daniel Stenberg (curl maintainer) has a good discussion of
this on his blog -
https://ubuntu.com/blog/securing-open-source-through-cve-prioritisation -
there is more to CVEs than just their CVSS score - also CVSS 4 will help a bit
but will still not capture enough nuance, and even if it does, it still won’t
stop the problem of CVEs being misclassified due to a lack of deep
understanding by whoever assigns the CVSS score (and in fact this may be made
worse by CVSS 4 since it contains more attributes used to compute a score)
[USN-6180-1] VLC media player vulnerabilities (09:58)
[USN-5948-2] Werkzeug vulnerabilities (10:16)
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)
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)
forensics-extra package which contains various forensics and ethical hacking
tools etc)
crafted file
[USN-6171-1] Linux kernel vulnerabilities (12:29)
kernel memory (info leak) - none appear to be exploitable remotely
[USN-6172-1] Linux kernel vulnerabilities (13:02)
[USN-6173-1] Linux kernel (OEM) vulnerabilities (13:32)
7 CVEs addressed in Jammy (22.04 LTS)
6.1 OEM
OOB read in the USB handling code for Broadcom FullMAC USB WiFi driver
your machine to be able to trigger (shout out to USBGuard)
OOB write in network queuing scheduler
[USN-6130-1] Linux kernel vulnerabilities from Episode 198
[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)
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.
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
RHEL then released the public statement above
source code - but this does not necessarily contain all the patches and
updates that end up in the various RHEL packages
off - as this is still public
looks like they will use CentOS Stream as their upstream - but will this
then be bug-for-bug compatible with RHEL as they claim?
partners via their usual customer portal - however the standard RHEL license
agreement prohibits these from being used to develop competitor products etc
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
Linux
Get in contact
View all episodes
By Ubuntu Security Team
4.8
1010 ratings
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)
parsing TIFF images
[USN-6168-1, USN-6168-2] libx11 vulnerability (01:55)
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)
(SASL) framework - used by network servers like IMAP/XMPP etc and to
authenticate clients etc
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)
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)
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)
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)
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)
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)
still assigned CVSS 6.5 for NULL ptr deref in demo code - shows the limits of
CVSS as a metric - Daniel Stenberg (curl maintainer) has a good discussion of
this on his blog -
https://ubuntu.com/blog/securing-open-source-through-cve-prioritisation -
there is more to CVEs than just their CVSS score - also CVSS 4 will help a bit
but will still not capture enough nuance, and even if it does, it still won’t
stop the problem of CVEs being misclassified due to a lack of deep
understanding by whoever assigns the CVSS score (and in fact this may be made
worse by CVSS 4 since it contains more attributes used to compute a score)
[USN-6180-1] VLC media player vulnerabilities (09:58)
[USN-5948-2] Werkzeug vulnerabilities (10:16)
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)
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)
forensics-extra package which contains various forensics and ethical hacking
tools etc)
crafted file
[USN-6171-1] Linux kernel vulnerabilities (12:29)
kernel memory (info leak) - none appear to be exploitable remotely
[USN-6172-1] Linux kernel vulnerabilities (13:02)
[USN-6173-1] Linux kernel (OEM) vulnerabilities (13:32)
7 CVEs addressed in Jammy (22.04 LTS)
6.1 OEM
OOB read in the USB handling code for Broadcom FullMAC USB WiFi driver
your machine to be able to trigger (shout out to USBGuard)
OOB write in network queuing scheduler
[USN-6130-1] Linux kernel vulnerabilities from Episode 198
[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)
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.
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
RHEL then released the public statement above
source code - but this does not necessarily contain all the patches and
updates that end up in the various RHEL packages
off - as this is still public
looks like they will use CentOS Stream as their upstream - but will this
then be bug-for-bug compatible with RHEL as they claim?
partners via their usual customer portal - however the standard RHEL license
agreement prohibits these from being used to develop competitor products etc
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
Linux
Get in contact