Skip to content

leodido/demo-cloud-native-ebpf-day

Repository files navigation

LSM BPF Changes Everything

This repository contains the code I used for the demo during my talk @ Cloud Native eBPF Day NA 2021.

Here you'll find the following eBPF programs:

restrict_connect
BPF LSM program (on socket_connect hook) that prevents any connection towards 1.1.1.1 to happen
audit_connect
program that shows BPF LSM for auditing (on socket_connect hook)
kprobe_connect
program that instruments a kprobe on the Kernel function (security_socket_connect) installing the socket_connect hook
trace_net
eBPF program for the net/net_dev_queue tracepoint
trace_connect
eBPF program tracing the entering of the connect syscall

Usage

First thing you'd need to clone this repository, isn't it?

git clone --recurse-submodules -j8 https://github.com/leodido/demo-cloud-native-ebpf-day.git

I guess you wanna now build this machinery. Cool!

Prerequisites

Wait a sec, here are some preconditions to get all of this demo working...

You need a BTF capable Kernel (Linux Kernel 4.18+).

To check whether you have a BTF enabled kernel run:

$ zcat /proc/config.gz | grep CONFIG_DEBUG_INFO_BTF=

Otherwise, you need to recompile you kernel with CONFIG_DEBUG_INFO_BTF=y: it's size will increase of ~1.5MB, not a big deal.

You need to install bpftool and clang.

On ArchLinux this is as easy as running:

$ sudo pacman -S bpf clang

If you also wanna try the BPF LSM programs, you need a Linux Kernel 5.7+ with BPF LSM on.

To check whether you have it enabled or not:

$ zcat /proc/config.gz | grep CONFIG_LSM=

Check if BPF hooks are enabled for LSM by looking at the output to contain them:

CONFIG_LSM="...,bpf"

Remember that BPF hooks for LSM can also be enabled via the lsm Kernel boot parameters, so take a look there too.

Also check your Kernel supports BPF LSM instrumentation with:

$ zcat /proc/config.gz | grep CONFIG_BPF_LSM=

Building

Ok, now you can move to the src directory. Here you'll find a nice Makefile to build all the things at once:

$ make

Or, one by one. For example:

$ make trace_net
$ make V=1 restrict_connect # in case you like to be verbose

Running

Now it's time to run 🏃

Wanna try to restrict connections towards 1.1.1.1? Try this:

$ sudo ./restrict_connect

Then, in another terminal:

$ curl https://1.1.1.1
$ ping 1.1.1.1

And observe the output!

Notice that all the other eBPF programs in this repo (so, except restrict_connect at the moment) work only against connections coming from executables which name is attack_connect.

This means they'll ignore connections generating from curl, etc.

Evaluation

One of the reasons because this repository (and its talk) exist was because I wanted to test an attack (CVE-2021-33505) that in some circumstances (ie., userfaultfd syscall enabled) is able to bypass security auditing tools based on tracepoints (that were not exactly made to accomplish this goal, but still...).

So, I wanted to verify which tracing implementations for the security context are vulnerable to this attack... And here we are. 🙃

Wanna know more about this attack? Watch this DEFCON talk by my friend Xiaofei Rex Guo.

Now, let's say that you wanna try the attack yourself targeting one of the eBPF programs here.

First, you'll need to verify whether you have the `userfaultfd` syscall...

$ zcat /proc/config.gz | grep CONFIG_USERFAULTFD

You'll also need to verify if it is enabled for unprivileged users (surprisingly, it is enabled for unprivileged users in many distro kernels).

$ cat /proc/sys/vm/unprivileged_userfaultfd

If /proc/sys/vm/unprivileged_userfaultfd is set to 0, for the sake of this experimentation set it to 1, like so:

$ sudo sysctl -w vm.unprivileged_userfaultfd=1

Now you should be able to doo you experimentations!

First, start an eBPF program of your choice...

Then, it's attack time:

$ pushd phantom-attack/phantom_v1/
$ make
$ popd
$ ./phantom-attack/phantom_v1/attack_connect

I also wrote a bash script to make these experimentations more straightforward.

Maybe, one day, I'll publish the results of such experimentations among different kernel releases, eBPF programs, etc.

Anyways, you can find it at experiment.sh in this repo and you can execute it by providing the number of times you want the attack to run (let's say 10?) and the eBPF program to target (let's say trace_connect?).

$ ./experiment.sh -i 100 -p trace_connect

Have fun!

~ Leo


Analytics