{"uuid": "e2089c92-4cdb-4377-96a7-9b4b2cbb9df8", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2019-5736", "type": "seen", "source": "https://t.me/hacking_Attack/34046", "content": "Kali Linux Tutorials\nWhoc : A Container Image That Extracts The Underlying Container Runtime\n\nWhoc is 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!\n\nHow does it work?\n\nAs shown by runc CVE-2019-5736, traditional Linux container runtimes expose themselves to the containers they\u2019re running through /proc/self/exe. whocuses this link to read the container runtime executing it.\n\nDynamic Mode\n\nThis is whocdefault mode that works against dynamically linked container runtimes.\n\n1. The whocimage entrypoint is set to /proc/self/exe, and the image\u2019s dynamic linker (ld.so) is replaced with upload_runtime.\n2. Once the image is run, the container runtime re-executes itself inside the container.\n3. Given the runtime is dynamically linked, the kernel loads our fake dynamic linker (upload_runtime) to the runtime process and passes execution to it.\n4. upload_runtimereads the runtime binary through /proc/self/exeand sends it to the configured remote server.\nhttps://blogger.googleusercontent.com/img/a/AVvXsEhoOtXTTgwAILo7_iVmwKDHiYFqUbdTTAaLwtkxF_o1uEl7cVjxgpPyycB1hmrcJSoO90Y4AtQLloD-nlpUfcurdePCzt5E-Za6ZryJW_LfFnAViUjIOVrhRxo0ggi0HDzk8rx5xJ3puaZ94h7wElqjr0Ei2xDYrIVBlfjrUN-g425lpMXY4pY5DD3d=s728 \nWait-For-Exec Mode\n\nFor statically linked container runtimes, whoccomes in another flavor: whoc:waitforexec.\n\n1. upload_runtimeis the image entrypoint, and runs as the whoccontainer PID 1.\n2. The user is expected to exec into the whoccontainer and invoke a file pointing to /proc/self/exe(e.g. docker exec whoc_ctr /proc/self/exe).\n3. Once the exec occurs, the container runtime re-executes itself inside the container.\n4. upload_runtimereads the runtime binary through /proc/$runtime-pid/exeand sends it to the configured remote server.\nhttps://blogger.googleusercontent.com/img/a/AVvXsEi3a_UpD_rXLfW9moPrDkZzlJOXXYrKnldu3IW_BpKgXSHTWzA2Efb8KtZx97cwQ8GasivuxnMs5vrYUYOgK8WE_FQ6ErQp_5t0Ykff-b2qMNl9Kzsn2j2dm3K2AoNGm_CS-EF4Q6NPJ5086YaoPXUJJtVZM9pLx43xRy04KhKoCiR92O8Y03DJUyFI=s571 \nTry Locally\n\nYou\u2019ll need dockerand python3installed. Clone the repository:\n$ git clone git@github.com:twistlock/whoc.git \nSet up a file server to receive the extracted container runtime:\n$ cd whoc\n$ mkdir -p stash && cd stash\n$ ln -s ../util/fileserver.py fileserver \n$ ./fileserver \nFrom another shell, run the whocimage in your container environment of choice, for example Docker:\n$ cd whoc\n$ docker build -f Dockerfile_dynamic -t whoc:latest src  # or ./util/build.sh\n$ docker run --rm -it --net=host whoc:latest 127.0.0.1  # or ./util/run_local.sh \nSee that the file server received the container runtime. If you run whocunder vanilla Docker, the received container runtime should be runc. --net=hostis only used in local tests so that the whoccontainer could easily reach the fileserver on the host via 127.0.0.1.\n\nOther Platforms\n\nBy default whocis built for linux/amd64, but it also supports other CPU architectures. Wait-for-exec mode can be built as usual. To build whocin dynamic mode for other CPU architectures, you must populate the PLATFORM_LD_PATH_ARGbuild argument with the path of the dynamic linker on the target architecture.\n\nAn example build script for arm64is available at util/build_arm64.sh.\n\nHelp\n\nHelp for whoc\u2018s main binary, upload_runtime:\nUsage: upload_runtime [options] ___________________________ \n@hacking_Attack\n@Hacking_Video", "creation_timestamp": "2026-09-01T20:02:07.587533Z"}