Groźne luki w runC umożliwiają ucieczkę z kontenerów Dockera i Kubernetesa (CVE-2025-31133, CVE-2025-52565, CVE-2025-52881) - Security Bez Tabu

Groźne luki w runC umożliwiają ucieczkę z kontenerów Dockera i Kubernetesa (CVE-2025-31133, CVE-2025-52565, CVE-2025-52881)

Wprowadzenie do problemu / definicja luki

Na początku listopada 2025 r. ujawniono trzy poważne podatności w runC – referencyjnej implementacji OCI wykorzystywanej m.in. przez Dockera, containerd i CRI-O. Każda z nich może prowadzić do pełnego przełamania izolacji kontenera i uzyskania dostępu do systemu-gospodarza (hosta) z uprawnieniami roota, głównie poprzez wymuszenie niebezpiecznych zapisów do plików w procfs. Łatki opublikowano w wersjach runC 1.2.8, 1.3.3 oraz 1.4.0-rc.3 i nowszych.

W skrócie

  • Trzy CVE: CVE-2025-31133, CVE-2025-52565, CVE-2025-52881.
  • Wspólny efekt: możliwość skierowania zapisu wykonywanego przez runC do „wrażliwych” plików w /proc (np. .../proc/sysrq-trigger), co otwiera drogę do eskalacji i ucieczki z kontenera.
  • Zakres: dotyczy praktycznie wszystkich linii runC stosowanych pod Linuksem (szczegóły wersji poniżej).
  • Status: dostępne aktualizacje; dystrybutorzy i chmury publikują obrazy z łatami (Ubuntu, Red Hat, Google COS, AWS EKS).

Kontekst / historia / powiązania

Zespół runC poinformował społeczność (kanały oss-security) o trzech podatnościach wysokiej wagi. W ciągu tego samego dnia wydano poprawione wydania (1.2.8/1.3.3/1.4.0-rc.3). Producenci dystrybucji Linuksa i dostawcy chmur zaczęli sukcesywnie wypychać aktualizacje obrazów node’ów Kubernetes i paczek systemowych.

Analiza techniczna / szczegóły luki

1) CVE-2025-31133 — nadużycie maskedPaths z /dev/null (maskowanie za pomocą bind-mount)

  • Mechanizm: runC maskuje wrażliwe ścieżki bind-mountem /dev/null nad docelowym plikiem.
  • Luka: jeśli atakujący podmieni /dev/null na dowiązanie symboliczne wskazujące na plik pod /proc, runC nie weryfikuje dostatecznie źródła i zamountuje cel symlinku RW – przez co uzyskuje się zapis do zabronionych plików procfs.
  • Zasięg: dotyczy wszystkich znanych wersji runC przed poprawką.

2) CVE-2025-52565 — błąd w bind-mouncie /dev/console

  • Mechanizm: podczas tworzenia /dev/console runC bind-montuje odpowiedni /dev/pts/$n do wnętrza kontenera.
  • Luka: wyścig i brak poprawnych sprawdzeń pozwalają na podmianę /dev/pts/$n na symlink — runC zamountuje wtedy nieoczekiwany cel nad /dev/console, zanim zostaną nałożone maskedPaths/readonlyPaths, otwierając furtkę do RW na krytycznych plikach.
  • Zasięg: od 1.0.0-rc3 w górę, obejmuje szerokie spektrum wydań.

3) CVE-2025-52881 — procfs write redirect i „gadżety zapisu” (arbitrary write)

  • Mechanizm: przy sprzyjających warunkach (m.in. wyścigi na współdzielonych montach), runC można nakłonić do przekierowania własnych zapisów do /proc na inne cele w procfs, de facto uzyskując dowolny zapis do niebezpiecznych plików.
  • Skutek uboczny: omijanie LSM re-labeling (np. AppArmor/SELinux) znane z wcześniejszych prac — ułatwia łańcuchowanie z 31133.
  • Zasięg: szeroki (dotyka wspieranych linii przed aktualizacją).

Wersje naprawione

  • runC 1.2.8, 1.3.3 i 1.4.0-rc.3 (i nowsze) zawierają łatki na wszystkie trzy CVE. Jeżeli korzystasz z Dockera/containerd/CRI-O, to po stronie hosta liczy się wersja binarki runC dostarczana przez system albo obraz node’a.

Praktyczne konsekwencje / ryzyko

  • Ucieczka z kontenera: możliwość nadpisania/zapisania do kluczowych wpisów procfs (/proc/sysrq-trigger, /proc/self/attr/..., itp.) umożliwia m.in. reset systemu, manipulacje bezpieczeństwem jądra czy obejście etykiet LSM — finalnie root na hoście.
  • Łańcuchowanie: 52881 może neutralizować warstwę LSM, co zwiększa skuteczność 31133.
  • Wejście w wektor przez pipeline’y buildowe: podatności da się wyzwalać podczas buildów (np. docker buildx) i przy niestandardowych konfiguracjach montowań — realne ryzyko dla CI/CD.
  • Brak exploitów 0-day w obiegu w momencie publikacji, ale wymagany jest natychmiastowy patch – powierzchnia ataku jest powszechna (runC jest „wszędzie”).

Rekomendacje operacyjne / co zrobić teraz

0. Szybka walidacja środowiska

Sprawdź, jaką wersję runC faktycznie uruchamia host/worker:

# na hoście
runc --version

# jeśli runc dostarcza dystrybucja:
dpkg -l | grep -E 'runc'            # Debian/Ubuntu
rpm -q runc                         # RHEL/CentOS/Fedora/SUSE

