I blooded the chal :) with a cheese strat way easier than intended challenge01-dist.tgz
We’re provided a rootfs and tcp connection info which gets us a shell.
Examining the rootfs and connecting to the shell the general structure of the challenge becomes clear.
We connect into a shell inside a docker container. This docker container is running inside a systemd nspawn container. This nspawn container is running inside an arch vm and the flag is present in /flag.txt inside the top level vm.
We’ll need to do two container escapes — first from docker to nspawn and then from nspawn to the top level. I’ll first examine the docker container for any security-relevant configuration.
Capabilities are more or less uninteresting — default and nothing that can be leverage to break out. Looking inside the container config though shows something very suspicious — that /root is mounted as a volume inside the container.
Following up on that shows that we have write access to root’s .ssh directory, sshd is running on the host, and the host and docker container are networked together. After fighting for a long time with the IO, I managed to get dropbear on inside the container and confirmed I could ssh up a level.
Looking at the config shows we are explicitly allowed to invoke add_key, keyctl, or bpf syscalls inside the container.
I know the author well enough to know that the intended solution is bpf fuckery (with the bpf syscall and cap_sys_admin) but I don’t know bpf well and didn’t want to do that. Fortunately for me, cap_sys_admin is an unreasonably powerful capability and there are other routes.
Systemd, by default, mounts procfs and sys as read-only. It does not prevent a user with the appropriate (and default) capabilities from mounting procfs again r/w. Once you have write access to procfs it’s trivial to escalate privileges by modifying core_pattern.