PLAY PODCASTS
Episode 203

Episode 203

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.

Ubuntu Security Podcast · Ubuntu Security Team

July 21, 202317m 21s

Audio is streamed directly from the publisher (people.canonical.com) as published in their RSS feed. Play Podcasts does not host this file. Rights-holders can request removal through the copyright & takedown page.

Original episode page

Show Notes

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)

[USN-6222-1] Linux kernel (Xilinx ZynqMP) vulnerabilities (02:13)

[USN-6223-1] Linux kernel (Azure CVM) vulnerabilities (02:25)

[USN-6224-1, USN-6228-1] Linux kernel vulnerabilities (02:36)

[USN-6231-1] Linux kernel (OEM) vulnerabilities (02:53)

[USN-6235-1] Linux kernel (OEM) vulnerabilities (03:17)

[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)

[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)

[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)

[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

← All episodes of Ubuntu Security Podcast