Sign up to save your podcasts
Or
Share Episode 203
Share to email
Share to Facebook
Share to X
Share to email
Share to Facebook
Share to X
Or
Episode 203
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)
[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)
network driver
[USN-6235-1] Linux kernel (OEM) vulnerabilities (03:17)
[USN-6219-1] Ruby vulnerabilities (03:32)
[USN-6216-1] lib3mf vulnerability (04:09)
[USN-6225-1] Knot Resolver vulnerability (04:14)
server to return large address sets - fixed by adding a limit to various lookups etc
[USN-6226-1] SciPy vulnerabilities (04:45)
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)
[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)
buffer overflow when handling inputs larger than 2GB
[USN-6236-1] ConnMan vulnerabilities (07:33)
(info leak) - requires an attacker to run a malicious DHCP server - think
public wifi etc
[USN-6237-1] curl vulnerabilities (08:45)
particular could match a punycode-encoded IDN against an ascii wildcard of x*
as punycode names always start with xn--
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.
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)
libpam to steal credentials
kernel using user-level return probe
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.
the functions - but this requires that binaries get executed with this
environment set so is harder to achieve
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
just looking at the contents of /sys/kernel/debug/tracing/uprobe_events -
which lists all the uretprobes currently in use on the system
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
monitoring / instrumentation to detect malware - ie. using an eBPF program to
detect malicious use of eBPF
/ untrusted users and use seccomp or similar (via systemd units) to restrict
the use of eBPF to only those applications which really need it
which already has access to eBPF - ie. the kernel itself or a privileged
process - ie. reducing the attack surface
Get in contact
View all episodes
By Ubuntu Security Team
4.8
1010 ratings
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)
[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)
network driver
[USN-6235-1] Linux kernel (OEM) vulnerabilities (03:17)
[USN-6219-1] Ruby vulnerabilities (03:32)
[USN-6216-1] lib3mf vulnerability (04:09)
[USN-6225-1] Knot Resolver vulnerability (04:14)
server to return large address sets - fixed by adding a limit to various lookups etc
[USN-6226-1] SciPy vulnerabilities (04:45)
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)
[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)
buffer overflow when handling inputs larger than 2GB
[USN-6236-1] ConnMan vulnerabilities (07:33)
(info leak) - requires an attacker to run a malicious DHCP server - think
public wifi etc
[USN-6237-1] curl vulnerabilities (08:45)
particular could match a punycode-encoded IDN against an ascii wildcard of x*
as punycode names always start with xn--
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.
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)
libpam to steal credentials
kernel using user-level return probe
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.
the functions - but this requires that binaries get executed with this
environment set so is harder to achieve
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
just looking at the contents of /sys/kernel/debug/tracing/uprobe_events -
which lists all the uretprobes currently in use on the system
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
monitoring / instrumentation to detect malware - ie. using an eBPF program to
detect malicious use of eBPF
/ untrusted users and use seccomp or similar (via systemd units) to restrict
the use of eBPF to only those applications which really need it
which already has access to eBPF - ie. the kernel itself or a privileged
process - ie. reducing the attack surface
Get in contact