Overview
This week we talk about the dual use purposes of eBPF - both for security and
for exploitation, and how you can keep your systems safe, plus we cover security
updates for the Linux kernel, Ruby, SciPy, YAJL, ConnMan, curl and more.
This week in Ubuntu Security Updates
80 unique CVEs addressed
[USN-6220-1] Linux kernel vulnerabilities (00:50)
[USN-6234-1] Linux kernel (Xilinx ZynqMP) vulnerability (01:20)
- 1 CVEs addressed in Focal (20.04 LTS)
- 5.4 Xilinux ZynqMP platform
[USN-6221-1] Linux kernel vulnerabilities (01:32)
- 7 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM)
- 4.4 Xenial ESM, Trusty ESM LTS Xenial
- AWS, KVM, Generic, Low latency
[USN-6222-1] Linux kernel (Xilinx ZynqMP) vulnerabilities (02:13)
- 31 CVEs addressed in Focal (20.04 LTS)
[USN-6223-1] Linux kernel (Azure CVM) vulnerabilities (02:25)
- 9 CVEs addressed in Jammy (22.04 LTS)
[USN-6224-1, USN-6228-1] Linux kernel vulnerabilities (02:36)
- 2 CVEs addressed in Lunar (23.04)
- 6.2 Oracle, Azure, GCP, IBM, Raspi, AWS, KVM, Low latency
[USN-6231-1] Linux kernel (OEM) vulnerabilities (02:53)
- 5 CVEs addressed in Jammy (22.04 LTS)
- 6.1 OEM
- OOB write due to uninitialized memory in packet control buffer for IP-VLAN
network driver
[USN-6235-1] Linux kernel (OEM) vulnerabilities (03:17)
- 8 CVEs addressed in Jammy (22.04 LTS)
- 6.0 OEM
- Flower, missing lock in
io_uring
[USN-6219-1] Ruby vulnerabilities (03:32)
- 2 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10), Lunar (23.04)
- ReDoS in URI parser - only one issue really but fix for first was incomplete
[USN-6216-1] lib3mf vulnerability (04:09)
- 1 CVEs addressed in Focal (20.04 LTS)
- UAF
[USN-6225-1] Knot Resolver vulnerability (04:14)
- 1 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
- CPU-based DoS due to high algorithmic complexity - requires an authoritative
server to return large address sets - fixed by adding a limit to various lookups etc
[USN-6226-1] SciPy vulnerabilities (04:45)
- 2 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
- 2 issues in reference count handling - both appear to be disputed by
upstream - first, as it would only be able to triggered by first
deterministicly exhausting memory, the other since the only way to trigger it
would be to first be able to execute arbitrary Python code. Both were reported
by the same user who discovered them via static analysis
[USN-6227-1] SpiderMonkey vulnerabilities (05:47)
- 2 CVEs addressed in Jammy (22.04 LTS), Kinetic (22.10), Lunar (23.04)
- mozjs102 (102.13.0) - memory mishandling in JS engine
[USN-6229-1] LibTIFF vulnerabilities (06:00)
- 4 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM)
- 2 heap buffer overflows, one OOB read, one NULL ptr deref
[USN-6230-1] PostgreSQL vulnerability (06:24)
[USN-6184-2] CUPS vulnerability (06:34)
[USN-6078-2] libwebp vulnerability (06:43)
[USN-6183-2] Bind vulnerability (06:46)
[USN-6233-1] YAJL vulnerabilities (06:56)
- 3 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM)
- Yet Another JSON library - used by i3, mpd, uwsgi, modsecurity, libvirt and others
- Memory leak, buffer overflow on unicode parsing, integer overflow -> heap
buffer overflow when handling inputs larger than 2GB
[USN-6236-1] ConnMan vulnerabilities (07:33)
- 9 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Lunar (23.04)
- a number of issues in internal gdhcp client - stack buffer overflow, OOB read
(info leak) - requires an attacker to run a malicious DHCP server - think
public wifi etc
- UAF in WISPR HTTP handling (MiTM)
- Heap buffer overflow gweb component - RCE
- 2 different OOB read in DNS proxy component - crash / info leak
- Also an infinite loop in DNS proxy
[USN-6237-1] curl vulnerabilities (08:45)
- 3 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10), Lunar (23.04)
- Improperly matched wildcard patterns when doing certificate validation - in
particular could match a punycode-encoded IDN against an ascii wildcard of
x*
as punycode names always start with xn--
- Logic error where would use the read callback to ask a remote client to ask
for data to send even if the same handle had been used previously for a PUT
request - unexpected behaviour for applications using curl, so could result in
potentially sending the wrong data (info leak) or a UAF etc.
- Race condition on fopen() - used to save cookies etc to files - would first
check that file is a real file before opening - local attacker could race to
say replace it with a symlink instead to then get cookies written to a
different file etc.
The dual use of eBPF as both a tool for malware and a tool for detecting malware (10:34)
- Interesting write-up on the use of eBPF by malware authors for hooking into
libpam to steal credentials
- pamspy - uses eBPF uprobes - way of hooking into userspace functions from the
kernel using user-level return probe
- requires to be root in the first place to be able to create a uretprobe
through
/sys/kernel/debug/tracing/uprobe_events
but once done, allows to then
have a BPF program executed every time the specified function within a
specified library / binary is executed - so by hooking libpam can then log the
credentials used by any user when logging in / authenticating for sudo etc.
- More traditional approach would have been to use say
LD_PRELOAD
to hook into
the functions - but this requires that binaries get executed with this
environment set so is harder to achieve
- But uretprobes have their own problems - implementation is based on
breakpoints so potentially be detected by the program which is being traced by
examining its own code (
.text
section) to look for breakpoint opcode (0xCC
) or
it could look for the special memory mapping [uprobes]
in /proc/self/maps
- Potentially more easy to find that they are being used on a system as well by
just looking at the contents of
/sys/kernel/debug/tracing/uprobe_events
-
which lists all the uretprobes currently in use on the system
- Interesting to see that (not surprisingly) each new technology can be used in
multiple ways - BPF+uprobes is a great way to do tracing of userspace code for
developers / sysadmins etc when debugging - but is also a great way for
malware authors to do the same
- Also interesting to see the aquasec team mention the use of eBPF for system
monitoring / instrumentation to detect malware - ie. using an eBPF program to
detect malicious use of eBPF
- but perhaps the best solution is to disable the use of eBPF by unprivileged
/ untrusted users and use seccomp or similar (via systemd units) to restrict
the use of eBPF to only those applications which really need it
- then the only way for malware to use eBPF would be to compromise something
which already has access to eBPF - ie. the kernel itself or a privileged
process - ie. reducing the attack surface
Get in contact