{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://cmaintz.github.io/tech-atlas/)"},"id":"platform/container-escape","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/platform/container-escape/","da":"https://cmaintz.github.io/tech-atlas/da/terms/platform/container-escape/"},"term":{"en":"Container escape","da":"Container escape"},"aka":{"en":["container breakout"],"da":["container breakout","udbrud fra container"]},"domain":["platform","security"],"cluster":"containers","layer":"host","status":"current","summary":{"en":"An attack where code running inside a container breaks out of it and gains control of the host machine beneath it.","da":"Et angreb, hvor kode, der kører i en container, bryder ud af den og får kontrol over værtsmaskinen nedenunder."},"body":{"formal":{"en":"A kind of privilege escalation in which a process inside a container uses a flaw in the kernel or container runtime, or a too loose setting, to act outside its container with the host's rights.","da":"En form for rettighedseskalering, hvor en proces i en container udnytter en fejl i kernen eller container-runtimen, eller en for løs indstilling, til at handle uden for sin container med værtens rettigheder."},"plain":{"en":"Like a guest in one hotel room who finds a loose wall panel and suddenly walks into the hotel's back office.","da":"Som en hotelgæst, der finder en løs vægplade på sit værelse og pludselig står på hotellets kontor."},"inPractice":{"en":"An attacker takes over a municipality's booking app, which runs in a container with full admin rights and the host's disks attached; one file written to the host lets them run code on the whole machine.","da":"En angriber overtager en kommunes bookingapp, der kører i en container med fulde administratorrettigheder og værtens diske tilkoblet; én fil skrevet direkte på værten lader angriberen køre kode på hele maskinen."},"whyItMatters":{"en":"Many teams treat containers as walls between customers or programs; one escape turns a single weak program into control of every container on the host.","da":"Mange teams bruger containere som skillevægge mellem kunder eller programmer; ét udbrud gør et enkelt svagt program til kontrol over alle containere på værten."}},"deepDive":{"en":"MITRE ATT&CK tracks the technique as T1611 (Escape to Host) under the Privilege Escalation tactic. Escapes fall into three families. Configuration escapes need no bug at all: a container started with --privileged (all capabilities, all devices, no seccomp or LSM profile) can mount the host's block device or load a kernel module; a bind-mounted /var/run/docker.sock or containerd socket lets the process ask the daemon to start a new privileged container with / mounted; hostPath volumes, hostPID or hostNetwork in a Kubernetes pod spec, or CAP_SYS_ADMIN on its own, open similar paths. The classic cgroup v1 release_agent trick (writing a host-path script into release_agent and triggering it when a cgroup empties) needs only CAP_SYS_ADMIN and a writable cgroupfs; CVE-2022-0492 showed a missing capability check made it reachable in some unprivileged setups.\n\nRuntime escapes exploit the low-level runtime that sets up the container. CVE-2019-5736 let a malicious image overwrite the host's runc binary through /proc/self/exe when an operator ran docker exec; CVE-2024-21626 (\"Leaky Vessels\") abused a file descriptor to the host filesystem that runc leaked into the container, reachable through a crafted WORKDIR of /proc/self/fd/N. Kernel escapes use any kernel bug reachable from inside the namespace: Dirty COW (CVE-2016-5195), Dirty Pipe (CVE-2022-0847) and CVE-2022-0185 (a heap overflow in filesystem context parsing that needed CAP_SYS_ADMIN, obtainable inside an unprivileged user namespace) are well-known examples.\n\nDefence is layered because no single control covers all three families. Kubernetes Pod Security Standards at the \"restricted\" level forbid privileged pods, host namespaces, hostPath and added capabilities, and require runAsNonRoot and a seccomp profile; admission controllers (Pod Security Admission, Kyverno, OPA Gatekeeper) enforce this. Keeping runc and the kernel patched closes known runtime and kernel paths; user namespaces make container root an unprivileged host user; read-only root filesystems remove persistence. For hostile multi-tenant workloads, gVisor or Kata Containers put a user-space kernel or a VM between the workload and the host kernel. Detection tools such as Falco watch for tell-tale syscalls: mounts, writes to release_agent, unexpected setns or shells spawned by runc.\n\nA container escape differs from ordinary privilege escalation inside the container (becoming root in the container is not yet an escape) and from a VM escape, which requires a hypervisor bug and is far rarer. After escaping, the attacker typically harvests kubelet credentials and service-account tokens of every pod on the node, which is how an escape turns into lateral movement across the cluster.","da":"MITRE ATT&CK beskriver teknikken som T1611 (Escape to Host) under taktikken Privilege Escalation. Udbrud falder i tre familier. Konfigurationsudbrud kræver slet ingen fejl: en container startet med --privileged (alle capabilities, alle enheder, ingen seccomp- eller LSM-profil) kan montere værtens blokenhed eller indlæse et kernemodul; en bind-monteret /var/run/docker.sock eller containerd-socket lader processen bede dæmonen starte en ny privilegeret container med / monteret; hostPath-volumener, hostPID eller hostNetwork i en Kubernetes-podspecifikation eller CAP_SYS_ADMIN alene åbner lignende veje. Det klassiske release_agent-trick i cgroup v1 (skriv et script på værten ind i release_agent og udløs det, når en cgroup bliver tom) kræver kun CAP_SYS_ADMIN og et skrivbart cgroupfs; CVE-2022-0492 viste, at et manglende capability-tjek gjorde det muligt i visse uprivilegerede opsætninger.\n\nRuntime-udbrud udnytter den lavniveau-runtime, der sætter containeren op. CVE-2019-5736 lod et ondsindet image overskrive værtens runc-binær via /proc/self/exe, når en operatør kørte docker exec; CVE-2024-21626 (\"Leaky Vessels\") udnyttede en fildeskriptor til værtens filsystem, som runc lækkede ind i containeren, og som kunne nås med et konstrueret WORKDIR på /proc/self/fd/N. Kerneudbrud bruger enhver kernefejl, der kan nås inde fra namespacet: Dirty COW (CVE-2016-5195), Dirty Pipe (CVE-2022-0847) og CVE-2022-0185 (et heap-overløb i fortolkningen af filsystemkontekst, som krævede CAP_SYS_ADMIN, der kan opnås i et uprivilegeret user namespace) er kendte eksempler.\n\nForsvaret skal være lagdelt, fordi ingen enkelt kontrol dækker alle tre familier. Kubernetes' Pod Security Standards på niveauet \"restricted\" forbyder privilegerede pods, værtens namespaces, hostPath og ekstra capabilities og kræver runAsNonRoot og en seccomp-profil; admission controllers (Pod Security Admission, Kyverno, OPA Gatekeeper) håndhæver det. Opdateret runc og kerne lukker kendte runtime- og kerneveje; user namespaces gør containerens root til en uprivilegeret bruger på værten; skrivebeskyttede rodfilsystemer fjerner persistens. Til fjendtlige workloads med flere lejere lægger gVisor eller Kata Containers en kerne i brugerrummet eller en VM mellem arbejdsbyrden og værtens kerne. Detektionsværktøjer som Falco holder øje med afslørende systemkald: mounts, skrivninger til release_agent, uventede setns-kald eller shells startet af runc.\n\nEt container escape adskiller sig fra almindelig rettighedseskalering inde i containeren (at blive root i containeren er endnu ikke et udbrud) og fra et VM-udbrud, der kræver en fejl i hypervisoren og er langt sjældnere. Efter udbruddet høster angriberen typisk kubelet-legitimationsoplysninger og service account-tokens fra alle pods på noden, og det er sådan, et udbrud bliver til lateral bevægelse gennem hele klyngen."},"edges":[{"type":"requires","to":"platform/container","confidence":"high","strength":"normal"},{"type":"requires","to":"platform/container-runtime","confidence":"high","strength":"normal"},{"type":"kind-of","to":"security/privilege-escalation","confidence":"high","strength":"normal"},{"type":"exploits","to":"security/vulnerability","why":{"en":"Breaking out depends on a flaw in the shared kernel or the runtime, or a setting that gives the container too many rights.","da":"At bryde ud afhænger af en fejl i den fælles kerne eller runtimen, eller en indstilling, der giver containeren for mange rettigheder."},"confidence":"high","strength":"primary"},{"type":"causes","to":"security/lateral-movement","why":{"en":"Control of the host gives access to its other containers and the logins they hold, opening the way to further systems.","da":"Kontrol over værten giver adgang til dens andre containere og de loginoplysninger, de har, hvilket åbner vejen til flere systemer."},"confidence":"medium","strength":"normal"}],"depth":5,"sources":[{"title":"NIST SP 800-190 - Application Container Security Guide","url":"https://csrc.nist.gov/pubs/sp/800/190/final","tier":"standard","publisher":"NIST"},{"title":"MITRE ATT&CK - Escape to Host (T1611)","url":"https://attack.mitre.org/techniques/T1611/","tier":"reference","publisher":"MITRE"}],"draft":true}