runc exe overwrite

When runc executes a process inside a container, the container can abuse the way runc re-executes itself through /proc/self/exe. A malicious image makes the entry process obtain a writable handle to the host runc binary and overwrites it, so the next container operation runs attacker code as root on the host.

2 phút đọccập nhật 7 thg 10, 2026florianamette1 người đóng góp
Hỏi trợ lý của bạn (MCP)Sửa trên GitHub

To create or enter a container, runc re-executes itself inside the container's namespaces using /proc/self/exe, a symlink the kernel maintains to the running executable, which here points at the host runc binary. The classic breakout abuses the moment the container's own code runs with a file descriptor path that still resolves to that host binary. A malicious image arranges for its entry process to open /proc/self/exe (the host runc) for writing, or to be a dynamic-loader or script shim that lets the container influence what runc re-executes, and overwrites the binary. Since runc runs as root on the host for every container lifecycle action, the overwritten binary executes attacker code as host root the next time any container is started or entered.

Confirm the runtime and version window:

bash
runc --version 2>/dev/null                  # pre-fix runc (older 1.0-rc line) is affected
readlink /proc/self/exe                     # resolves to the runtime binary during entry

Technique#

bash
# A malicious image ships an entrypoint that, when runc execs into it:
# 1. Opens /proc/self/exe, which still resolves to the host runc binary
# 2. Holds the descriptor until runc has dropped into the container, then
#    reopens it via /proc/self/fd/<n> for writing and overwrites the ELF
# 3. Writes a payload binary in place of runc
# Minimal shape of the entry payload:
exec 3< /proc/self/exe                       # fd to the host runc
# busy-wait until the fd is writable (runc has finished its exec), then:
cat payload_elf > /proc/self/fd/3            # overwrite host runc on disk

The next container create/start/exec on the host invokes the now-malicious runc, running the payload as root on the host.

Exploitation notes#

  • The attacker needs to run code in a container from an image or process they control; this is why it is a prime risk when a platform runs untrusted images or allows user-supplied exec.
  • Fixes make runc operate on a private, memory-backed copy of itself (a sealed memfd) so /proc/self/exe no longer resolves to the on-disk host binary; patched runtimes defeat the technique.
  • A successful overwrite affects every subsequent container operation on the host, so it is both an escape and a host-wide persistence mechanism.

References#

Trướcrunc and containerd exploitsTiếp Leaky Vessels