December 09, 2022

Episode 184

13 minutes

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

...more

View all episodes

By Ubuntu Security Team

4.8

1010 ratings