Forum Discussion
DavidFernandes
Microsoft
Apr 16, 2024New Blog | eBPF-Powered Threat Protection using Inspektor Gadget
By Dor Serero
On February 20th, Microsoft Defender for Containers released its new sensor component, powered by Inspektor Gadget.
Inspektor Gadget is a Cloud Native Computing Foundation (CNCF) project that aims to change the way we consume and execute eBPF programs by managing its packing, deployment and execution. If you aren't familiar with eBPF, you can read more about it on ebpf.io, but in short – eBPF allows us to execute sandboxed programs that extends the Linux kernel without having to change it. In this post we will use eBPF to attach to a tracepoint event when a specific system call is made by a process.
Our new sensor uses Inspektor Gadget as its instrumentation layer - allowing us to collect events at the Kernel space and analyze them to provide security insights on workloads running in Kubernetes (insights include those from the host as well as at the container level).
This blog post will focus on how the Defender for Containers sensor leverages Inspektor Gadget applications running in Kubernetes by detecting vulnerabilities at runtime. We will first learn about a recent vulnerability and how we can exploit it at runtime. Then, we will see how Inspektor Gadget helps us to write an eBPF program that can detect this exploitation attempt.
A good way to understand the risks in running containers is to understand what "container escape" is. While some refer to containers as sandboxed or isolated processes, for linux-based container runtimes, this is an incorrect assumption. Container escape is when a malicious actor can breach the isolation boundaries of a container and gain access to the host. A good way to demonstrate container escape is to look at some known vulnerabilities. On January 31st, 2024, NIST published CVE-2024-21626, also known as "Leaky Vessels", a vulnerability in runc – the most popular "low-level" container runtime. This vulnerability is described as a way to "breakout through process.cwd trickery and leaked fds". The use of the word "trickery" here is both cool and terrifying. It means it's easy to demonstrate this (as we'll do in this blog post), but this also means it is really easy for attackers to use as well, hence the high severity score of this vulnerability. Without going into too much detail, this vulnerability relies on the fact that runc, prior to v1.1.12, doesn't close a "leaked" file descriptor in a timely manner when creating or executing commands inside the container, causing the container to inherit that file descriptor and gain access to the host filesystem.
Let’s start by building a simple go program that creates a symbolic link to the soon to be leaked file descriptor. Creating the symbolic link doesn’t require the file descriptor to be leaked when the container is instantiated.
package main
import (
"fmt"
"os"
"os/signal"
"syscall"
)
func main() {
// Create a symbolic link /host to /proc/self/fd/7
err := os.Symlink("/proc/self/fd/7", "/host")
if err != nil {
fmt.Println("Error creating symlink:", err)
return
}
exit := make(chan os.Signal, 1)
signal.Notify(exit, syscall.SIGINT, syscall.SIGTERM)
<-exit
}
Read the full post here: eBPF-Powered Threat Protection using Inspektor Gadget
No RepliesBe the first to reply