whoc: extracts the underlying container runtime
A container image that extracts the underlying container runtime and sends it to a remote server. Poke at the underlying container runtime of your favorite CSP container platform!
- WhoC at Defcon 29 Cloud Village
- Azurescape – whoc-powered research, the first cross-account container takeover in the public cloud
How does it work?
As shown by runc CVE-2019-5736, traditional Linux container runtimes expose themselves to the containers they’re running through /proc/self/exe. whoc uses this link to read the container runtime executing it.
This is whoc default mode that works against dynamically linked container runtimes.
- The whoc image entrypoint is set to /proc/self/exe
- The image’s dynamic linker (ld.so) is replaced with upload_runtime
- Once the image is run, the container runtime re-executes itself inside the container
- Given the runtime is dynamically linked, the kernel loads our fake dynamic linker (upload_runtime) to the runtime process and passes execution to it.
- upload_runtime reads the runtime binary through /proc/self/exe and sends it to the configured remote server
For statically linked container runtimes, whoc comes in another flavor: whoc:waitforexec.
- upload_runtime is the image entrypoint, and runs as the whoc container PID 1
- The user is expected to exec into the whoc container and invokes a file pointing to /proc/self/exe (e.g. docker exec whoc_ctr /proc/self/exe)
- Once the exec occurs, the container runtime re-executes itself inside the container
- upload_runtime reads the runtime binary through /proc/$runtime-pid/exe and sends it to the configured remote server
Copyright (c) 2021 Twistlock