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...

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

$ sudo pacman -S bpf clang

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

CONFIG_LSM="...,bpf"

$ 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.

$ zcat /proc/config.gz | grep CONFIG_USERFAULTFD

$ cat /proc/sys/vm/unprivileged_userfaultfd

$ 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