It’s another week when too many security updates are never enough as we
cover 240 CVE fixes across Avahi, QEMU, the Linux kernel, containerd,
binutils and more, plus the Ubuntu 20.10 Groovy Gorilla end-of-life.
Show Notes
Overview
It’s another week when too many security updates are never enough as we
cover 240 CVE fixes across Avahi, QEMU, the Linux kernel, containerd,
binutils and more, plus the Ubuntu 20.10 Groovy Gorilla end-of-life.
Usual mix of vulns in emulation of various devices etc - generally allows
a malicious guest to cause QEMU to crash on the host -> DoS
MMIO, ATAPI, SCSI, ARM Generic Interrupt Controller, e1000
Mishandling in virtio-fs shared filesystem daemon allows malicious guest
to read/write host devices
A few others possibly result on code-exec on the host as the QEMU daemon
BUT on Ubuntu QEMU is confined via AppArmor by default so this limits the
possible impact
seq_file vuln - this virt file-system contained an unsigned integer
conversion error - would result in a local user being able to cause an
OOB write and hence possible code-exec in the kernel -> privesc
[USN-5015-1] Linux kernel (OEM) vulnerabilities [04:28]
When extracting a container image, would try and set the
owner/permissions on the resulting extracted files - if these files were
symlinks pointing to existing files on the host then would change perms
of those files instead - fixed to ensure it does not follow symlinks when
applying this permissions changes
When parsing mount paths, would allocate memory for the path on the
stack - if a local attacker can mount a file-system with a very long path
name, would overflow the entire stack memory and cause systemd to crash -
as systemd is PID1 this effectively crashes the whole system
Remote attacker could cause sytemd DHCP client to force assign a
different address and hence could cause a networking DoS against a remote
server on the same network by making it unroutable etc
binutils gets a lot of CVEs which are generally low priority -
ie. objdump could crash or get code-exec if run on untrusted input - but
since is installed in a lot of common developer scenarious we often get
requests about these CVEs - even though they are unlikely to actually be
able to be exploited in most scenarios
Thanks to Leo on our team (and Marc for the original backport of a lot of
these patches)