Ubuntu Security Podcast

By Ubuntu Security TeamTechnology

Ubuntu Security Podcast episodes

April 13, 2023Episode 193
Overview
The release of Ubuntu 23.04 Lunar Lobster is nigh so we take a look at some of
the things the security team has been doing along the way, plus it’s our 6000th
USN so we look back at the last 19 years of USNs whilst covering security
updates for the Linux kernel, Emacs, Irssi, Sudo, Firefox and more.
This week in Ubuntu Security Updates
109 unique CVEs addressed
[USN-5998-1] Apache Log4j vulnerabilities (01:00)
4 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2022-23307
CVE-2022-23305
CVE-2022-23302
CVE-2019-17571
A bunch of older vulnerabilities, some discovered in the wake of log4shell but
not deemed as critical
[USN-6000-1] Linux kernel (BlueField) vulnerabilities (01:37)
23 CVEs addressed in Focal (20.04 LTS)
CVE-2023-28328
CVE-2023-26607
CVE-2023-23455
CVE-2023-23454
CVE-2023-20938
CVE-2023-1382
CVE-2023-0394
CVE-2023-0266
CVE-2023-0045
CVE-2022-47929
CVE-2022-47520
CVE-2022-42329
CVE-2022-42328
CVE-2022-4139
CVE-2022-41218
CVE-2022-36280
CVE-2022-3623
CVE-2022-3545
CVE-2022-3521
CVE-2022-3435
CVE-2022-3424
CVE-2022-3169
CVE-2023-0461
NVIDIA BlueField specific kernel (5.4)
Most high priority CVE UAF in Upper Level Protocol (mentioned in the last few
episodes)
6000th USN published by the Ubuntu Security team - this one by Rodrigo Zaiden
Out of interest:
USN-5000-1 - also a kernel USN in June 2021 (Steve Beattie)
USN-4000-1 - corosync in May 2019 (Leo Barbosa)
USN-3000-1 - kernel (utopic HWE backported to trusty) in June 2016 (John Johansen)
USN-2000-1 - nova in October 2013 (Jamie Strandboge)
USN-1000-1 - kernel again in October 2010 (Kees Cook)
USN-1-1 - libpng again in October 2004 (Matt Zimmerman)
[USN-6001-1] Linux kernel (AWS) vulnerabilities (04:18)
51 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2023-1118
CVE-2023-26607
CVE-2023-26545
CVE-2023-23455
CVE-2023-1095
CVE-2023-1074
CVE-2023-0394
CVE-2022-47929
CVE-2022-4662
CVE-2022-41850
CVE-2022-41849
CVE-2022-41218
CVE-2022-39188
CVE-2022-3903
CVE-2022-36879
CVE-2022-3646
CVE-2022-36280
CVE-2022-3628
CVE-2022-3303
CVE-2022-3111
CVE-2022-3061
CVE-2022-2991
CVE-2022-2663
CVE-2022-2380
CVE-2022-2318
CVE-2022-2503
CVE-2022-20572
CVE-2022-20132
CVE-2022-1975
CVE-2022-1974
CVE-2022-1516
CVE-2022-1462
CVE-2022-1205
CVE-2022-1195
CVE-2022-1016
CVE-2022-0617
CVE-2022-0494
CVE-2022-0487
CVE-2021-45868
CVE-2021-4203
CVE-2021-4149
CVE-2021-3772
CVE-2021-3732
CVE-2021-3669
CVE-2021-3659
CVE-2021-3428
CVE-2021-28713
CVE-2021-28712
CVE-2021-28711
CVE-2021-26401
CVE-2020-36516
4.4 kernel - wins the prize for the most number of CVEs fixed in a single
update this week - thanks as always to the kernel team for all their work on
these
[USN-6004-1] Linux kernel (Intel IoTG) vulnerabilities (04:42)
15 CVEs addressed in Jammy (22.04 LTS)
CVE-2023-28328
CVE-2023-26606
CVE-2023-23559
CVE-2023-23455
CVE-2023-23454
CVE-2023-0266
CVE-2023-0210
CVE-2023-0045
CVE-2022-48424
CVE-2022-48423
CVE-2022-4382
CVE-2022-41218
CVE-2022-36280
CVE-2022-3424
CVE-2022-2196
5.15 kernel
[USN-6007-1] Linux kernel (GCP) vulnerabilities (04:51)
20 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2023-26607
CVE-2022-43750
CVE-2022-42895
CVE-2022-42329
CVE-2022-42328
CVE-2022-41850
CVE-2022-41849
CVE-2022-39842
CVE-2022-3649
CVE-2022-3646
CVE-2022-3640
CVE-2022-3628
CVE-2022-3545
CVE-2022-3521
CVE-2022-29901
CVE-2022-29900
CVE-2022-2663
CVE-2022-26373
CVE-2022-20369
CVE-2023-0461
4.15 (backported from 18.04 LTS)
[USN-6009-1] Linux kernel (GCP) vulnerabilities
11 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2023-28328
CVE-2023-23559
CVE-2023-23455
CVE-2023-0394
CVE-2023-0266
CVE-2023-0045
CVE-2022-47929
CVE-2022-41218
CVE-2022-36280
CVE-2022-3424
CVE-2021-3669
follow-up kernel update including a bunch more fixes
[USN-6003-1] Emacs vulnerability (05:03)
1 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2023-28617
Similar to [USN-5955-1] Emacs vulnerability [00:50] from Episode 191 - again
if used org-mode to output to a latex document which included other documents
that had shell metacharacters in their filenames, could get code execution as
the user running Emacs
[USN-6002-1] Irssi vulnerability (05:45)
1 CVEs addressed in Kinetic (22.10)
CVE-2023-29132
IRC client - UAF when outputting a line which was not formatted whilst also
outputting a line that was formatted - only likely to be able to be triggered
by various scripts - was discovered after a recent update to GLib 2.75 which
stopped using it’s own internal memory allocator and instead switched to
regular malloc() / free() - would then trigger the memory checking of libc
which detected this
[USN-6005-1] Sudo vulnerabilities (07:25)
2 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2023-28487
CVE-2023-28486
Failed to escape control characters in both the log output and sudoreplay (can
be used to list or play back the commands executed in a sudo session) - and so
could allow an attacker to get code execution as the user running sudoreplay
by injecting terminal control characters
[USN-6010-1] Firefox vulnerabilities (08:45)
15 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2023-29541
CVE-2023-29539
CVE-2023-29538
CVE-2023-29536
CVE-2023-29535
CVE-2023-29533
CVE-2023-29551
CVE-2023-29550
CVE-2023-29549
CVE-2023-29548
CVE-2023-29547
CVE-2023-29544
CVE-2023-29543
CVE-2023-29540
CVE-2023-29537
112.0 - one Linux specific vuln in particular around the handling of
downloaded .desktop files - could allow an attacker to get code execution as
the user running firefox - interesting to note that as a snap, firefox is
confined by default and cannot execute arbitrary commands from the host
system - can only use binaries from within the firefox snap itself or the
user’s $HOME which makes exploitation of such an issue harder since less
LOLBins to make use of
[USN-6011-1] Json-smart vulnerabilities (10:00)
2 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2023-1370
CVE-2021-31684
Small and fast JSON parser for Java - two similar issues, one in handling of
unclosed quotes and the other in unclosed brackets - both could allow an
attacker to DoS the application through crafted input
Goings on in Ubuntu Security Community
Preparing for the release of Ubuntu 23.04 (Lunar Lobster) (10:36)
Team has been busy finishing various items from the development roadmap for
this cycle:
SBOM specification
improvements to how we distribute OVAL data
evaluation of dbus-broker integration with AppArmor to possibly replace
dbus-daemon in a future Ubuntu release
Testing unprivileged user namespace restrictions via AppArmor
io_uring mediation support in AppArmor
Working with the snapd team on integrating dm-verity within snapd for
improved integrity of snaps
Usual maintenance items as well:
all the normal CVE patching
a heap of MIR security reviews
snap store reviews
AppArmor upstream project maintenance
and more
Ubuntu Security Podcast on 2 weeks break
Alex on leave next week and the following week is the 23.10 start-of-cycle
product roadmap sprint in Prague
Expect the podcast to be back the week ending 5th May
Get in contact
[email protected]
#ubuntu-security on the Libera.Chat IRC network
ubuntu-hardened mailing list
Security section on discourse.ubuntu.com
@[email protected], @ubuntu_sec on twitter
15 min
March 31, 2023Episode 192
Overview
Ubuntu gets pwned at Pwn2Own 2023, plus we cover security updates for vulns in
GitPython, object-path, amanda, url-parse and the Linux kernel - and we mention
the recording of Alex’s Everything Open 2023 presentation as well.
This week in Ubuntu Security Updates
91 unique CVEs addressed
[USN-5968-1] GitPython vulnerability [00:46]
1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-24439
RCE via a malicious URL when cloning a repo - would call git clone under the
hood and pass the purported URL in without any validation
Used as a dependency for other Python based tools etc - in particular by
Bandit, Python security checking tool - used to scan python projects for
security issues - would be ironic if a tool used to scan for security problems
could be used to leverage an attack - so I took a quick look at the source
code for bandit and it seems to only use GitPython to check if the current
directory is a git repo or not - so would not be able to be exploited by this
issue
[USN-5967-1] object-path vulnerabilities [02:11]
3 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2021-3805
CVE-2021-23434
CVE-2020-15256
all prototype pollution vulns - a type of injection attack that particularly
applies for languages like Javascript, where an attacker can add arbitrary
properties to global / default javascript objects that then get inherited by
user-defined objects - and so can result in the ability to change the logic of
the application or potentially even get remote code execution (depending on
how those object properties are used by the application)
[USN-5942-2] Apache HTTP Server vulnerability [02:56]
1 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2023-25690
request smuggling attack against mod_proxy
[USN-5966-1, USN-5966-2] amanda vulnerabilities [03:06]
3 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-37705
CVE-2022-37704
CVE-2022-37703
amanda has several suid-root binaries - each was able to be abused in a
different way - one to see if a given directory existed or not (info leak),
and the others to both get code execution etc - update introduced a regression
which was then also fixed
[USN-5969-1] gif2apng vulnerabilities [04:00]
3 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2021-45911
CVE-2021-45910
CVE-2021-45909
[USN-5971-1] Graphviz vulnerabilities [04:12]
3 CVEs addressed in Trusty ESM (14.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2020-18032
CVE-2019-11023
CVE-2018-10196
2 different NULL ptr derefs, 1 buffer overflow -> DoS / RCE
[USN-5954-2] Firefox regressions [04:40]
9 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2023-28161
CVE-2023-28164
CVE-2023-28160
CVE-2023-25751
CVE-2023-28177
CVE-2023-28176
CVE-2023-28162
CVE-2023-25752
CVE-2023-25750
111.0.1 - fixes a couple regressions on macOS and Windows apparently
[USN-5972-1] Thunderbird vulnerabilities [04:58]
6 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2023-25752
CVE-2023-28164
CVE-2023-25751
CVE-2023-28176
CVE-2023-28162
102.9.0
[USN-5973-1] url-parse vulnerabilities [05:11]
8 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2022-0686
CVE-2022-0691
CVE-2022-0639
CVE-2022-0512
CVE-2021-3664
CVE-2021-27515
CVE-2020-8124
CVE-2018-3774
nodejs module for parsing URLs - even for such a seemingly simple task as
parsing URLs, can have various vulnerabilities
DoS, SSRF, open-redirect, or bypass various other authorisation checks
upstream project now recommends to use the URL interface from nodejs and the
various browsers for “better security and accuracy”
[USN-5974-1] GraphicsMagick vulnerabilities [06:24]
7 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2022-1270
CVE-2020-12672
CVE-2019-11006
CVE-2018-9018
CVE-2018-5685
CVE-2018-20189
CVE-2018-20184
[USN-5686-4] Git vulnerability [06:37]
1 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2022-39253
[USN-5686-1] Git vulnerabilities from Episode 181
[USN-5970-1] Linux kernel vulnerabilities [06:45]
9 CVEs addressed in Kinetic (22.10)
CVE-2023-23559
CVE-2023-1195
CVE-2023-0469
CVE-2023-0266
CVE-2023-0045
CVE-2022-4382
CVE-2022-42329
CVE-2022-42328
CVE-2022-2196
[LSN-0093-1] Linux kernel vulnerability [07:15]
2 CVEs addressed in all the various Livepatch supported releases (LTS and
16.04 ESM) across various different kernels
CVE-2023-0461
CVE-2023-0179
UAF in Upper Level Protocol and buffer overflow in netfilter when handling
VLAN headers - both could allow a local user to DoS / code execution in kernel
-> EoP
Kernel type
22.04
20.04
18.04
16.04
aws
93.1
93.1
93.1
—
aws-5.15
—
93.1
—
—
aws-5.4
—
—
93.1
—
aws-hwe
—
—
—
93.1
azure
93.1
93.1
—
93.1
azure-4.15
—
—
93.1
—
azure-5.4
—
—
93.1
—
gcp
93.2
93.1
—
93.1
gcp-4.15
—
—
93.1
—
gcp-5.15
—
93.2
—
—
gcp-5.4
—
—
93.1
—
generic-4.15
—
—
93.1
93.1
generic-5.4
—
93.1
93.1
—
gke
93.2
93.1
—
—
gke-4.15
—
—
93.1
—
gke-5.15
—
93.2
—
—
gke-5.4
—
—
93.1
—
gkeop
—
93.1
—
—
gkeop-5.4
—
—
93.1
—
ibm
93.1
93.1
—
—
linux
93.1
—
—
—
lowlatency-4.15
—
—
93.1
93.1
lowlatency-5.4
—
93.1
93.1
—
oem
—
—
93.1
—
To check your kernel type and Livepatch version, enter this command:
canonical-livepatch status
[USN-5975-1] Linux kernel vulnerabilities
31 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2023-28328
CVE-2023-26607
CVE-2023-23559
CVE-2023-23455
CVE-2023-0394
CVE-2023-0266
CVE-2023-0045
CVE-2022-47929
CVE-2022-43750
CVE-2022-42895
CVE-2022-42329
CVE-2022-42328
CVE-2022-41850
CVE-2022-41849
CVE-2022-41218
CVE-2022-39842
CVE-2022-3649
CVE-2022-3646
CVE-2022-3640
CVE-2022-36280
CVE-2022-3628
CVE-2022-3545
CVE-2022-3521
CVE-2022-3424
CVE-2022-29901
CVE-2022-29900
CVE-2022-2663
CVE-2022-26373
CVE-2022-20369
CVE-2021-3669
CVE-2023-0461
[USN-5976-1] Linux kernel (OEM) vulnerabilities
9 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS)
CVE-2023-0394
CVE-2022-41850
CVE-2022-3649
CVE-2022-3646
CVE-2022-36280
CVE-2022-3628
CVE-2022-3061
CVE-2022-2196
CVE-2023-0461
[USN-5977-1] Linux kernel (OEM) vulnerabilities
3 CVEs addressed in Jammy (22.04 LTS)
CVE-2023-1032
CVE-2022-2196
CVE-2023-1281
[USN-5978-1] Linux kernel (OEM) vulnerabilities
12 CVEs addressed in Jammy (22.04 LTS)
CVE-2023-26545
CVE-2023-23559
CVE-2023-1078
CVE-2023-1075
CVE-2023-1074
CVE-2023-1073
CVE-2023-0394
CVE-2022-4842
CVE-2022-4382
CVE-2022-27672
CVE-2022-2196
CVE-2023-1281
[USN-5979-1] Linux kernel (HWE) vulnerabilities
9 CVEs addressed in Jammy (22.04 LTS)
CVE-2023-23559
CVE-2023-1195
CVE-2023-0469
CVE-2023-0266
CVE-2023-0045
CVE-2022-4382
CVE-2022-42329
CVE-2022-42328
CVE-2022-2196
[USN-5980-1] Linux kernel vulnerabilities
4 CVEs addressed in Focal (20.04 LTS)
CVE-2023-23559
CVE-2022-4382
CVE-2022-2196
CVE-2021-3669
[USN-5981-1] Linux kernel vulnerabilities
11 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2023-28328
CVE-2023-23559
CVE-2023-23455
CVE-2023-0394
CVE-2023-0266
CVE-2023-0045
CVE-2022-47929
CVE-2022-41218
CVE-2022-36280
CVE-2022-3424
CVE-2021-3669
[USN-5982-1] Linux kernel vulnerabilities
15 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS)
CVE-2023-28328
CVE-2023-26606
CVE-2023-23559
CVE-2023-23455
CVE-2023-23454
CVE-2023-0266
CVE-2023-0210
CVE-2023-0045
CVE-2022-48424
CVE-2022-48423
CVE-2022-4382
CVE-2022-41218
CVE-2022-36280
CVE-2022-3424
CVE-2022-2196
Goings on in Ubuntu Security Community
pwn2own 2023 [08:02]
pwn2own - part of CanSecWest security conference in Vancouver, Canada
originally started as an informal event, now is organised by Trend’s ZDI and
is attended by many of the best offensive security research teams in the world
compete to hack various known targets under various categories
Runs over 3 days
Ubuntu Desktop was a target again this year, in particular in the local user
elevation of privilege category - standard unprivileged user account which can
be used to escalate privileges to root - targeting the latest Ubuntu interim
release 22.10 (Kinetic)
competitors get 3 attempts, each with a time limit of 10 minutes to get their
exploit to work
From our side, we had a team of 4 engineers (Steve Beattie, John Johansen and
Georgia Garcia from the Ubuntu Security team and Thadeu Cascardo from the
Ubuntu Kernel team) who were on call to be shown the exploit and vulnerability
and within 30 minutes would have to determine if it was already known or not
Day 1 saw 2 attempts
one unsuccessful, the other was a previously known (but unpatched)
Day 2 saw 1 successful attempt (incorrect pointer scaling issue)
Day 3 saw 3 successful attempts
one also previously known, the other two double free and a UAF
In total, 6 separate teams targeted Ubuntu Desktop, 5 were successful, and the
other was not able to get their exploit to work in the allotted time limit
Details surrounding all of these vulnerabilities is embargoed for now, but
will become available in the future
Only minor details have been released publicly by ZDI at this time (ie
incorrect pointer scaling, double free and UAF) but all (unsurprisingly)
related to the memory unsafety of C
Interesting to see the macOS was only targeted once (successful), and Windows
11 twice (both successful too) yet Ubuntu had 6
Yet last year, there were 6 for WIndows 11, and 4 for Ubuntu
Is Ubuntu seen as an easy target? Or are there more security researchers
looking at Ubuntu compared to Windows nowadays?
Does the open source nature of Linux make it easier to find vulns since the
source code is easily able to be inspected?
Pace of development of the upstream kernel is quite fast, lots of new
subsystems like io_uring and large attack surfaces through unprivileged user
namespaces perhaps make Ubuntu more of an easy target
Part of the motivation to want to restrict access to unprivileged user
namespaces in the future
More details to follow once vulns have been made public
Thanks to Steve, JJ, Georgia and Thadeu
Day 1 Results
Day 2 Results
Day 3 Results
Securing a distro and you own open source project - Everything Open 2023 [14:27]
https://youtu.be/a-_5aJIjjLQ
Ubuntu is one of the most popular Linux distributions and is used by millions
of people all over the world. It contains software from a wide array of
different upstream projects and communities across a number of different
language ecosystems. Ubuntu also aims to provide the best user experience for
consuming all these various pieces of software, whilst being both as secure
and usable as possible.
The Ubuntu Security team is responsible for keeping all of this software
secure and patched against known vulnerabilities, as well as proactively
looking for new possible security issues, and finally for ensuring the
distribution as a whole is secured through proactive hardening work. They also
have a huge depth of experience in working with upstream open source projects
to report, manage patch and disclose security vulnerabilities. Find out both
how they keep Ubuntu secure and how you can improve the security of your own
open source project or the projects you contribute to.
Get in contact
[email protected]
#ubuntu-security on the Libera.Chat IRC network
ubuntu-hardened mailing list
Security section on discourse.ubuntu.com
@[email protected], @ubuntu_sec on twitter
16 min
March 24, 2023Episode 191
Overview
This week saw the unexpected release of Ubuntu 20.04.6 so we go into the detail
behind that, plus we talk Everything Open and we cover security updates
including Emacs, LibreCAD, Python, vim and more.
This week in Ubuntu Security Updates
82 unique CVEs addressed
[USN-5955-1] Emacs vulnerability [00:50]
1 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2022-48339
htmlfontify package would try and validate whether a given file is text by
calling file on it - but would fail to escape the filename - so if a user
could be tricked into running htmlfontify-copy-and-link-dir on a crafted
directory, could get code execution in the context of emacs
Unlikely to be an issue in practice, also there doesn’t appear to be any users
of this function on github (other than references to the documentation for it)
[USN-5956-1, USN-5956-2] PHPMailer vulnerabilities [02:03]
7 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS)
CVE-2021-3603
CVE-2020-13625
CVE-2018-19296
CVE-2017-5223
CVE-2017-11503
CVE-2016-10045
CVE-2016-10033
email sending library for PHP
similarly, possible RCE since could possibly inject commands that would be
passed to the shell when executing the underlying mail command - original
patch didn’t fix properly so second CVE was issued for the fix
[USN-5957-1] LibreCAD vulnerabilities [02:58]
7 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2021-45343
CVE-2021-45342
CVE-2021-45341
CVE-2021-21900
CVE-2021-21899
CVE-2021-21898
CVE-2018-19105
Various memory corruption issues when parsing DXF, DWG, DRW or JWW files
OOB writes, UAFs, NULL ptr deref - RCE / DoS
[USN-5855-2] ImageMagick vulnerabilities [03:37]
2 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-44268
CVE-2022-44267
[USN-5958-1] FFmpeg vulnerabilities [03:45]
4 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-3965
CVE-2022-3964
CVE-2022-3341
CVE-2022-3109
2 NULL ptr derefs and 2 OOB reads -> DoS
[USN-5954-1] Firefox vulnerabilities [03:59]
9 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2023-28161
CVE-2023-28164
CVE-2023-28160
CVE-2023-25751
CVE-2023-28177
CVE-2023-28176
CVE-2023-28162
CVE-2023-25752
CVE-2023-25750
111.0
usual mix of issues for web engines (DoS, info leak across domains, RCE) if
visited a malicious website
memory corruption, plus a few logic issues that could be used to either
cause firefox to leak local information back to the web server or spoof
parts of the UI etc
[USN-5961-1] abcm2ps vulnerabilities
6 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS)
CVE-2021-32436
CVE-2021-32435
CVE-2021-32434
CVE-2019-1010069
CVE-2018-10771
CVE-2018-10753
[USN-5962-1] Linux kernel (Intel IoTG) vulnerabilities [04:47]
18 CVEs addressed in Jammy (22.04 LTS)
CVE-2023-26605
CVE-2023-0468
CVE-2022-47521
CVE-2022-47520
CVE-2022-47519
CVE-2022-47518
CVE-2022-45869
CVE-2022-4379
CVE-2022-42329
CVE-2022-42328
CVE-2022-4139
CVE-2022-3545
CVE-2022-3521
CVE-2022-3435
CVE-2022-3344
CVE-2022-3169
CVE-2023-0179
CVE-2023-0461
two high priority issues
netfilter mishandling of vlan headers - OOB write -> crash / RCE
UAF in upper-level protocol subsystem - can be triggered by local user -
similarly, crash / RCE
[USN-5959-1] Kerberos vulnerabilities [05:32]
2 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2021-37750
CVE-2021-36222
NULL ptr derefs -> crash in kerberos daemon -> DoS
[USN-5960-1] Python vulnerability [05:51]
1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2023-24329
possibly to bypass blocklists in urllib.parse() simply by prefixing the URL
with a space - blocklisting is not part of upstream functionality but often
would be implemented in application / library logic by first using urlparse()
to parse the given URL - if prefixed with a space then can get urlparse() to
fail to return the correct scheme/hostname - can workaround simply by first
calling strip() on URL - apparently upstream still discussing whether the
current fix is sufficient so watch this space
[USN-5963-1] Vim vulnerabilities [07:14]
9 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2023-1264
CVE-2023-1175
CVE-2023-1170
CVE-2023-0051
CVE-2023-0433
CVE-2023-0288
CVE-2023-0054
CVE-2023-0049
CVE-2022-47024
moar vim vulns from bug-bounty - all found via fuzzing of vim - all memory
corruption vulns -> DoS / RCE
[USN-5964-1] curl vulnerabilities [07:41]
5 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2023-27538
CVE-2023-27536
CVE-2023-27535
CVE-2023-27534
CVE-2023-27533
various connection reuse issues - eg. would reuse an SSH connection even if
caller had changed an SSH option - similar for FTP.
mishandling of ~ in SFTP could then allow access to unintended files (would
expand even if not the first part of the path)
[USN-5806-3] Ruby vulnerability [08:43]
1 CVEs addressed in Focal (20.04 LTS)
CVE-2021-33621
[USN-5965-1] TigerVNC vulnerability [08:53]
1 CVEs addressed in Focal (20.04 LTS)
CVE-2020-26117
when processing a TLS certificate, would store that internally as a
certificate authority - then if client connected to a different server would
use that stored cert as a CA cert to validate the new server - could then
allow a malicious server to impersonate other servers
[USN-5904-2] SoX regression [09:35]
9 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-31651
CVE-2022-31650
CVE-2021-40426
CVE-2021-3643
CVE-2021-23210
CVE-2021-23172
CVE-2021-23159
CVE-2019-13590
CVE-2021-33844
Fix for one of the vulns fixed in the original update was incomplete
Goings on in Ubuntu Security Community
Ubuntu 20.04.6 LTS Released [09:49]
https://lists.ubuntu.com/archives/ubuntu-announce/2023-March/000287.html
https://wiki.ubuntu.com/FocalFossa/ReleaseSchedule
Wasn’t originally planned to be released
Unlike previous point releases, 20.04.6 is a refresh of the amd64
installer media after recent key revocations, re-enabling their usage
on Secure Boot enabled systems.
Many other security updates for additional high-impact bug fixes are also
included, with a focus on maintaining stability and compatibility with
Ubuntu 20.04 LTS.
TL;DR - recent vulnerabilities in shim and grub meant that we revoked those
old versions such that they would not boot anymore if updates had been
installed - so if wanted to reinstall using the 20.04.5 media it would fail to
boot. Can prove this to yourself:
cat /sys/firmware/efi/efivars/SbatLevelRT-605dab50-e046-4300-abb6-3dd810dd8b23
sbat,1,2022052400
grub,2
objdump -j .sbat -s grubx64.efi
Ubuntu Security at Everything Open 2023 [12:02]
https://ubuntu.com/blog/everything-open-2023-in-melbourne
https://2023.everythingopen.au/schedule/presentation/64/
Presented about how the Ubuntu Security keeps Ubuntu secure and also gave
advice on how you can improve the security of your own open source projects
Get in contact
[email protected]
#ubuntu-security on the Libera.Chat IRC network
ubuntu-hardened mailing list
Security section on discourse.ubuntu.com
@[email protected], @ubuntu_sec on twitter
15 min
March 10, 2023Episode 190
Overview
The Ubuntu Security Podcast is on a two week break to focus on Everything Open
2023 in Melbourne next week - come hear Alex talk about Securing a distribution
and securing your own open source project in person if you can.
Get in contact
[email protected]
#ubuntu-security on the Libera.Chat IRC network
ubuntu-hardened mailing list
Security section on discourse.ubuntu.com
@[email protected], @ubuntu_sec on twitter
2 min
March 03, 2023Episode 189
Overview
This week we dive into the BlackLotus UEFI bootkit teardown and find out how
this malware has some roots in the FOSS ecosystem, plus we look at security
updates for the Linux kernel, DCMTK, ZoneMinder, Python, tar and more.
This week in Ubuntu Security Updates
111 unique CVEs addressed
[USN-5739-2] MariaDB regression [00:48]
Affecting Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
Latest point release had various memory and performance regressions
[USN-5883-1] Linux kernel (HWE) vulnerabilities [01:05]
19 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2023-0461
CVE-2022-43750
CVE-2022-42895
CVE-2022-42328
CVE-2022-41850
CVE-2022-41849
CVE-2022-39842
CVE-2022-3649
CVE-2022-3646
CVE-2022-3640
CVE-2022-3628
CVE-2022-3545
CVE-2022-3521
CVE-2022-29901
CVE-2022-29900
CVE-2022-2663
CVE-2022-26373
CVE-2022-20369
CVE-2022-4378
4.15 kernel backported from 18.04LTS to 16.04ESM
sysctl stack buffer overflow discussed last week plus a range of other kernel
vulns
[USN-5884-1] Linux kernel (AWS) vulnerabilities [01:26]
6 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2023-23559
CVE-2023-0045
CVE-2022-42895
CVE-2022-41858
CVE-2022-20566
CVE-2021-4155
4.4 GA kernel from 16.04
[USN-5882-1] DCMTK vulnerabilities [01:36]
10 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-43272
CVE-2022-2121
CVE-2022-2120
CVE-2022-2119
CVE-2021-41690
CVE-2021-41689
CVE-2021-41688
CVE-2021-41687
CVE-2019-1010228
CVE-2015-8979
libraries and utils for handling DICOM (Digital Imaging and Communications in
Medicine) image files (used for radiology etc)
various memory corruption issues -> DoS / code execution
[USN-5885-1] APR vulnerability [02:29]
1 CVEs addressed in Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-24963
Integer overflow -> memory corruption -> DoS / code exec
[USN-5886-1] Intel Microcode vulnerabilities [02:44]
4 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-38090
CVE-2022-33972
CVE-2022-33196
CVE-2022-21216
latest upstream release from Intel
Various issues in SGX and out-of-band management - particularly on Intel Xeon
processors - allow require privileged access in the first place (ie admin) but
could allow to then say bypass SGX protections and the like
[USN-5887-1] ClamAV vulnerabilities [03:27]
2 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2023-20052
CVE-2023-20032
latest upstream point release - 0.103.8
one in HFS+ and the other in the DMG parsers - both different filesystem
formats for Apple
[USN-5889-1] ZoneMinder vulnerabilities [03:49]
13 CVEs addressed in Xenial ESM (16.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS)
CVE-2022-29806
CVE-2019-7331
CVE-2019-7332
CVE-2019-7330
CVE-2019-7328
CVE-2019-7327
CVE-2019-7326
CVE-2019-7329
CVE-2019-7325
CVE-2019-6991
CVE-2019-6992
CVE-2019-6990
CVE-2019-6777
Video surveillance software system - includes a web interface so has usual
types of issues and then some
Various XSS issues plus a stack buffer overflow in handling of username /
passwords as would use a fixed size buffer for these (what year is this?) and
a upload file handling issue resulting in possible remote code execution
[USN-5890-1] Open vSwitch vulnerabilities [04:27]
2 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-4338
CVE-2022-4337
[USN-5891-1, USN-5894-1] curl vulnerabilities
3 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2023-23916
CVE-2023-23915
CVE-2023-23914
3 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM)
CVE-2022-43552
CVE-2021-22925
CVE-2021-22898
[USN-5892-1] NSS vulnerabilities
2 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2023-0767
CVE-2022-3479
[USN-5893-1] WebKitGTK vulnerabilities [04:34]
1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2023-23529
type confusion in webkit - Apple says that they had seen reports that this had
been actively exploited in the wild
[USN-5896-1] Rack vulnerabilities
2 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS)
CVE-2022-30123
CVE-2022-30122
[USN-5895-1] MPlayer vulnerabilities
10 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-38861
CVE-2022-38866
CVE-2022-38864
CVE-2022-38863
CVE-2022-38858
CVE-2022-38855
CVE-2022-38851
CVE-2022-38865
CVE-2022-38860
CVE-2022-38850
[USN-5897-1] OpenJDK vulnerabilities [04:55]
2 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2023-21843
CVE-2023-21835
openjdk 11 (aka lts), 17, 18
latest upstream point releases
[USN-5898-1] OpenJDK vulnerabilities [05:05]
2 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2023-21843
CVE-2023-21830
openjdk 8 - also latest upstream point release
[USN-5888-1] Python vulnerabilities [05:09]
6 CVEs addressed in Focal (20.04 LTS)
CVE-2023-24329
CVE-2022-45061
CVE-2022-42919
CVE-2022-37454
CVE-2021-28861
CVE-2015-20107
python3.9 - esm-apps
high priority - vuln in multiprocessing module - if used with forkserver on
Linux would allow pickles to be deserialized from any user on the same machine
in the same network namespace - therefore as one local user can easily get
code execution as another user on the same machine
[USN-5899-1] AWStats vulnerability
1 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-46391
[USN-5901-1] GnuTLS vulnerability
1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2023-0361
[USN-5902-1] PHP vulnerabilities
3 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2023-0662
CVE-2023-0568
CVE-2023-0567
[USN-5821-3] pip regression
1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-40898
[USN-5903-1] lighttpd vulnerabilities
2 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-41556
CVE-2022-22707
[USN-5638-4] Expat vulnerabilities
2 CVEs addressed in Trusty ESM (14.04 ESM)
CVE-2022-43680
CVE-2022-40674
[USN-5900-1] tar vulnerability [06:15]
1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-48303
1-byte OOB read - although as yet no evidence this can be used to gain control
flow hence really only a possible DoS
[USN-5880-2] Firefox regressions [06:42]
15 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2023-25745
CVE-2023-25744
CVE-2023-25742
CVE-2023-25741
CVE-2023-25737
CVE-2023-25736
CVE-2023-25733
CVE-2023-25731
CVE-2023-25739
CVE-2023-25735
CVE-2023-25732
CVE-2023-25730
CVE-2023-25729
CVE-2023-25728
CVE-2023-0767
110.0.1 - biggest regression was that if chose to clear recent cookies it
would clear all cookies - plus a webgl crash when running under vmware on
Linux
Goings on in Ubuntu Security Community
BlackLotus UEFI bootkit teardown [07:23]
https://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/
https://github.com/Wack0/CVE-2022-21894
Teardown of the first in-the-wild UEFI bootkit that bypasses UEFI Secure Boot
by eset
Appears to be BlackLotus which has been sold on hacking and criminal forums
since atleast October 2022
At that time no sample was available so security researchers could not verify
the claims of the malware author, namely:
very small - only 80kb, has anti-debug / obfuscation to help avoid RE
bypasses Windows UAC + Secure Boot and can load unsigned drivers
disables HVCI (hypervisor protected code integrity - a feature designed to
protect the Windows kernel from modification at runtime), BitLocker and
Windows Defender
persists in UEFI and is able to protect itself from being unloaded
uses a signed boot loader so can work on machines with Secure Boot enabled
Of these, the most interesting part for Linux users is the UEFI Secure Boot
bypass - this is something which we theorised was possible via all the
previously disclosed shim and grub vulnerabilities
And in particular, they way they go about this is by using a copy of shim
and grub - but not because they are exploiting any vulnerabilities in them,
but since they are very useful components if you want to boot your own
bootkit
they also exploit a vulnerability in the Windows Boot Manager UEFI binary
which allows them to subvert the Secure Boot process and load their own code
to bypass Secure Boot and gain persistence on future boots
they way they do this is to install their own UEFI binaries into the EFI
partition (including shim and grub) - but also a copy of a vulnerable
version of the Windows Boot Manager UEFI binary plus their own custom boot
configuration data - and since they have disabled BitLocker already these
will happily be loaded at next boot without the usual integrity checks etc
when the machine reboots, their vulnerable Windows Boot Manager binary is
loaded, along with their custom boot configuration data which allows them to
exploit the vulnerability and to then load additional binaries into the boot
process
those binaries then go on to modify the secure boot configuration by
enrolling a new key in the machine owners keyring (aka MOK) db
normally enrolling a new key like this would require a system admin to be
physically present to confirm the operation - but since they bypasses the
normal Secure Boot protections this can be done without any knowledge of
the sysadmin
their grub is signed using this key whilst the shim is Red Hat’s shim -
unmodified and signed by Microsoft and hence trusted - this will then trust
their malicious grub as it is signed by the key they just enrolled in the
MOK
whilst their shim is an unmodified copy, their grub is not - and is actually
malicious
shim then goes on to boot this malicious grub which starts Windows but also
installs a bunch of UEFI memory hooks to be able to subvert further stages
of the boot process and eventually Windows itself
There are lots more details in the teardown article, particularly about how
the various components are installed into Windows and how they are able to
then load additional drivers etc into Windows, plus the further components of
the malware that are able to download additional binaries, how the C2 and
anti-analysis etc works - but this is the USP so we won’t cover those here
But what is interesting for Linux is that this is reusing components that were
ostensibly designed to boot Linux on machines that were originally designed to
boot Windows
one member of our team wondered if Microsoft might become more hesitant
about signing shim in the future - perhaps, but it is not really shim that
is at fault here - the issue is the original vulnerability in the Windows
Boot Manager - shim just helps to make loading additional parts of their
bootkit easier (along with grub) - so hopefully Microsoft don’t go down that
path
and the reason this can be exploited in the first place is that Microsoft
have not revoked their vulnerable Windows Boot Manager binary
back in the original BootHole vulns, various shim’s did get revoked - but
revoking this Microsoft binary would mean many older systems may fail to
boot, including their recovery images and install media etc
ideally Microsoft would revoke this to stop further exploitation
Another interesting wrinkle is that their UEFI exploit apparently appears to
come directly from a PoC that was uploaded to Github in August 2022 - will
likely restart the usual discussions around public PoCs being a “bad thing” as
they can be used for actual malicious purposes
interesting to note the PoC has had additional code added to it in the last
24 hours which allow it to operate on older versions of Windows 10
even more reason for Microsoft to perhaps revoke this old binary
Get in contact
[email protected]
#ubuntu-security on the Libera.Chat IRC network
ubuntu-hardened mailing list
Security section on discourse.ubuntu.com
@[email protected], @ubuntu_sec on twitter
18 min
February 24, 2023Episode 188
Overview
This week the common theme is vulnerabilities in setuid-root binaries and their
use of environment variables, so we take a look at a great blog post from the
Trail of Bits team about one such example in the venerable chfn plus we look at
some security vulnerabilities in, and updates for the Linux kernel, Go Text, the
X Server and more, and finally we cover the recent announcement of Ubuntu
22.04.2 LTS.
This week in Ubuntu Security Updates
75 unique CVEs addressed
[USN-5872-1] NSS vulnerabilities [00:57]
2 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM)
CVE-2022-34480
CVE-2022-22747
[USN-5874-1] Linux kernel vulnerabilities
7 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2023-20928
CVE-2022-42895
CVE-2022-41850
CVE-2022-41849
CVE-2022-3649
CVE-2022-3640
CVE-2022-3628
[USN-5877-1] Linux kernel (GKE) vulnerabilities [01:06]
28 CVEs addressed in Focal (20.04 LTS)
CVE-2023-0590
CVE-2022-47940
CVE-2022-4662
CVE-2022-45934
CVE-2022-43750
CVE-2022-42895
CVE-2022-41850
CVE-2022-41849
CVE-2022-4095
CVE-2022-40307
CVE-2022-39842
CVE-2022-39188
CVE-2022-3649
CVE-2022-3646
CVE-2022-3643
CVE-2022-3640
CVE-2022-3628
CVE-2022-3623
CVE-2022-3619
CVE-2022-3586
CVE-2022-3543
CVE-2022-3303
CVE-2022-3061
CVE-2022-2663
CVE-2022-20421
CVE-2022-0171
CVE-2022-42896
CVE-2022-4378
UAF in L2CAP handshake implementation in bluetooth subsystem - as is in
handshake likely can allow an unprivileged remote attacker within bluetooth
range to crash kernel / leak contents of memory or get RCE - or even a local
unprivileged user could use this to try and escalate their privileges by
turning on bluetooth then attacking the machine via it
Stack buffer overflow in handling of sysctl - need to be able to write a
sysctl which is normally only available to root - but also can be used by root
within a user namespace - so if have unprivileged user namespaces enabled then
a local unpriv user can use this to either crash the kernel or possibly
execute arbitrary code within the kernel -> EoP
[USN-5875-1] Linux kernel (GKE) vulnerabilities [03:20]
11 CVEs addressed in Focal (20.04 LTS)
CVE-2023-20928
CVE-2022-45934
CVE-2022-42895
CVE-2022-41850
CVE-2022-41849
CVE-2022-3649
CVE-2022-3643
CVE-2022-3640
CVE-2022-3628
CVE-2022-42896
CVE-2022-43945
bluetooth UAF
Buffer overflow in the in-kernel NFSD implementation - Episode 184
[USN-5876-1] Linux kernel vulnerabilities
10 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS)
CVE-2023-0590
CVE-2022-47940
CVE-2022-42895
CVE-2022-41850
CVE-2022-41849
CVE-2022-3640
CVE-2022-3628
CVE-2022-3623
CVE-2022-3619
CVE-2022-3543
[USN-5878-1] Linux kernel (Azure) vulnerabilities
5 CVEs addressed in Kinetic (22.10)
CVE-2023-0590
CVE-2022-42895
CVE-2022-3640
CVE-2022-3628
CVE-2022-3619
[USN-5879-1] Linux kernel (HWE) vulnerabilities
9 CVEs addressed in Jammy (22.04 LTS)
CVE-2023-0590
CVE-2022-45934
CVE-2022-42895
CVE-2022-3643
CVE-2022-3640
CVE-2022-3628
CVE-2022-3619
CVE-2022-42896
CVE-2022-4378
[USN-5873-1] Go Text vulnerabilities [03:54]
5 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-32149
CVE-2021-38561
CVE-2020-28852
CVE-2020-28851
CVE-2020-14040
Go lib for text processsing, in particular for handling of Unicode
CPU-based DoS - possible infinite loop on crafted content
Various runtime DoS issues - crafted content could trigger a panic -> crash of
application - often used for parsing of HTTP headers
One of the few cases of a USN where we list the -dev package as the affected
package - quirk of the way Go packages are packaged in Debian and hence
Ubuntu - since go binaries are generally statically compiled, another package
will use the -dev package to build and get statically linked against this - so
the security team has to then rebuild all the other packages in the archive
that use this -dev package
[USN-5880-1] Firefox vulnerabilities [07:15]
15 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2023-25745
CVE-2023-25744
CVE-2023-25742
CVE-2023-25741
CVE-2023-25737
CVE-2023-25736
CVE-2023-25733
CVE-2023-25731
CVE-2023-25739
CVE-2023-25735
CVE-2023-25732
CVE-2023-25730
CVE-2023-25729
CVE-2023-25728
CVE-2023-0767
110.0 release - various memory corruption vulns plus some logic issues
allowing to bypass restrictions etc
[USN-5881-1] Chromium vulnerabilities
13 CVEs addressed in Bionic (18.04 LTS)
CVE-2023-0704
CVE-2023-0703
CVE-2023-0701
CVE-2023-0700
CVE-2023-0474
CVE-2023-0705
CVE-2023-0702
CVE-2023-0699
CVE-2023-0698
CVE-2023-0696
CVE-2023-0473
CVE-2023-0472
CVE-2023-0471
110.0.5481.100 release
also has various memory corruption vulns fixed, same original policy bypass
etc
[USN-5778-2] X.Org X Server vulnerabilities [08:15]
7 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM)
CVE-2023-0494
CVE-2022-46344
CVE-2022-46343
CVE-2022-46342
CVE-2022-46341
CVE-2022-46340
CVE-2022-4283
Various possible attacks against the X server - UAF, stack and heap buffer
overflows etc -> local user could then possibly get EoP when X server is
running as root (as it is on these older releases - only on 18.04 and onwards
does X run as the unprivileged user)
[USN-5807-2] libXpm vulnerabilities [09:01]
3 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2022-4883
CVE-2022-46285
CVE-2022-44617
X11 pixmap handling library
2 CPU-based DoS (infinite loop) issues plus one in handling of compressed
files - would call out to external binaries to decompress these - so if a
malicious user could influence the PATH environment variable could get it to
execute their binaries instead - particularly could be an issue if a setuid()
binary uses libxpm - and this is mentioned in the glibc manual around tips for
writing setuid programs
Goings on in Ubuntu Security Community
Readline crime: exploiting a SUID logic bug [10:06]
Trail of Bits blog has a great writeup of a bug they discovered in chfn as
implemented by the util-linux package - used the readline library for input
handling by many CLI applications - as a result, able to be abused to read the
contents of a root-owned SSH private key
Great dive into the complexities and dangers of using third party libraries in
privileged components
Inspired by a previous
finding
from Qualys, started out looking for setuid binaries that used environment
variables as part of their operation - since this often allows an unprivileged
user to set that env var and then run the setuid binary which then runs as
root - if it then can be influenced by the value of that env var can possibly
then go further to cause other effects as root (EoP?)
Found the chfn binary (which is used to set info about the current user in
/etc/shadow) would use the readline library just to read input from the user -
by default readline will parse its configuration from the INPUTRC environment
variable
When it encounters an invalid config, it will helpfully print out the lines of the
configuration which are invalid
So to get it to dump the contents of some other root-owned file, you can just
set INPUTRC to point to that file and execute chfn and it will then go parse
that - however, the file first has to appear close to the format which is
expected - and it just so happens that SSH private keys fit this bill
One thing to note - it only affected a Arch since on most chfn comes from the
standalone passwd package, not util-linux - and the chfn from passwd didn’t
use readline
Looking for environment variable use (and setuid binaries) is one of the
explicit things the security team does when auditing packages as part of the MIR security review process
Ubuntu 22.04.2 LTS released [14:55]
Delayed by 2 weeks - is finally here!
Includes various fixes rolled into the 22.04 LTS release - if you are already
running 22.04 LTS with updates enabled you will already have it
Ubuntu Pro is now integrated within gnome-initial-setup - previously this
was only Livepatch, but can now enable any of the Ubuntu Pro offerings as
soon as you log in for the first time.
After logging in you can enrol the machine in Ubuntu Pro directly from the
initial setup wizard and choose which elements - esm-infra / esm-apps /
livepatch and even FIPS and USG (Ubuntu Security Guide for CIS and DISA-STIG
compliance and auditing)
Uses the HWE kernel - 5.19 (22.10 - kinetic)
Kernel and shim etc are now signed by new signing key since old one has been
deny-listed in latest shim due to having signed a version of grub2 which is
now known to have various vulnerabilities that could enable a local attacker
to bypass secure boot restrictions (Boot Hole v3 v4?)
Plus a heap of other changes
Complete list can be found on the Ubuntu Discourse
Get in contact
[email protected]
#ubuntu-security on the Libera.Chat IRC network
ubuntu-hardened mailing list
Security section on discourse.ubuntu.com
@[email protected], @ubuntu_sec on twitter
20 min
February 17, 2023Episode 187
Overview
After the announcement of Ubuntu Pro GA last week, we take the time to dispel
some myths around all things Ubuntu Pro, esm-apps and apt etc, plus Camila sits
down with Mark and David to discuss the backstory of Editorconfig CVE-2023-0341
and we also have a brief summary of the security updates from the past week.
Ubuntu Pro, esm-apps and apt confusions [00:40]
https://www.theregister.com/2022/10/13/canonical_ubuntu_ad/
talks in general about Ubuntu Pro notices in apt but doesn’t cover any
details
https://www.omgubuntu.co.uk/2022/10/ubuntu-pro-terminal-ad
talks more about the details but seems to think it is only beneficial for
LTS releasing at the end of the LTS
https://news.ycombinator.com/item?id=33260896
almost no engagement on hacker news
But there has been a lot of users expressing a lot of emotion over the
appearance now of the new ‘advertisement’ for Ubuntu Pro / esm-apps when they
run apt update, e.g.:
The following security updates require Ubuntu Pro with 'esm-apps' enabled:
python2.7-minimal python2.7 libpython2.7-minimal libpython2.7-stdlib
Learn more about Ubuntu Pro at https://ubuntu.com/pro
There appears to be a few main issues:
Users don’t like what appears to be an advertisement in the apt output
Some updates now appear to be behind a “paywall”
Whilst they are free for personal use, to get access to them you need to
register an account on Ubuntu One etc and this requires providing various
high-level personal details (Name, Email etc)
So let’s take some time to look into these issues:
This is not the first time Canonical has tried to raise awareness of
various products - e.g. motd etc - so perhaps this causes more frustration
for users - however, if desired it can be disabled:
pro config set apt_news False
Ubuntu Pro is free for personal / small-scale commercial use - any user is
entitled to a free Ubuntu Pro subscription on up to 5 machines
this can be for bare metal or virtual machines and using either Ubuntu
Server or Desktop - the install / Ubuntu type doesn’t matter
and as we mentioned last week, if you are an Ubuntu member you get an
entitlement for 50 machines
currently this is not reflected in the https://ubuntu.com/pro/dashboard
(it still says 5 machines against the free personal token)
so there is nothing to pay here - likely most folks that find this
objectionable are personal users and so are entitled to the free
subscription
the other big part of this is that some folks seem to think these updates
are now only available via Ubuntu Pro when previously they were part of
the regular Ubuntu archive
this is incorrect - the esm-apps part of this message indicates that
these updates are for packages in the Universe component of the Ubuntu
archive - previously this has only ever been community supported - and
so the Ubuntu Security team would only ever provide security updates on
rare occasions OR if a member of the community came along and provided
an update in the form of a debdiff which could be sponsored by someone
from the Ubuntu Security team
but now the team is starting to do security updates for packages in
Universe and these are being made available via Ubuntu Pro
so if you do not enrol in Ubuntu Pro, your machine is still getting the
regular security updates for the Main+Restricted components as it
always was
but if you do choose to enrol in Ubuntu Pro you can get these extra
security updates that were never previously available
On the issue of having to provide some personal information to get access
to Ubuntu One, I realise this can be a bit contentious given that a lot of
Ubuntu and Linux users in general can be quite privacy conscious - however
this is not really any different than other online services like
Github/Gmail etc - and as said earlier, if you choose to not enrol in
Ubuntu Pro, you are just as secure as you always were - and to avoid having
to see the prompt in your apt update output, you can disable that as
mentioned earlier and so restore your system to the same state as it used
to be - as always, you are in control of your own machine
Hopefully this helps to dispel some of the myths and concerns surrounding
Ubuntu Pro and encourage folks to use it - the Ubuntu Security Team and others
at Canonical have put a lot of work into Ubuntu Pro behind the scenes and we
think this provides a lot of great security benefits and so encourage all
listeners to make use of it to ensure their systems are as secure as possible
The inside story of Editorconfig CVE-2023-0341 [09:05]
Interview by Camila Camargo de Matos with David Fernandez Gonzalez and Mark
Esler about the discovery and investigation of CVE-2023-0341 in Editorconfig
([USN-5842-1] EditorConfig Core C vulnerability from Episode 186)
Keynote: Improving FOSS Security - Mark Esler | UbuCon Asia 2022
https://litios.github.io/2023/01/14/CVE-2023-0341.html
This week in Ubuntu Security Updates [25:19]
64 unique CVEs addressed
[USN-5849-1] Heimdal vulnerabilities
1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2022-45142
[USN-5835-4] Cinder vulnerability
1 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2022-47951
[USN-5835-5] Nova vulnerability
1 CVEs addressed in Bionic (18.04 LTS)
CVE-2022-47951
[USN-5852-1] OpenStack Swift vulnerability
1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-47950
[USN-5850-1] Linux kernel vulnerabilities
5 CVEs addressed in Kinetic (22.10)
CVE-2023-0590
CVE-2022-42895
CVE-2022-3640
CVE-2022-3628
CVE-2022-3619
[USN-5854-1] Linux kernel vulnerabilities
11 CVEs addressed in Bionic (18.04 LTS)
CVE-2022-43750
CVE-2022-41850
CVE-2022-41849
CVE-2022-39842
CVE-2022-3649
CVE-2022-3646
CVE-2022-29901
CVE-2022-29900
CVE-2022-2663
CVE-2022-26373
CVE-2022-20369
[USN-5855-1] ImageMagick vulnerabilities
2 CVEs addressed in Bionic (18.04 LTS)
CVE-2022-44268
CVE-2022-44267
[USN-5856-1] Linux kernel (OEM) vulnerabilities
3 CVEs addressed in Jammy (22.04 LTS)
CVE-2022-3424
CVE-2022-1048
CVE-2023-0179
[USN-5857-1] Linux kernel (OEM) vulnerability
1 CVEs addressed in Jammy (22.04 LTS)
CVE-2023-0179
[USN-5858-1] Linux kernel (OEM) vulnerabilities
4 CVEs addressed in Jammy (22.04 LTS)
CVE-2022-45934
CVE-2022-42895
CVE-2022-3545
CVE-2023-0179
[USN-5859-1] Linux kernel (OEM) vulnerabilities
4 CVEs addressed in Focal (20.04 LTS)
CVE-2022-42895
CVE-2022-4139
CVE-2022-3545
CVE-2023-0179
[USN-5848-1] less vulnerability
1 CVEs addressed in Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-46663
[USN-5860-1] Linux kernel (GKE) vulnerabilities
14 CVEs addressed in Jammy (22.04 LTS)
CVE-2023-0590
CVE-2022-47940
CVE-2022-45934
CVE-2022-42895
CVE-2022-41850
CVE-2022-41849
CVE-2022-3643
CVE-2022-3640
CVE-2022-3628
CVE-2022-3623
CVE-2022-3619
CVE-2022-3543
CVE-2022-42896
CVE-2022-4378
[USN-5861-1] Linux kernel (Dell300x) vulnerabilities
15 CVEs addressed in Bionic (18.04 LTS)
CVE-2022-45934
CVE-2022-43750
CVE-2022-41850
CVE-2022-41849
CVE-2022-39842
CVE-2022-3649
CVE-2022-3646
CVE-2022-3643
CVE-2022-29901
CVE-2022-29900
CVE-2022-2663
CVE-2022-26373
CVE-2022-20369
CVE-2022-42896
CVE-2022-43945
[USN-5862-1] Linux kernel (Qualcomm Snapdragon) vulnerabilities
11 CVEs addressed in Bionic (18.04 LTS)
CVE-2022-43750
CVE-2022-41850
CVE-2022-41849
CVE-2022-39842
CVE-2022-3649
CVE-2022-3646
CVE-2022-29901
CVE-2022-29900
CVE-2022-2663
CVE-2022-26373
CVE-2022-20369
[USN-5863-1] Linux kernel (Azure) vulnerabilities
4 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2022-45934
CVE-2022-3643
CVE-2022-42896
CVE-2022-43945
[USN-5865-1] Linux kernel (Azure) vulnerabilities
11 CVEs addressed in Bionic (18.04 LTS)
CVE-2022-43750
CVE-2022-41850
CVE-2022-41849
CVE-2022-39842
CVE-2022-3649
CVE-2022-3646
CVE-2022-29901
CVE-2022-29900
CVE-2022-2663
CVE-2022-26373
CVE-2022-20369
[USN-5866-1] Nova vulnerabilities
5 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2022-37394
CVE-2021-3654
CVE-2020-17376
CVE-2017-18191
CVE-2015-9543
[USN-5867-1] WebKitGTK vulnerabilities
3 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2023-23518
CVE-2023-23517
CVE-2022-42826
[USN-5864-1] Fig2dev vulnerabilities
14 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2021-32280
CVE-2021-3561
CVE-2020-21676
CVE-2020-21675
CVE-2020-21535
CVE-2020-21534
CVE-2020-21533
CVE-2020-21532
CVE-2020-21531
CVE-2020-21530
CVE-2020-21529
CVE-2019-19797
CVE-2019-19555
CVE-2019-14275
[LSN-0091-1] Linux kernel vulnerability
2 CVEs addressed in
CVE-2022-42719
CVE-2022-41222
[USN-5869-1] HAProxy vulnerability
2 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2023-25725
CVE-2023-24580
[USN-5871-1] Git vulnerabilities
2 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2023-23946
CVE-2023-22490
[USN-5870-1] apr-util vulnerability
1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-25147
Get in contact
[email protected]
#ubuntu-security on the Libera.Chat IRC network
ubuntu-hardened mailing list
Security section on discourse.ubuntu.com
@[email protected], @ubuntu_sec on twitter
28 min
February 10, 2023Episode 186
Overview
The Ubuntu Security Podcast is back for 2023! We ease into the year with
coverage of the recently announced launch of Ubuntu Pro as GA, plus we look at
some recent vulns in git, sudo, OpenSSL and more.
This week in Ubuntu Security Updates
212 unique CVEs addressed
[USN-5778-1] X.Org X Server vulnerabilities
6 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-46344
CVE-2022-46343
CVE-2022-46342
CVE-2022-46341
CVE-2022-46340
CVE-2022-4283
[USN-5779-1] Linux kernel (Azure) vulnerabilities
9 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS)
CVE-2022-3621
CVE-2022-3594
CVE-2022-3567
CVE-2022-3566
CVE-2022-3565
CVE-2022-3564
CVE-2022-3524
CVE-2022-42703
CVE-2022-43945
[USN-5780-1] Linux kernel (OEM) vulnerabilities
5 CVEs addressed in Jammy (22.04 LTS)
CVE-2022-42896
CVE-2022-42895
CVE-2022-3628
CVE-2022-3619
CVE-2022-3524
[USN-5781-1] Emacs vulnerability
1 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2022-45939
[USN-5782-1] Firefox vulnerabilities
7 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2022-46879
CVE-2022-46878
CVE-2022-46877
CVE-2022-46874
CVE-2022-46873
CVE-2022-46872
CVE-2022-46871
[USN-5783-1] Linux kernel (OEM) vulnerability
1 CVEs addressed in Jammy (22.04 LTS)
CVE-2022-42896
[USN-5784-1] usbredir vulnerability
1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2021-3700
[USN-5785-1] FreeRADIUS vulnerabilities
3 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS)
CVE-2022-41861
CVE-2022-41860
CVE-2019-17185
[USN-5786-1] GNOME Files vulnerability
1 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-37290
[USN-5787-1] Libksba vulnerability
1 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-47629
[USN-5782-2] Firefox regressions
7 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2022-46879
CVE-2022-46878
CVE-2022-46877
CVE-2022-46874
CVE-2022-46873
CVE-2022-46872
CVE-2022-46871
[USN-5789-1] Linux kernel (OEM) vulnerabilities
10 CVEs addressed in Focal (20.04 LTS)
CVE-2022-3621
CVE-2022-3594
CVE-2022-3567
CVE-2022-3566
CVE-2022-3564
CVE-2022-3524
CVE-2022-33743
CVE-2022-26365
CVE-2022-42703
CVE-2022-43945
[USN-5788-1] curl vulnerabilities
2 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-43552
CVE-2022-43551
[USN-5790-1] Linux kernel vulnerabilities
7 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS)
CVE-2022-4095
CVE-2022-40307
CVE-2022-39188
CVE-2022-3586
CVE-2022-3061
CVE-2022-20421
CVE-2021-4159
[USN-5791-1] Linux kernel vulnerabilities
10 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2022-43750
CVE-2022-4095
CVE-2022-40307
CVE-2022-39842
CVE-2022-3646
CVE-2022-3586
CVE-2022-3303
CVE-2022-3061
CVE-2022-2663
CVE-2022-20421
[USN-5792-1] Linux kernel vulnerabilities
13 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS)
CVE-2022-43750
CVE-2022-4095
CVE-2022-40307
CVE-2022-39842
CVE-2022-39188
CVE-2022-3649
CVE-2022-3646
CVE-2022-3586
CVE-2022-3303
CVE-2022-3061
CVE-2022-2663
CVE-2022-20421
CVE-2022-0171
[USN-5793-1] Linux kernel vulnerabilities
17 CVEs addressed in Kinetic (22.10)
CVE-2022-43750
CVE-2022-41850
CVE-2022-41849
CVE-2022-4095
CVE-2022-40307
CVE-2022-3977
CVE-2022-3649
CVE-2022-3623
CVE-2022-3586
CVE-2022-3646
CVE-2022-3544
CVE-2022-3543
CVE-2022-3541
CVE-2022-3303
CVE-2022-2663
CVE-2022-20421
CVE-2022-3910
[USN-5794-1] Linux kernel (AWS) vulnerabilities
4 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2022-45934
CVE-2022-3643
CVE-2022-42896
CVE-2022-43945
[USN-5787-2] Libksba vulnerability
1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM)
CVE-2022-47629
[USN-5795-1] Net-SNMP vulnerabilities
2 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-44793
CVE-2022-44792
[USN-5796-1] w3m vulnerability
1 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-38223
[USN-5797-1] WebKitGTK vulnerabilities
7 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-46700
CVE-2022-46699
CVE-2022-46698
CVE-2022-46692
CVE-2022-42867
CVE-2022-42856
CVE-2022-42852
[USN-5792-2] Linux kernel vulnerabilities
13 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS)
CVE-2022-43750
CVE-2022-4095
CVE-2022-40307
CVE-2022-39842
CVE-2022-39188
CVE-2022-3649
CVE-2022-3646
CVE-2022-3586
CVE-2022-3303
CVE-2022-3061
CVE-2022-2663
CVE-2022-20421
CVE-2022-0171
[USN-5793-2] Linux kernel (Azure) vulnerabilities
17 CVEs addressed in Kinetic (22.10)
CVE-2022-43750
CVE-2022-41850
CVE-2022-41849
CVE-2022-4095
CVE-2022-40307
CVE-2022-3977
CVE-2022-3649
CVE-2022-3623
CVE-2022-3586
CVE-2022-3646
CVE-2022-3544
CVE-2022-3543
CVE-2022-3541
CVE-2022-3303
CVE-2022-2663
CVE-2022-20421
CVE-2022-3910
[USN-5782-3] Firefox regressions
7 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2022-46879
CVE-2022-46878
CVE-2022-46877
CVE-2022-46874
CVE-2022-46873
CVE-2022-46872
CVE-2022-46871
[USN-5796-2] w3m vulnerability
1 CVEs addressed in Trusty ESM (14.04 ESM)
CVE-2022-38223
[USN-5798-1] .NET 6 vulnerability
1 CVEs addressed in Jammy (22.04 LTS), Kinetic (22.10)
CVE-2023-21538
[USN-5791-3] Linux kernel (Azure) vulnerabilities
10 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2022-43750
CVE-2022-4095
CVE-2022-40307
CVE-2022-39842
CVE-2022-3646
CVE-2022-3586
CVE-2022-3303
CVE-2022-3061
CVE-2022-2663
CVE-2022-20421
[USN-5793-3] Linux kernel vulnerabilities
17 CVEs addressed in Kinetic (22.10)
CVE-2022-43750
CVE-2022-41850
CVE-2022-41849
CVE-2022-4095
CVE-2022-40307
CVE-2022-3977
CVE-2022-3649
CVE-2022-3623
CVE-2022-3586
CVE-2022-3646
CVE-2022-3544
CVE-2022-3543
CVE-2022-3541
CVE-2022-3303
CVE-2022-2663
CVE-2022-20421
CVE-2022-3910
[USN-5793-4] Linux kernel (IBM) vulnerabilities
17 CVEs addressed in Kinetic (22.10)
CVE-2022-43750
CVE-2022-41850
CVE-2022-41849
CVE-2022-4095
CVE-2022-40307
CVE-2022-3977
CVE-2022-3649
CVE-2022-3623
CVE-2022-3586
CVE-2022-3646
CVE-2022-3544
CVE-2022-3543
CVE-2022-3541
CVE-2022-3303
CVE-2022-2663
CVE-2022-20421
CVE-2022-3910
[USN-5799-1] Linux kernel (OEM) vulnerability
1 CVEs addressed in Jammy (22.04 LTS)
CVE-2022-4378
[USN-5800-1] Heimdal vulnerabilities
4 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2022-44640
CVE-2022-42898
CVE-2022-3437
CVE-2021-44758
[USN-5802-1] Linux kernel vulnerabilities
4 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM)
CVE-2022-45934
CVE-2022-3643
CVE-2022-42896
CVE-2022-43945
[USN-5803-1] Linux kernel vulnerabilities
4 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-45934
CVE-2022-3643
CVE-2022-42896
CVE-2022-4378
[USN-5804-1] Linux kernel vulnerabilities
4 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2022-45934
CVE-2022-3643
CVE-2022-42896
CVE-2022-43945
[USN-5801-1] Vim vulnerabilities
2 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS)
CVE-2022-0417
CVE-2022-0392
[USN-5804-2] Linux kernel vulnerabilities
4 CVEs addressed in Bionic (18.04 LTS)
CVE-2022-45934
CVE-2022-3643
CVE-2022-42896
CVE-2022-43945
[USN-5805-1] Apache Maven vulnerability
1 CVEs addressed in Kinetic (22.10)
CVE-2021-26291
[USN-5795-2] Net-SNMP vulnerabilities
8 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM)
CVE-2022-44793
CVE-2022-44792
CVE-2022-24810
CVE-2022-24809
CVE-2022-24808
CVE-2022-24807
CVE-2022-24806
CVE-2022-24805
[USN-5808-1] Linux kernel (IBM) vulnerabilities
4 CVEs addressed in Bionic (18.04 LTS)
CVE-2022-45934
CVE-2022-3643
CVE-2022-42896
CVE-2022-43945
[USN-5810-1, USN-5810-2, USN-5810-3] Git vulnerabilities [01:16]
2 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-41903
CVE-2022-23521
Integer overflow when parsing really long paths specified in .gitattributes
But depends if file is in working tree, index or both since when parsed
normally the parsing is done in chunks which mitigates the vuln
leads to heap reads/writes -> RCE
Integer overflow when using a crafted format specifier for git log or git archive
Not too common to use random format specifiers, but how many people have
wanted a prettier git log output, and copy-pasted something from stack
overflow without understanding it?
We talk about the provenance and integrity of code for OSS / supply chain
attacks - interesting to think about it from a configuration / data point of
view
Can ChatGPT be poisoned to spit out dangerous configs?
[USN-5811-1, USN-5811-2, USN-5811-3] Sudo vulnerabilities [03:34]
2 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-33070
CVE-2023-22809
Most interesting was a vuln in sudoedit - ie the command to edit a file with
sudo - launches your specified editor to edit the file
The editor is specified via various environment variables - SUDO_EDITOR,
VISUAL or EDITOR - these would normally specify the binary of the editor to
use
But could also include extra arguments to pass to the editor - such as
additional filenames by separating them with a double hyphen --
As such a user could set their EDITOR=vim -- /etc/shadow - then when sudoedit
launches the editor for the originally specified file, would also launch it
with this file too
Allows a user to bypass possible restrictions set via /etc/sudoers - ie since
could be configured to only allow a user to edit say the apache config via
sudoedit
[USN-5812-1] urllib3 vulnerability
1 CVEs addressed in Focal (20.04 LTS)
CVE-2021-33503
[USN-5810-2] Git regression
2 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2022-41903
CVE-2022-23521
[USN-5813-1] Linux kernel vulnerabilities
4 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2022-45934
CVE-2022-3643
CVE-2022-42896
CVE-2022-43945
[USN-5814-1] Linux kernel vulnerabilities
4 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-45934
CVE-2022-3643
CVE-2022-42896
CVE-2022-4378
[USN-5815-1] Linux kernel (BlueField) vulnerabilities
10 CVEs addressed in Focal (20.04 LTS)
CVE-2022-43750
CVE-2022-4095
CVE-2022-40307
CVE-2022-39842
CVE-2022-3646
CVE-2022-3586
CVE-2022-3303
CVE-2022-3061
CVE-2022-2663
CVE-2022-20421
[USN-5816-1] Firefox vulnerabilities
9 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2023-23606
CVE-2023-23605
CVE-2023-23604
CVE-2023-23603
CVE-2023-23602
CVE-2023-23601
CVE-2023-23599
CVE-2023-23598
CVE-2023-23597
[USN-5817-1] Setuptools vulnerability
1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-40897
[USN-5818-1] PHP vulnerability
1 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-31631
[USN-5819-1] HAProxy vulnerability
1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2023-0056
[USN-5806-2] Ruby vulnerability
1 CVEs addressed in Bionic (18.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2021-33621
[USN-5820-1] exuberant-ctags vulnerability
1 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-4515
[USN-5821-1] wheel vulnerability
1 CVEs addressed in Trusty ESM (14.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-40898
[USN-5822-1] Samba vulnerabilities
7 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-45141
CVE-2022-42898
CVE-2022-38023
CVE-2022-37967
CVE-2022-37966
CVE-2022-3437
CVE-2021-20251
[USN-5823-1] MySQL vulnerabilities
20 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2023-21887
CVE-2023-21883
CVE-2023-21882
CVE-2023-21881
CVE-2023-21880
CVE-2023-21879
CVE-2023-21878
CVE-2023-21877
CVE-2023-21876
CVE-2023-21875
CVE-2023-21873
CVE-2023-21871
CVE-2023-21870
CVE-2023-21869
CVE-2023-21868
CVE-2023-21867
CVE-2023-21863
CVE-2023-21840
CVE-2023-21836
CVE-2022-32221
[USN-5823-2] MySQL vulnerability
1 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2023-21840
[USN-5825-1] PAM vulnerability
1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-28321
[USN-5826-1] Privoxy vulnerabilities
2 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2021-44543
CVE-2021-44540
[USN-5827-1] Bind vulnerabilities
3 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-3924
CVE-2022-3736
CVE-2022-3094
[USN-5828-1] Kerberos vulnerabilities
2 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-42898
CVE-2018-20217
[USN-5829-1] Linux kernel (Raspberry Pi) vulnerabilities
4 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2022-45934
CVE-2022-3643
CVE-2022-42896
CVE-2022-43945
[USN-5822-2] Samba regression
7 CVEs addressed in Focal (20.04 LTS)
CVE-2022-45141
CVE-2022-42898
CVE-2022-38023
CVE-2022-37967
CVE-2022-37966
CVE-2022-3437
CVE-2021-20251
[USN-5830-1] Linux kernel vulnerabilities
4 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2022-45934
CVE-2022-3643
CVE-2022-42896
CVE-2022-43945
[USN-5831-1] Linux kernel (Azure CVM) vulnerabilities
4 CVEs addressed in Jammy (22.04 LTS)
CVE-2022-45934
CVE-2022-3643
CVE-2022-42896
CVE-2022-4378
[USN-5823-3] MySQL regression
Affecting Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
[USN-5832-1] Linux kernel (Raspberry Pi) vulnerabilities
4 CVEs addressed in Kinetic (22.10)
CVE-2022-45934
CVE-2022-3643
CVE-2022-42896
CVE-2022-4378
[USN-5833-1] python-future vulnerability
1 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-40899
[USN-5835-1] Cinder vulnerability
1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-47951
[USN-5835-2] OpenStack Glance vulnerability
1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-47951
[USN-5835-3] Nova vulnerability
1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-47951
[USN-5834-1] Apache HTTP Server vulnerabilities
2 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2022-36760
CVE-2006-20001
[USN-5836-1] Vim vulnerabilities
5 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM)
CVE-2023-0433
CVE-2023-0288
CVE-2023-0054
CVE-2023-0049
CVE-2022-47024
[USN-4781-2] Slurm vulnerabilities
9 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM)
CVE-2021-31215
CVE-2020-27746
CVE-2020-27745
CVE-2020-12693
CVE-2019-6438
CVE-2018-7033
CVE-2017-15566
CVE-2018-10995
CVE-2016-10030
[USN-5837-1] Django vulnerability
1 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2023-23969
[USN-5839-1] Apache HTTP Server vulnerabilities
3 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-37436
CVE-2022-36760
CVE-2006-20001
[USN-5838-1] AdvanceCOMP vulnerabilities
7 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-35016
CVE-2022-35015
CVE-2022-35020
CVE-2022-35019
CVE-2022-35018
CVE-2022-35017
CVE-2022-35014
[USN-5837-2] Django vulnerability
1 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2023-23969
[USN-5839-2] Apache HTTP Server vulnerability
1 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2022-37436
[USN-5840-1] Long Range ZIP vulnerabilities
6 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2018-5786
CVE-2022-28044
CVE-2022-26291
CVE-2021-27347
CVE-2021-27345
CVE-2020-25467
[USN-5841-1] LibTIFF vulnerabilities
6 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM)
CVE-2022-48281
CVE-2022-3970
CVE-2020-35524
CVE-2020-35523
CVE-2019-17546
CVE-2019-14973
[USN-5816-2] Firefox regressions
9 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2023-23606
CVE-2023-23605
CVE-2023-23604
CVE-2023-23603
CVE-2023-23602
CVE-2023-23601
CVE-2023-23599
CVE-2023-23598
CVE-2023-23597
[USN-5825-2] PAM regressions
1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-28321
[USN-5824-1] Thunderbird vulnerabilities
29 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2023-0430
CVE-2023-23603
CVE-2023-23602
CVE-2023-23601
CVE-2023-23599
CVE-2023-23598
CVE-2022-46877
CVE-2022-46874
CVE-2022-46872
CVE-2022-46871
CVE-2022-45416
CVE-2022-45414
CVE-2022-45412
CVE-2023-23605
CVE-2022-46882
CVE-2022-46881
CVE-2022-46880
CVE-2022-46878
CVE-2022-45421
CVE-2022-45420
CVE-2022-45418
CVE-2022-45411
CVE-2022-45410
CVE-2022-45409
CVE-2022-45408
CVE-2022-45406
CVE-2022-45405
CVE-2022-45404
CVE-2022-45403
[USN-5842-1] EditorConfig Core C vulnerability [05:24]
1 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2023-0341
Discovered by Mark Esler and David Fernandez Gonzalez from Ubuntu Security team
Will be discussed in more detail in an upcoming episode with an interview with
both Mark and David - TL;DR - Mark decided to fuzz some regex handling in
editorconfig-core-c whilst doing a security audit as part of the MIR
process. This uncovered a few crashes which David then looked into an
identified a heap buffer overflow. He then went further and was able to
develop an input that would allow to jump to an arbitrary location, ie. code
execution. So was able to demonstrate a heap buffer overflow that could lead
to code execution from untrusted input data.
Will have to wait for hopefully next weeks episode to get the real inside
story
[USN-5843-1] tmux vulnerability
1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-47016
[USN-5810-3] Git vulnerabilities
2 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2022-41903
CVE-2022-23521
[USN-5844-1, USN-5845-1, USN-5845-2] OpenSSL vulnerabilities [08:06]
8 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2023-0401
CVE-2023-0217
CVE-2023-0216
CVE-2023-0215
CVE-2022-4450
CVE-2022-4304
CVE-2022-4203
CVE-2023-0286
2 CVEs addressed in Trusty ESM (14.04 ESM), Bionic (18.04 LTS)
CVE-2023-0215
CVE-2023-0286
Most interesting issue was a type confusion in handling of X.509
certificates - when parsing the X.400 address would parse it as a string but
other code would assume this was a simple type. As such, when comparing this
to other values this would not be done correctly. Thus could bypass these
checks, in particular which are used for CRL processing and that could then
lead to the ability to read other memory contents or crash the application.
So whilst not a heartbleed (since is a lot more complicated and doesn’t allow
the same level of control of the memory which is read and hence is unlikely to
be able to be used to read out private keys etc)
[USN-5846-1] X.Org X Server vulnerability
1 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2023-0494
[USN-5847-1] Grunt vulnerabilities
3 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS)
CVE-2022-1537
CVE-2022-0436
CVE-2020-7729
Goings on in Ubuntu Security Community
Ubuntu Pro GA [09:33]
https://ubuntu.com/blog/ubuntu-pro-enters-ga
https://ubuntu.com/pro
https://www.omgubuntu.co.uk/2023/01/ubuntu-pro-general-availability
In late January Canonical announced the general availability of Ubuntu Pro
you may have noticed this in your apt update output, e.g.:
The following security updates require Ubuntu Pro with 'esm-apps' enabled:
python2.7-minimal python2.7 libpython2.7-minimal libpython2.7-stdlib
Learn more about Ubuntu Pro at https://ubuntu.com/pro
TL;DR - security team is now patching vulnerabilities in packages in the
universe component of the Ubuntu archive
these patched packages get published under the esm-apps service of Ubuntu Pro
ESM has evolved from extended to expanded security maintenance
not only can you get security updates for packages in main once a release
reaches the end of the LTS period, you also get security updates for
packages in universe both during the LTS period and during the 5 year ESM
period too
Ubuntu Pro gives 10 years of security support for both packages in both main
and universe
Ubuntu Pro is free for personal use on up to 5 machines (50 if you are an
Ubuntu member)
for commercial organisations, 30 day free trial
More details in Ubuntu Pro Beta overview with Lech Sandecki and Eduardo Barretto from Episode 180
Hiring [12:58]
Chief Information Security Officer
Product Marketing Manager - Security
Security Certifications Product Manager - CIS, FIPS, FedRAMP and more
Ubuntu Security Manager
Multiple possible focus areas:
Security Maintenance (CVE and vulnerability addressing life cycle)
Security Technology (AppArmor, Secureboot, and Cryptography)
Certifications and Compliance (FIPS, CIS, FedRAMP)
Linux Cryptography and Security Engineer
Security Engineer - Ubuntu
Get in contact
[email protected]
#ubuntu-security on the Libera.Chat IRC network
ubuntu-hardened mailing list
Security section on discourse.ubuntu.com
@[email protected], @ubuntu_sec on twitter
16 min
December 16, 2022Episode 185
Overview
For our final episode of 2022, Camila is back with a special holiday themed
discussion of the security of open source code, plus we hint at what is in store
for the podcast for 2023 and we cover some recent security updates including
Python, PostgreSQL, Squid and more.
This week in Ubuntu Security Updates
54 unique CVEs addressed
[USN-5765-1] PostgreSQL vulnerability [00:55]
1 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2021-23222
[USN-5145-1] PostgreSQL vulnerabilities in Episode 138
Akin to STARTTLS vulns - could inject cleartext before a secure connection has
been established
[USN-5766-1] Heimdal vulnerability [01:38]
1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2022-41916
Buffer over-read of 1 byte with crafted certificate - crash
[USN-5768-1] GNU C Library vulnerabilities [01:47]
4 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2017-12132
CVE-2020-27618
CVE-2019-25013
CVE-2016-10228
Various possible crasher bugs in low-level utils that are not expected to run
on untrusted input
[USN-5767-1, USN-5767-2] Python vulnerabilities [02:24]
2 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-45061
CVE-2022-37454
1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM)
CVE-2022-45061
CPU based DoS when parsing IDNA (internationalised domain names in
applications - ie. unicode / bidirectional in your domain names) - used an
algorithm that was quadratic [O(n²)] - so if an attacker provided a really
long domain name that included crafted bidirectional unicode contents to be
parsed by the client, could cause the client to use lots of CPU resources to
parse this - this code was used by the socket and asyncio modules - and so
simply returning a 3xx redirect header with a crafted Location could trigger
this bug
Possible integer overflow in SHA3 implementation - but python is memory safe -
true but this code was implemented in C
[USN-5769-1] protobuf vulnerabilities [03:56]
2 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2022-1941
CVE-2015-5237
[USN-5770-1] GCC vulnerability
1 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2017-11671
[USN-5771-1] Squid regression [04:05]
6 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2018-1000027
CVE-2018-1000024
CVE-2016-3948
CVE-2016-2571
CVE-2016-2570
CVE-2016-2569
Very old update to squid introduced a possible regression - initially thought
this was just a logging issue but turns out it was a real bug - an off-by-one
issue would mean squid would sometimes file to find items that were already
cached - only applies where the HTTP server is using the Vary header
[USN-5772-1] QEMU vulnerabilities [05:18]
6 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-3165
CVE-2022-2962
CVE-2022-0216
CVE-2021-3930
CVE-2021-3750
CVE-2021-3682
Various guest to host issues - allowing a guest to crash QEMU on the host
[USN-5754-2, USN-5756-3] Linux kernel (Azure) vulnerabilities [05:39]
8 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Kinetic (22.10)
CVE-2022-3621
CVE-2022-3594
CVE-2022-3567
CVE-2022-3566
CVE-2022-3565
CVE-2022-3564
CVE-2022-3524
CVE-2022-43945
5.19 for 22.10, 5.4 for 20.04 LTS + 18.04 LTS
Most interesting is the high priority one we mentioned last week -
[USN-5754-1] Linux kernel
vulnerabilities - Buffer overflow in NFSD
[USN-5773-1] Linux kernel (OEM) vulnerabilities [06:14]
10 CVEs addressed in Jammy (22.04 LTS)
CVE-2022-3621
CVE-2022-3594
CVE-2022-3567
CVE-2022-3566
CVE-2022-3564
CVE-2022-3524
CVE-2022-33743
CVE-2022-26365
CVE-2022-42703
CVE-2022-43945
5.17
Essentially the same as above but also includes the anonymous VMA mapping vuln
from GPZ discussed in the last 2 episodes
[USN-5774-1] Linux kernel (Azure) vulnerabilities [06:59]
16 CVEs addressed in Trusty ESM (14.04 ESM), Bionic (18.04 LTS)
CVE-2022-40768
CVE-2022-36879
CVE-2022-3635
CVE-2022-3621
CVE-2022-3594
CVE-2022-3567
CVE-2022-3566
CVE-2022-3565
CVE-2022-3564
CVE-2022-3524
CVE-2022-3239
CVE-2022-3028
CVE-2022-2978
CVE-2022-2153
CVE-2022-20422
CVE-2022-42703
4.15
[USN-5775-1] Vim vulnerabilities [07:18]
6 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2022-3591
CVE-2022-3324
CVE-2022-3256
CVE-2022-3099
CVE-2022-2581
CVE-2022-2345
Moar vim CVEs - none of these are high impact - all reported via their bug
bounty program, found via fuzzing
[USN-5776-1] containerd vulnerabilities [08:07]
4 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-24778
CVE-2022-24769
CVE-2022-31030
CVE-2022-23471
[USN-5777-1] Pillow vulnerabilities
2 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS)
CVE-2022-45198
CVE-2022-24303
Goings on in Ubuntu Security Community
Camila discusses the security of open source vs proprietary code [08:38]
Transcript
Hello listener! It has been a while since I last showed up here to share with
you some of my thoughts and spread the knowledge, and today I am back in order
to try to fix that, remove the void I have left in the hearts of those that
enjoy listening to me rambling about a certain cyber security topic. That being
said, I recorded my first podcast segment during the holiday season last year,
and I thought it would be very poetic to return at the same time this year to
record once again. Especially after I was struck with inspiration after spending
a little time with my family. Nothing more fitting for this once again holiday
episode, considering it is the time of the year - the most wonderful one - when
we usually enjoy mingling and celebrating with family and friends. The time of
the year where we meet in order to eat some good food, spend some quality time
together, catch up on life, share the joy… and answer the always asked
question by someone who knows you work with computers: “Do you think it’s a
virus?”. “Yes, uncle, it probably is, since the link you clicked on that said
‘Free 1000 dollar Christmas vouchers for the first 10 clicks’ is most likely a
scam. But hey, I gotta go now, because it is time for some delicious holiday
season desserts! Your computer can survive a few more hours doing some
cryptomining for some random hacker, so I’ll check on that later for you”.
Anyway, surprising as it may be, this actually was not the topic of conversation
that brought me here today, although I fully expect the previously mentioned
question to come my way whenever I do meet my family for the end of the year
festivities of 2022. Instead, I was asked a question that would probably have my
holiday treats wait for me a little bit longer, since it is one I find
compelling to answer, and one that I thought would be actually interesting to
share the answer to, so that you can take it to your holiday meetings as a hot
topic of conversation…you know…show off a little bit to the ones you love.
So…to elaborate a little bit more on my story and on this so far mysterious
question…while sipping on some delicious cocoa surrounded by some fairy lights
and the cold air - even though it is summer during the end of the year where I
live…I see you, southern hemisphere. I was traveling when this happened - my
dearest not-in-the-IT-field family member asked me the following question while
we had a conversation about my job: “how is it possible to have security in a
software when the code for that software is available for all to see on the
Internet?”. Running a prettify function on this question, we can word it as:
“how can open source software be secure if the code is public?”. And that,
family and friends, is the question that we wish to answer today. I already
answered my family member, but now, I want to do it the fancy way, the holiday
spirit way! So gather around with your drinks and delicious appetizers, and
before we head for dinner, and of course, dessert, let’s think about the year we
leave behind, the code that was a part of it, and why, in the year of 2022, can
this code be secure when everyone knows exactly what it is.
Let’s begin this beautiful holiday sharing moment by actually talking about what
is open source software and what is NOT open source software, as well as why one
would think that the former is less secure than the latter. To keep it simple:
open source software is the kind of software where the source code, a.k.a. the
instructions that will be transformed into the computer program that you will
later use, is publicly available for all to see. Those that wish to do so can
inspect this software’s code to know exactly how it does what it does. They can
use it freely if following its license terms, and they can even modify it, maybe
change its functionalities, be it through creation of a copy of that code that
branches from the original version, or be it with authorization from the
creator/maintainer of the software to edit the original version wherever it is
being maintained. A beautiful example to bring this all together in your mind:
almost all software packages in Ubuntu are open source. The programs you run in
your Ubuntu OS come from code that is publicly available for all to access
through the loveliest Internet. For many packages, it is possible to choose one
from main or universe, for example, and find its code in a repository after a
quick web search. Even quicker: you can download the source code related to the
executables and libraries apt installs in your Ubuntu OS when you run ‘apt-get
install ’ by running ‘apt-get source
’ instead. Please remember to replace
with the actual package name if you’re gonna try to
do this. Anyway, this package you download with apt may have its code differ a
little bit from the original code for that software package, the one maintained
by its creator or any successors, also known as the upstream code, and that may
happen for various reasons, which I will not go too much further into here,
however, to put it directly: this code associated with the package will most
likely have its regular upstream maintainers, with a lot of them also accepting
contributions from people that might use this software, care about its wellbeing
or even…its security, and the source code in an Ubuntu package will be nothing
more than a copy of an upstream version that is being contributed to by the
Ubuntu teams and the Ubuntu community. Very much in the holiday spirit, one of
the ideas of open source is to have people collaborate on software, as well as
have software be shared with those that wish to use it, sometimes with changes.
Moving on…on the other side of our coin, we have non-open source software,
also known as closed source software, which is software for which the source
code is not publicly available for all to inspect, use or modify. Closed source
software has its source code protected, with only an authorized group of
people - who are usually a part of the organization that developed said software
or that is currently maintaining it after taking responsibility for it at a
certain point in time - having access to this source code, be it to change the
source code or to simply look at it and know what it is. Closed software is
usually not free to use and users that wish to have access to the software and
its functionalities will only be able to obtain a final executable version of
it, where it is very difficult to acquire information on the source…unless you
are very determined, but more on that later. For now, know that closed source
software will allow you to execute it, but you can’t know what you are executing
unless you do some very intense digging. As for an example…let’s put it this
way, so that you can fill in the blanks: if Ubuntu is a door and the doors are
open, then that must mean that the Windows are … . And there you have your
answer. I mean…it is the holiday season and we would rather have our guests
come in to celebrate through the door instead of any other way. And I say this
because I want you to understand that there is no right or wrong when it comes
to open source and closed source, there are only preferences and needs. There
are situations where one will be more useful than the other, or where one might
be preferred over the other. Who am I to judge if you let people into your house
through your window, or your chimney? What actually matters to us here is: why
is closed source usually considered something more secure “intuitively” when
open source can be just as, or arguably, even more secure? So, let’s try to
answer that question, shall we? When you think about wanting to protect
something, you think about keeping it hidden, keeping it a secret. Wait…this
is not nearly festive enough for a holiday episode. Let’s try again. When you
don’t want someone to guess what is going to be the surprise holiday dessert you
are serving by the end of dinner, you usually won’t tell them anything about
it. You will hide the recipe, cook your dessert following that recipe, but only
allow your guests to know what it is and eat it once the time is just
right. After all, the holidays are all about each family’s tradition, and I know
dessert eating schedules are definitely a part of it for many. Anyway, the point
here is…if no one knows what the dessert is and they don’t have access to your
house while you cook it, bake it, prepare it in general, they cannot copy this
recipe to bring their own version of your dessert to your holiday celebration -
or any other holiday celebration, for that matter - and they can only speculate
on the ingredients once they eat it. And…since you kept your ingredients and
your cooking utensils far away from messy hands while you prepared your dessert,
no one can tamper with it, maybe steal a little bite before it is actually
complete, or even add a missing ingredient without authorization. You keep your
dessert “safe” by actually hiding it, allowing people access only when the final
product is complete. As much as I love holiday season analogies, let’s put our
cyber security glasses back on and see this situation from the closed source
point of view: your recipe is your source code; you preparing the dessert is you
editing, building and compiling the code to create an executable program; and
this executable program is actually your final holiday dessert.
You’re not sharing your source code, meaning people cannot tamper with it,
cannot create a bad copy of it and cannot inspect it in order to figure out
possible failures or ways to exploit it. Yes, even I have fallen victim to the
“too much sugar” mistake when baking stuff, but sometimes we can try to mask
mistakes with other ingredients and no one will ever know…This can also be
called security through obscurity, when you rely on secrecy and confidentiality
in order to avoid the exposure of weaknesses and the direct targeting that may
befall your software. How can a hacker actually exploit my code if they don’t
know what the code is? That is the idea behind security through obscurity. I
will not get into the details of whether security through obscurity is an
effective practice or not, because that is a very intense and polarizing
subject, and it is the holiday season…let’s leave the heated discussions for
some other time. I will say, however, that it directly clashes with the open
source premise, and it is one of the reasons that may be behind the choice of
making software closed source. However, even though this might be a way to
protect your software from exploitation and from vulnerability discovery, it is
not a fool proof technique to avoid the really determined from figuring out what
they want when they are trying to hack you. Talking once more about desserts,
because they are delicious and a very pleasing analogy to consider…if you
have, for example, a friend or family member that is a chef. They go to your
holiday dinner party and then eat your dessert, which we will consider here as
being a beautiful multilayered trifle. They eat your trifle and because they are
so experienced in the art of cooking, they are able to tell all of the
ingredients you have in your cream after tasting it. It is not a skill everyone
possesses - discovering the trifle recipe is no trifle matter…one might say -
and it is not something everyone will be looking forward to do…after all, some
of us simply want to eat and enjoy the food, be the ingredients what they
may. However, there might just be that someone that is willing and capable to go
the extra mile to figure out your recipe…and let me tell you the bad
news…there is not much you can do about it, because there is not much you can
hide about your dessert if you intend to serve it for people to eat.
The same goes for code. Yes, it is possible to not share the source code of your
software, but for a computer to run a software, it needs to follow the
instructions that were transformed into the executable program that originated
from the source code. So even if the executable does not contain the exact
source code, it will contain something that can be extracted and analyzed by the
brave and patient. Any program out there can be reverse engineered into its low
level code version, and this low level code, mainly created to be machine
readable code, when analyzed, will tell you more about what the source code
could actually be. You are able to get from the final product to the actual
recipe that led you to that product…even if the low level code will be very
difficult to analyze and piece together in order to form something similar to
what would be the original source code that generated it. But doubt not my
friend…there are people out there that are willing to do this, and sometimes
these people can be really, really good at it. So that is why security through
obscurity can help, as it is one more barrier that a hacker needs to cross in
order to be able to possibly tamper with a system, however, it is not an
impenetrable one, and it will only stop those lazy enough to cross it…or those
that maybe ate too much during dinner already and will pass on dessert.
Aah, holiday season food is delicious, isn’t it? Plus, I’m not the type to pass
on dessert, and I am definitely not done talking about them, the holiday spirit
and how it all relates to open source code quite yet, so let’s keep going. Hold
on to that dessert analogy, because we will bring it back shortly. For now, we
move on, understanding one reason why it might seem that closed source is safer
or more secure than open source. Especially when you think about one of the main
activities performed by the Ubuntu Security team, which is applying patches to
vulnerabilities that are constantly being found in the source code of packages
that can be installed in Ubuntu, or that are found in the core of Ubuntu, the
kernel. Throughout all the seasons, including the holiday season, we fix issues
that are being found by people from the community that look into and identify
flaws in these packages, sometimes even unintentionally. We can see this as
people finding problems with our recipe and pointing them out to us, forcing us
to change it so that the end result will be something better, something that all
can enjoy. “Hey, you have peanuts here, what about the people who have peanut
allergies that will eat this?”…or…“Hey, if this is cooked in the southern
hemisphere, where it is hot during the holiday season instead of cold, this rest
time for the cream might be too much and it will be too much of a liquid by the
time you want to put your trifle in its final container”. And while you listen
to all these complaints and look at your recipe book, you might think it is all
very annoying…having to change your recipe to fix all these problems…but
when you actually think about it…is it not helpful instead? I mean…you don’t
wanna kill grandma because you forgot she was allergic to peanuts, do you? Had
you not made your recipe public, you might have not discovered that you had to
change it…the bad way: by having grandma spit that trifle all over the floor
and scold you because grandma might fall for phishing scams from time to time,
but she knows better than to eat hidden peanuts in your trifle. Also…this is a
podcast with positive vibes, so let’s not actually consider the worst of the
worst situation here for grandma and for you as well… but you get the point.
Do not kid yourself by thinking that closed source software has less bugs than
open source software. They might be encountered at a smaller rate, since
analysis of the source code is something harder to do and can only be done by
people with access to the code, however, they are there…and sometimes, people
figure this out in the worst way possible: when they have already been
hacked. And then it is a race to figure out where the bug that caused the issue
is, so that it can be fixed. By making the source code public, people that are
willing to help and are willing to make this code better, safer and more robust
have the chance to actively participate in its development and improve the
overall final product. One of the reasons why open source software came to be
was exactly to provide users with more security, since it is easier to find
hidden problems in that which has a lot of people auditing AND it is also easier
to trust that which you can audit. Imagine if your prankster cousin wants to
tamper with your dessert, and they add an extra bad ingredient to the recipe
without your knowledge after you leave them a while with your recipe
book…after all, you also need to prepare your holiday dinner. Anyway, if you
had decided to hide your dessert recipe from everyone, people would only know
something was incredibly wrong once they would have eaten it. Of course, if you
were hiding it from everyone, you would have also hidden it from your prankster
cousin and not shown them the recipe in the first place, but they could have
just as easily found another way to get to it, and if they did a good job
changing the recipe without your knowledge, you might not even know it had been
tampered with at all. Shoutout to a well known comedy series in which someone
adds some savory food to what is supposed to be a dessert trifle because they
thought that was the correct recipe, when it was actually all a
misunderstanding. The ones who know, will know… Of course, when you hide your
recipe book well enough, it is not expected that the recipe will be tampered
with, but sometimes, you yourself are the one doing the tampering…you holiday
prankster, you! You want to play a prank on your friends and family during the
holidays and decide to add something weird to your dessert. If your recipe is
public, however, people are able to check for mistakes, and if they see
something that might be a problem to them, they can tell you so that you can fix
it, or they can choose to not eat your dessert if you don’t want to act on your
apparent mistake. Sure, if you make your recipe public maybe you don’t get to do
the prank - which is actually not really nice on your part, considering that you
are hosting a holiday party to entertain people you love and care about - but if
you don’t make it public, there might be people who just won’t eat your dessert
out of lack of trust in you.
When we talk about source code, we have the same. Being able to check the source
code for a program you wish to use will allow you to check if the source code is
doing something you don’t see as being secure, or if it is behaving insecurely
due to a bug. You can even create your own copy of the source with the changes
you find are necessary in order to get to use the software in a way you find
acceptable! However, since the code is public and a lot of people end up using
it, a community usually builds around it and there are always the ones looking
to improve code, fix its bugs, and make it more secure overall, so maybe you
won’t even need your own edited copy of the source code, since you can just
share your concerns with that community and the issue might be addressed
directly in the upstream version of the code. Of course this all depends if the
software you are considering has an active upstream and is being properly
maintained…that is unfortunately a downside to free and open source software:
not all code out there is being properly taken care of…not everyone has the
holiday spirit and wants to improve on their dessert recipes. They write it once
and just make it available to whoever wants to cook it without any extra
additions or mistake corrections. However, fear not, because at least when we
are talking about security, information regarding vulnerabilities found in open
source code is mostly shared publicly, and, since it is possible to have your
own copy of the code to edit, people who have these copies can also edit their
own versions to fix issues that were found by other people, be it with their own
fixes be it with fixes provided by the upstream developers that maintain the
software (when they exist)…as we do with Ubuntu packages! So as you can see,
open source truly encompasses the holiday spirit, by allowing people to share
and by allowing software to improve under the suggestions of many people. The
open source community being a group of friends sitting together to share that
holiday dinner, find possible issues and solve them so that next year said
dinner can be even more delicious…and maybe even have some extra desserts!
So there you have it, the reason why you don’t need to worry about open source
being insecure just because the source code is public. Sure, there is a risk
involved with having your code be public, but I had a teacher that once taught
me that sometimes it is not about hiding the algorithm, but instead about making
it that the algorithm is so well structured that it doesn’t matter that said
algorithm is public, since there is simply no way to exploit it. The basic
example are the cryptographic algorithms out there that we use to encrypt our
data: the algorithms are public, since we need a standard and people need to
know how things work in order to implement the standard and use it in their
applications, however, it doesn’t matter that they are public and that people
know the steps necessary to encrypt or decrypt some plain text, because what
matters is that if there is no key, breaking the encryption is simply not
achievable in our average lifespan with the average resources. The power of the
algorithm is in the way it works, the math and the theory that support it, and
not in its visibility. Everyone can look at the algorithm, and its security
stands strong. So without that key, breaking encryption is nearly
impossible. When writing open source code, the idea is to follow this same
premise: write good code, in such a way that it doesn’t matter that it is
public, because even if it is, it is not exploitable since you programmed it
with security in mind. So no…please don’t hardcode passwords into your open
source code. That is not secure practice, and that is not open source being
secure. Don’t do it in your closed source code…because this is not closed
source being secure also!
Strive to write a dessert recipe that is so perfect, that it doesn’t matter if
someone tries to tamper with it once it is completed, your dessert will come out
delicious every time! Yeah, I see you prankster cousin, trying to turn on the
heat to get my trifle to melt. It won’t though because I added gelatine to
it…or whatever ingredient is needed to not have cream melt…I’m not a cooking
expert…my family and friends definitely know that. Anyway, of course there are
problems that you might still come across even when cooking or coding with
deliciousness and security in mind. Because there is no dessert that can be
saved by you using 3kg of salt instead of 3g of salt on what is supposed to be
something sweet, because there is an accidental extra ‘k’ in your recipe…but
you get the point, and open source gets the point! Because if your dessert
recipe is an open recipe and someone finds this “accidental” 3kgs-of-salt
mistake - which happens, we are all human and we make mistakes - they can tell
you about it and you can fix it! So buy a recipe notebook that can be left
outside and no one can write on it unless they use the special notebook pen
which you own the rights to, sign your instructions so that you know which ones
are trustworthy, and fix the mistakes you find along the way when people that
want to share this amazing thing with you give you a nudge about it. You will
then know that you are doing your best to provide people with the best holiday
dessert ever, so that everyone can enjoy it together during this special holiday
time! Also…you know…secure open source code during the holidays as well!
Well, dearest friends and family, that is all of the holiday spirit I have to
share with you today! I wish you all an amazing holiday season, filled with
love, joy, open source and lots and lots of security patches! Feel free to share
your thoughts about this podcast segment and the topic related to it in any of
our social media channels! I hope you enjoyed it, and for now, I bid you all
farewell, and until next time! Bye!
Credit to https://www.fesliyanstudios.com for the background music.
Ubuntu Security team and podcast on holiday break [34:37]
Almost all of Canonical is on leave for 2 weeks
Various security team members will be in and out over the break - some taking more leave after that
Podcast will also take a break for a few weeks - likely return in late January
Hope to look at some changes / perhaps a more permanent co-host and other changes in 2023
Wishing all our listeners a safe and enjoyable holiday season
Get in contact
[email protected]
#ubuntu-security on the Libera.Chat IRC network
ubuntu-hardened mailing list
Security section on discourse.ubuntu.com
@[email protected], @ubuntu_sec on twitter
37 min
December 09, 2022Episode 184
Overview
This week we cover Mark Esler’s keynote address from UbuCon Asia 2022 on
Improving FOSS Security, plus we look at security vulnerabilities and updates
for snapd, the Linux kernel, ca-certificates and more.
This week in Ubuntu Security Updates
42 unique CVEs addressed
[USN-5753-1] snapd vulnerability [01:08]
1 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-3328
Follow-up to the last snapd vulnerability (see Oh Snap! More Lemmings (Local Privilege Escalation in snap-confine) from Episode 149)
https://blog.qualys.com/vulnerabilities-threat-research/2022/11/30/race-condition-in-snap-confines-must_mkdir_and_open_with_perms-cve-2022-3328
A slightly simplified explanation is as follows
Part of that vulnerability was that snap-confine creates a private tmp for
each snap - and this is created under the system’s real /tmp so that its disk
usage etc gets accounted for as part of the normal /tmp
But /tmp is world writable so it is trivial for a user to create the expected
per-snap directory and place their own contents inside that such that they can
have this be executed by snap-confine during the process of creating this
private /tmp namespace for the snap - and hence get privilege escalation to root as snap-confine is suid
the original fix then relied on checking if this path was appropriately owned
by root etc - and if not, it would create a new random directory then move the
imposter out of the way and replace it with the one it just created via rename()
But this is not atomic so could be raced - and even though the fix included
additional checks to try and catch any failed race, Qualys found a way to win
this race and avoid those checks
New fix is to use systemd-tmpfiles to create a /tmp/snap-private-tmp/
directory on boot with the appropriate restrictive permissions
Then snap-confine can create the per-snap private /tmp within this without
fear of being interfered with by unprivileged users
Thanks to Qualys for their help in reporting this and reviewing patches etc
[USN-5743-2] LibTIFF vulnerability [05:10]
1 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-3970
[USN-5743-1] LibTIFF vulnerability from Episode 183
[USN-5752-1] Linux kernel (Azure CVM) vulnerabilities [05:20]
6 CVEs addressed in Jammy (22.04 LTS)
CVE-2022-42722
CVE-2022-42721
CVE-2022-42720
CVE-2022-42719
CVE-2022-41674
CVE-2022-2602
5.15 azure fde 22.04 LTS
Race condition in io_uring -> UAF (from Pwn2Own 2022)
[LSN-0090-1] Linux kernel vulnerability from Episode 182
[USN-5754-1] Linux kernel vulnerabilities [05:50]
8 CVEs addressed in Kinetic (22.10)
CVE-2022-3621
CVE-2022-3594
CVE-2022-3567
CVE-2022-3566
CVE-2022-3565
CVE-2022-3564
CVE-2022-3524
CVE-2022-43945
5.19 generic/aws/gcp/ibm/kvm/oracle/raspi/lowlatency
Buffer overflow in NFSD in kernel affecting only very recent kernel versions
(5.19.17 to 6.0.2)
would allow a remote client to trigger this stack buffer overflow and
potentially get code execution within the kernel
[USN-5755-1] Linux kernel vulnerabilities [06:18]
9 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS)
CVE-2022-3621
CVE-2022-3594
CVE-2022-3567
CVE-2022-3566
CVE-2022-3565
CVE-2022-3564
CVE-2022-3524
CVE-2022-42703
CVE-2022-43945
5.15 generic/aws/gcp/ibm/kvm/oracle/raspi/lowlatency (22.04 LTS + 20.04 LTS
for specific HWE variants)
NFSD buffer overflow
anonymous VMA mapping issue discussed briefly last week
GPZ put out a very detailed blog post about how the PoC works for this
https://googleprojectzero.blogspot.com/2022/12/exploiting-CVE-2022-42703-bringing-back-the-stack-attack.html
[USN-5756-1] Linux kernel vulnerabilities [06:55]
8 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2022-3621
CVE-2022-3594
CVE-2022-3567
CVE-2022-3566
CVE-2022-3565
CVE-2022-3564
CVE-2022-3524
CVE-2022-42703
[USN-5757-1] Linux kernel vulnerabilities
9 CVEs addressed in Bionic (18.04 LTS)
CVE-2022-3621
CVE-2022-3594
CVE-2022-3567
CVE-2022-3566
CVE-2022-3565
CVE-2022-3564
CVE-2022-3524
CVE-2022-3239
CVE-2022-42703
[USN-5757-2] Linux kernel vulnerabilities
9 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2022-3621
CVE-2022-3594
CVE-2022-3567
CVE-2022-3566
CVE-2022-3565
CVE-2022-3564
CVE-2022-3524
CVE-2022-3239
CVE-2022-42703
[USN-5758-1] Linux kernel vulnerabilities
13 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM)
CVE-2022-43750
CVE-2022-40768
CVE-2022-3649
CVE-2022-3635
CVE-2022-3621
CVE-2022-3594
CVE-2022-3567
CVE-2022-3566
CVE-2022-3565
CVE-2022-3564
CVE-2022-3524
CVE-2022-3239
CVE-2022-42703
[USN-5756-2] Linux kernel (GKE) vulnerabilities
8 CVEs addressed in Focal (20.04 LTS)
CVE-2022-3621
CVE-2022-3594
CVE-2022-3567
CVE-2022-3566
CVE-2022-3565
CVE-2022-3564
CVE-2022-3524
CVE-2022-42703
[USN-5755-2] Linux kernel vulnerabilities
9 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS)
CVE-2022-3621
CVE-2022-3594
CVE-2022-3567
CVE-2022-3566
CVE-2022-3565
CVE-2022-3564
CVE-2022-3524
CVE-2022-42703
CVE-2022-43945
[USN-5759-1] LibBPF vulnerabilities [07:06]
5 CVEs addressed in Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-3606
CVE-2022-3534
CVE-2022-3533
CVE-2021-45941
CVE-2021-45940
2 different heap-based buffer overflows, 1 memory leak, 1 UAF and 1 NULL
pointer deref
[USN-5760-1, USN-5760-2] libxml2 vulnerabilities [07:19]
3 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-40304
CVE-2022-40303
CVE-2022-2309
2 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM) (first two above)
NULL ptr deref, double-free, OOB read due to an integer overflow when parsing
multigigabyte XML files
[USN-5761-1, USN-5761-2] ca-certificates update [07:37]
Affecting Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
Removal of the TrustCor CA cert - upstream Mozilla have marked this as
distrusted after 30th November - ie don’t trust anything signed by this CA
after that date - but there is no such functionality in ca-certificates to
mark something as distrusted after a particular date - so instead we have
removed it entirely so all things signed by TrustCor would now not be trusted
TrustCor appear to have very close ties (ie potentially the same owners) with
other companies who have built spyware and surveillance technologies
https://www.washingtonpost.com/technology/2022/11/30/trustcor-internet-authority-mozilla/
Looking at certificate transparency logs, appears to only be a few downstream
sites that would now be distrusted as a result - in particular a bunch of
dynamic DNS provider noip.com
Thanks to JanC in #ubuntu-security for discussing this with the team
[USN-5762-1] GNU binutils vulnerability [09:51]
1 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-38533
[USN-5764-1] U-Boot vulnerabilities
7 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2022-34835
CVE-2022-33967
CVE-2022-33103
CVE-2022-30767
CVE-2022-30790
CVE-2022-30552
CVE-2022-2347
[USN-5763-1] NumPy vulnerabilities
4 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
CVE-2021-41496
CVE-2021-41495
CVE-2021-34141
CVE-2021-33430
Goings on in Ubuntu Security Community
Mark Esler at UbuCon Asia 2022 [10:00]
UbuCon Asia 2022 is conference held in Asia focussing on Ubuntu, Linux and
F/OSS in general
First one was held last year as a fully virtual conference
This year was in person in Seoul, South Korea
Mark Esler from the Ubuntu Security team delivered the keynote address about
how Canonical does security maintenance for Ubuntu as well as advice for how
F/OSS projects can better handle security vulnerabilities and coordinate with
downstreams like Ubuntu to help keep all users of their software safe
Covers things like how we maintain stable versions of each package in a given
release and then backport fixes on top, how we handle any potential
regressions, how CVEs are (unfortunately) a normal part of software and some
common examples of different CVEs
How we handle disclosure of vulnerabilities
The process of how we do security updates in Ubuntu (patching, testing, releasing etc)
And then how upstream F/OSS projects can better handle security issues and
work with the security community
https://2022.ubucon.asia/sessions/keynote/
Slides including speaker notes
Video of the session is at https://youtu.be/N5nVSXV9Hbk?t=480 - Mark’s
presentation begins right at about 8 minutes in
Get in contact
[email protected]
#ubuntu-security on the Libera.Chat IRC network
ubuntu-hardened mailing list
Security section on discourse.ubuntu.com
@[email protected], @ubuntu_sec on twitter
14 min

About Ubuntu Security Podcast

From the publisher's feed

A fortnightly podcast talking about the latest developments and updates from the Ubuntu Security team, including a summary of recent security vulnerabilities and fixes as well as a discussion on some…

Share Ubuntu Security Podcast

Sign up to save your podcasts

Ubuntu Security Podcast

Ubuntu Security Podcast episodes

About Ubuntu Security Podcast