# containerd
ctr version | grep -i runc
crictl info | jq '.config.containerd.runtimes'

# Kubernetes node (przez SSH na worker)
kubelet --version

1. Aktualizacje (preferowane)

  • System/obrazy node’ów: zaktualizuj paczki runc/containerd lub przeprowizjonuj AMIs/OS images dla klastrów (EKS/AKS/GKE/COS ma już rollout z łatą).
  • Minimalne bezpieczne wersje runC: 1.2.8 / 1.3.3 / 1.4.0-rc.3 (lub nowsze).
  • Przykładowe ścieżki:
    • Ubuntu: sudo apt-get update && sudo apt-get install --only-upgrade runc (USN-7851-1).
    • RHEL/SUSE: sudo dnf update runc / zypper up runc (RHSA/SUSE advisory).
    • EKS: zaktualizuj node groups / wymuś rolling replace zgodnie z biuletynem AWS.
    • Google COS/GKE: dobierz najnowszy cos-stable z notatek wydania.

2. Dodatkowe twardnienie (gdy patch jeszcze w toku)

Poniższe nie zastępują aktualizacji, ale ograniczają ryzyko:

  • User Namespaces (bez mapowania hostowego UID 0): uruchamiaj kontenery z root-less lub z remapowaniem UID/GID – uniemożliwia wielu ścieżkom zapisu do procfs dzięki DAC.
  • Rootless Docker/Podman tam, gdzie to możliwe.
  • Ogranicz niestandardowe montowania w docker run, PodSpec i pipeline’ach buildowych (buildx) – polityki Admission Controller (OPA/Gatekeeper/Kyverno) blokujące hostPath, --mount, nieautoryzowane bind-mounty, SYS_ADMIN, CAP_SYS_ADMIN.
  • LSM / seccomp / AppArmor/SELinux: włączone profile to wciąż bariera, choć 52881 redukuje ich skuteczność – traktuj to jako warstwę „Defense in Depth”.
  • ReadOnlyRootFilesystem, no-new-privileges, drop większości capabilities; brak --privileged.
  • RBAC: zablokuj możliwość tworzenia podów z niestandardowymi montami przez nieuprawnionych deweloperów.

3. Wykrywanie i obserwowalność

  • Sygnatury EDR/eBPF/Falco pod kątem:
    • Podejrzanych symlinków w /dev/pts/* i podmian /dev/null podczas init kontenera.
    • Zapisów do plików /proc/ nietypowych dla workloadu (np. */proc/sysrq-trigger, */proc/*/attr/*).
  • Telemetria z auditd/BPF i korelacja z cyklem życia kontenerów. (Sysdig publikuje wskazówki detekcyjne oraz opis wektorów).

Przykładowa reguła Falco (szkic – dostosuj do środowiska):

- rule: Suspicious_Procfs_Write_From_Container
  desc: "Zapis do krytycznych plików procfs przez proces w kontenerze"
  condition: evt.type in (open,openat) and fd.name pmatch (
               "/proc/sysrq-trigger",
               "/proc/*/attr/*",
               "/proc/sys/kernel/*"
             ) and container and (evt.arg.flags & O_WRONLY != 0 or evt.arg.flags & O_RDWR != 0)
  output: "procfs write in container (user=%user.name proc=%proc.name file=%fd.name container=%container.id)"
  priority: CRITICAL
  tags: [container, mitre-privilege-escalation]

Różnice / porównania z innymi przypadkami

  • Historyczne analogie: 52881 to „bardziej wyrafinowany” następca problemów z LSM relabel obserwowanych wcześniej (np. CVE-2019-19921). Wspólny motyw to przekierowanie zapisów wykonywanych przez sam runtime, co omija klasyczne sandboxowe ograniczenia procesu w kontenerze.
  • Wobec CVE w Docker Desktop 2025 (SSRF/ECI): inna klasa – tam problem dotyczył środowiska desktop/WSL2 i API dockerd, tutaj mówimy o jądrze i procfs w runtime. (Wspólna nauka: aktualizacje toolchainu kontenerowego są krytyczne).

Podsumowanie / kluczowe wnioski

  • Te trzy CVE w runC to fundamentalne problemy izolacji kontenera; aktualizacja runC do 1.2.8/1.3.3/1.4.0-rc.3 (lub nowszej) powinna być traktowana jak pilny changerequest na wszystkich hostach/workerach.
  • Do czasu pełnego patcha: rootless/userns, blokady niestandardowych montów i wzmocnione monitorowanie procfs.
  • Zadbaj o pipeline’y buildowe (buildx) i obrazy bazowe node’ów w chmurach – wielu dostawców już publikuje zaktualizowane obrazy, ale rollout bywa rozłożony w czasie.

Źródła / bibliografia

  • BleepingComputer: przegląd i wersje naprawione (1.2.8/1.3.3/1.4.0-rc.3). (BleepingComputer)
  • GitHub (opencontainers/runc) – release notes z opisem trzech CVE i kontekstem technicznym. (GitHub)
  • NVD: karty CVE z opisem zakresu wersji i szczegółami (31133, 52565, 52881). (NVD)
  • Advisory/dystrybutorzy: Ubuntu USN-7851-1; Red Hat RHSA-2025:19927; Google COS release notes; AWS Security Bulletin (EKS). (Ubuntu)
  • Sysdig: analiza wektorów i wskazówki detekcyjne. (sysdig.com)