{"uuid": "9584d8ca-2e31-4410-8bb2-e48949a83eee", "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/32544", "content": "A container (https://www.kitploit.com/search/label/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 (https://www.youtube.com/watch?v=DF0qoCsHKT4)Azurescape (https://unit42.paloaltonetworks.com/azure-container-instances/) - whoc-powered research, the first cross-account container takeover (https://www.kitploit.com/search/label/Takeover) in the public cloud (70,000$ bounty)\nHow does it work?\nAs shown by runc CVE-2019-5736 (https://unit42.paloaltonetworks.com/breaking-docker-via-runc-explaining-cve-2019-5736/), traditional Linux container runtimes expose themselves to the containers (https://www.kitploit.com/search/label/Containers) they're running through /proc/self/exe. whoc uses this link to read the container runtime executing it.\nDynamic Mode\nThis is whoc default mode that works against dynamically linked container runtimes.The whoc image entrypoint is set to /proc/self/exe, and the image's dynamic (https://www.kitploit.com/search/label/Dynamic) linker (ld.so) is replaced with fake_ld.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 to the runtime process and passes execution to it.fake_ld obtains a file descriptor for the runtime binary by opening /proc/self/exe, and executes upload_runtime.upload_runtime reads the runtime binary from /proc/self/fd/ and sends it to the configured remote server.\n\n___________________________ \n@hacking_Attack\n@Hacking_Video", "creation_timestamp": "2026-09-01T20:02:08.578607Z"}