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 thesocket_connect
hook - trace_net
- eBPF program for the
net/net_dev_queue
tracepoint - trace_connect
- eBPF program tracing the entering of the
connect
syscall
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!
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=
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
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.
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