ucieczka z kontenera

Ucieczka z kontenera (container escape) to wykorzystanie podatności albo błędnej konfiguracji do wyjścia poza izolację kontenera i uzyskania dostępu do systemu operacyjnego hosta. NIST opisuje kontenery jako formę wirtualizacji na poziomie systemu operacyjnego, połączoną z pakowaniem oprogramowania aplikacji ^[7]. Wszystkie kontenery na jednym hoście dzielą więc to samo jądro. W katalogu MITRE ATT&CK ucieczka jest opisana jako technika T1611 „Escape to Host” w taktyce eskalacji uprawnień; atakujący wychodzi z kontenera, by dostać się do hosta, a przez niego do innych kontenerów ^[1].

Jak działa

Izolacja kontenera opiera się na mechanizmach jądra Linuksa. Dokumentacja Dockera wyjaśnia, że dzięki przestrzeniom nazw procesy w kontenerze nie widzą procesów innych kontenerów ani hosta, a tym bardziej nie mogą na nie wpływać ^[2]. Kontener startuje też z ograniczonym zestawem uprawnień jądra (capabilities), więc „root” w kontenerze ma znacznie mniej możliwości niż prawdziwy root ^[2]. Ucieczka polega na obejściu jednej z tych warstw.

Atak zwykle zaczyna się od przejęcia procesu w kontenerze, na przykład przez zdalne wykonanie kodu w aplikacji. Dopiero potem napastnik szuka drogi na zewnątrz. Typowy łańcuch pokazuje schemat poniżej.

RYS. 1Od aplikacji w kontenerze do hosta

Ostatni krok to ruch boczny (lateral movement): z hosta napastnik widzi pozostałe kontenery, ich dane i sekrety.

Odmiany

MITRE wymienia kilka dróg ucieczki ^[1]. Część wynika z konfiguracji, którą ktoś świadomie ustawił, część z błędów w oprogramowaniu.

Konfiguracja jest groźna, bo działa bez żadnej luki. Docker zaznacza, że pozwala współdzielić katalog między hostem a kontenerem bez ograniczania praw dostępu kontenera ^[2]. Z tego powodu tylko zaufani użytkownicy powinni mieć kontrolę nad demonem Dockera, który wymaga uprawnień roota ^[2]. Kubernetes w polityce Baseline zakazuje podów uprzywilejowanych, bo wyłączają większość mechanizmów bezpieczeństwa, a także współdzielenia przestrzeni nazw hosta i woluminów typu hostPath ^[3]. To klasyczna błędna konfiguracja zabezpieczeń.

W WordPressie

WordPress coraz częściej działa w kontenerach: u dostawców hostingu, w środowiskach budowanych na obrazach Dockera i na komputerach programistów. Narzędzie wp-env, służące do stawiania lokalnego WordPressa do budowy i testów wtyczek oraz motywów, domyślnie korzysta z Dockera ^[8].

Dla strony na WordPressie ucieczka z kontenera jest zwykle drugim etapem ataku. Pierwszym jest podatność we wtyczce albo w motywie, która pozwala wgrać webshell lub wykonać kod. Kontener ogranicza szkody do jednej instalacji, dopóki izolacja działa. Po ucieczce napastnik może sięgnąć do plików i baz innych stron na tym samym hoście. Dlatego ryzyko przypomina znane z hostingu współdzielonego, gdzie jedna przejęta strona zagraża sąsiadom.

W praktyce warto sprawdzić, czy kontener z WordPressem nie ma zamontowanego gniazda Dockera ani całych katalogów hosta i czy nie działa w trybie uprzywilejowanym. Te ustawienia bywają dodawane „dla wygody”, na przykład do automatycznych kopii albo narzędzi do zarządzania.

Zagrożenia i skutki

Według MITRE ucieczka może dać napastnikowi dostęp do hosta, a przez niego do innych kontenerów i zasobów ^[1]. W technice T1611 atakujący zyskuje uprawnienia wyższe niż w kontenerze, stąd przypisanie jej do eskalacji uprawnień ^[1]. Sekurak, opisując serię błędów Leaky Vessels, podsumował skutek jako możliwość „wyskoczenia” ze środowiska kontenera do systemu operacyjnego hosta, zwykle z uprawnieniami roota ^[5].

Skutki są tym większe, im więcej usług dzieli host. Jeden przejęty kontener może oznaczać wyciek sekretów wszystkich aplikacji, przejęcie potoku budowania obrazów albo całego klastra.

Jak się bronić

MITRE zaleca ograniczanie wywołań systemowych przez seccomp i Pod Security Standards, usuwanie zbędnych narzędzi z obrazów, kontenery tylko do odczytu, minimalne obrazy, uruchamianie bez roota i bieżące instalowanie poprawek ^[1]. Te zalecenia są zastosowaniem zasady najmniejszych uprawnień.

• Bez roota. Docker pozwala mapować roota w kontenerze na zwykłego użytkownika hosta przez przestrzenie nazw użytkowników, co ogranicza ryzyko ucieczki; funkcja istnieje od wersji 1.10, ale domyślnie jest wyłączona ^[2].
• Polityka podów. W Kubernetes profil Restricted odpowiada bieżącym dobrym praktykom utwardzania podów, a profil Privileged dopuszcza znane eskalacje uprawnień ^[3].
• Aktualne środowisko. Luki w runc i BuildKit usuwano poprawkami; dla CVE-2024-21626 poprawiona wersja runc to 1.1.12 ^[4]. Regularna łatka (patch) środowiska uruchomieniowego i jądra jest tak samo ważna jak aktualizacja aplikacji.
• Zaufane obrazy. Skanowanie obrazów kontenerów i budowanie tylko z zaufanych plików Dockerfile ogranicza ataki takie jak Leaky Vessels.

MITRE wskazuje też obszary wykrywania: nietypowe montowania woluminów, podejrzane uruchomienia kontenerów, nietypowe wywołania systemowe i nieoczekiwany dostęp do zasobów hosta ^[1].

Historia i przykłady

Leaky Vessels (2024). 31 stycznia 2024 roku opublikowano komunikat o CVE-2024-21626 w runc, ocenionym na 8,6 w skali CVSS ^[4]. Wyciek deskryptora pliku pozwalał nowemu procesowi uruchomionemu przez runc exec mieć katalog roboczy w systemie plików hosta; podatne były wersje od 1.0.0-rc93 do 1.1.11 ^[4]. Sekurak 8 lutego 2024 roku opisał całą serię odkrytą przez firmę Snyk: obok błędu w runc trzy luki w BuildKit, oznaczone jako CVE-2024-23651, CVE-2024-23652 i CVE-2024-23653 ^[5]. Wykorzystanie wymagało, by ofiara zbudowała lub uruchomiła złośliwy obraz albo Dockerfile, więc w grę wchodziła też socjotechnika ^[5].

Docker Desktop (2025). We wrześniu 2025 roku Sekurak opisał CVE-2025-9074 w Docker Desktop dla Windows ^[6]. Z wnętrza kontenera dostępne było API demona Dockera bez uwierzytelnienia; dwa żądania POST wystarczały, by utworzyć i uruchomić nowy kontener z zamontowanym katalogiem hosta ^[6]. Autorzy pokazali, że drogą do tego API może być nawet SSRF w aplikacji działającej w kontenerze, o ile pozwala wysyłać żądania POST ^[6].