CVE-2025-52565 — runc: ucieczka z kontenera przez montowanie /dev/console (race + symlink)

TL;DR

W runc (silnik OCI używany m.in. przez Docker, containerd, CRI‑O) występuje błąd sprawdzania podczas montowania /dev/pts/$n na /dev/console dla kontenerów z przydzielonym terminalem. Ze względu na wyścigi i śledzenie symlinków atakujący, który kontroluje konfigurację/obraz uruchamianego kontenera, może przekierować bind‑mount i uzyskać możliwość zapisu do chronionych plików w procfs (np. /proc/sysrq-trigger, /proc/sys/kernel/core_pattern), co w praktyce umożliwia DoS hosta lub ucieczkę na hosta. Luka dotyczy m.in. runc 1.0.0‑rc3–1.2.7, 1.3.0‑rc.1–1.3.2 oraz 1.4.0‑rc.1–rc.2; naprawiona w 1.2.8, 1.3.3 i 1.4.0‑rc.3. CVSS v4 (CNA): High (8.4).

---

Krótka definicja techniczna

CVE‑2025‑52565 to luka w runc, w której bind‑mount /dev/pts/$n → /dev/console wykonywany jest przed zastosowaniem maskedPaths/readonlyPaths. Przy niewystarczających walidacjach możliwe jest podstawienie symlinka i „nadpisanie” celu mountu ścieżką prowadzącą do wrażliwych plików procfs, co może skutkować eskalacją do ATT&CK T1611: Escape to Host.

---

Gdzie występuje / przykłady platform

• Linux (host): dystrybucje korzystające z runc (Docker/Containerd/CRI‑O).
• Kubernetes (AKS/EKS/GKE, on‑prem): każdy klaster, w którym runtime CRI używa runc; pod z tty: true może inicjować wadliwy montaż konsoli.
• Chmury (AWS/EKS/ECS): AWS potwierdził wpływ nowych luk runc na uruchamianie nowych kontenerów; brak ryzyka między‑klienckiego w usługach zarządzanych (izolacja nie opiera się o kontenery jako granicę bezpieczeństwa).
• Dystrybucje (Ubuntu/SUSE itd.): doradztwa bezpieczeństwa publikują statusy i aktualizacje pakietów runc.

---

Szczegółowy opis techniki (jak działa, cele, dlaczego skuteczna)

Podczas inicjalizacji kontenera z terminalem runc bind‑mountuje „slave” pty (/dev/pts/$n) pod /dev/console. Przed zaaplikowaniem maskedPaths/readonlyPaths dochodzi do okna czasu, w którym atakujący może podmienić źródło na symlink wskazujący docelowo na ścieżki w procfs. Efekt: zapisy do plików typu /proc/sysrq-trigger (natychmiastowe działania systemowe → DoS) bądź modyfikacja /proc/sys/kernel/core_pattern (przekierowanie core dumpów do programu — wektor eskalacji/persistencji). Łańcuch jest koncepcyjnie podobny do CVE‑2025‑31133, lecz dotyczy innego etapu montowania konsoli. Błąd naprawiono, dodając m.in. walidacje inode, bezpieczne ponowne otwieranie ścieżek i wsparcie TIOCGPTPEER.

Zakres wersji: 1.0.0‑rc3–1.2.7, 1.3.0‑rc.1–1.3.2, 1.4.0‑rc.1–rc.2 → fixed: 1.2.8, 1.3.3, 1.4.0‑rc.3. CWE: 61 (symlink following) oraz 363 (race enabling link following). CVSS v4 (CNA GitHub): 8.4 High (na NVD brak jeszcze własnej oceny). Uwaga: w opisie GHSA pojawia się alternatywna ocena 7.3 High; różnice wynikają z aktualizacji metryk przez źródła.

---

Artefakty i logi (co zbierać)

Źródło	Artefakt / log	Na co patrzeć	Uwagi
Linux auditd	SYSCALL=mount (MS_BIND), open/openat → ścieżki w /proc/sys*, /proc/sysrq-trigger	Próby zapisu/otwarcia do ww. plików z procesów uruchamianych w cgroupach kontenerowych (/kubepods/, /docker/, /containerd/).	Wysoka wartość dowodowa w korelacji z utworzeniem nowego kontenera.
Sysmon for Linux	EID 11 (FileCreate), EID 1 (ProcessCreate)	Tworzenie/zapis do /proc/sys/kernel/core_pattern lub akcji na /proc/sysrq-trigger; łańcuch procesów wskazujący na runc, containerd-shim, dockerd.	Wymaga właściwego mapowania pól.
K8s audit	create Pod/Container	spec.containers[].tty=true lub stdin=true dla obrazów z niskim zaufaniem; nagłe serie interaktywnych podów.	Warto mieć polityki OPA/Gatekeeper zakazujące TTY w produkcji.
Docker/containerd	dzienniki demona	Utworzenie z Config.Tty=true (Docker) lub WithTTY=true (containerd).	Pola zależne od journald/syslog.
AWS CloudTrail / CloudWatch Logs (EKS/ECS)	RegisterTaskDefinition	containerDefinitions[].pseudoTerminal=true (ECS)	Pole pseudoTerminal odpowiada --tty.
M365	—	[nie dotyczy]	N/D

---

Detekcja (praktyczne reguły)

Sigma (Linux/auditd) – zapis do krytycznych procfs z kontenera

title: Linux Procfs Write Indicative of Container Escape (CVE-2025-52565 family)
id: 8c2d8b38-6a6d-4ef0-9c43-52565a01
status: experimental
description: Wykrywa próby zapisu do /proc/sysrq-trigger lub /proc/sys/kernel/core_pattern wykonywane przez procesy działające w cgroupach kontenerowych.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2025-52565
  - https://github.com/opencontainers/runc/security/advisories/GHSA-qw9x-cqr3-wc7r
logsource:
  product: linux
  service: auditd
detection:
  selection_paths:
    (file.name|endswith):
      - "/proc/sysrq-trigger"
      - "/proc/sys/kernel/core_pattern"
  selection_syscalls:
    syscall|in:
      - open
      - openat
      - creat
      - write
  container_hint:
    cwd|contains:
      - "/docker/"
      - "/kubepods/"
      - "/containerd/"
  condition: selection_paths and selection_syscalls and container_hint
fields:
  - auid
  - exe
  - comm
  - cwd
  - uid
  - saddr
level: high
tags:
  - attack.t1611
  - cve.2025-52565

Splunk (SPL) – auditd → zapisy do procfs z przestrzeni kontenera

index=linux sourcetype=audit*
(| file IN ("/proc/sysrq-trigger","/proc/sys/kernel/core_pattern")
 OR msg IN ("/proc/sysrq-trigger","/proc/sys/kernel/core_pattern"))
 (syscall IN ("open","openat","creat","write"))
 (cwd="*kubepods*" OR cwd="*docker*" OR cwd="*containerd*")
| stats count min(_time) as first_seen max(_time) as last_seen by host exe comm uid file cwd

KQL (Azure/Microsoft Sentinel – Syslog lub AMA)

Syslog
| where ProcessName has_cs "runc" or ProcessName has_cs "containerd" or ProcessName has_cs "dockerd"
| where SyslogMessage has "/proc/sysrq-trigger" or SyslogMessage has "/proc/sys/kernel/core_pattern"
| where SyslogMessage has_any ("open","write","mount")

CloudTrail/CloudWatch Logs Insights – ECS task def z TTY

fields @timestamp, userIdentity.principalId, eventName, requestParameters.containerDefinitions
| filter eventSource = "ecs.amazonaws.com" and eventName="RegisterTaskDefinition"
| filter requestParameters.containerDefinitions like /"pseudoTerminal":\s*true/
| sort @timestamp desc

Elastic / EQL – pliki procfs

file where
  event.action in ("modification","open") and
  file.path in ("/proc/sysrq-trigger","/proc/sys/kernel/core_pattern") and
  process.container.id != null

---

Heurystyki / korelacje

• Nowy kontener z TTY (tty: true / pseudoTerminal: true) + w krótkim czasie próby zapisu do procfs.
• Nietypowe obrazy/źródła (rejestry spoza allowlist) + TTY + privileged: false (brak konieczności bycia privileged → sygnał zaskakujący).
• Zmiana core_pattern → koreluj z nagłą aktywnością debugerów/potoków na hoście.
• Seria nieudanych montowań (MS_BIND) z kontekstu runc w tym samym oknie czasowym co tworzenie pody/konternera.

---

False positives / tuning

• Automatyka hosta (configuration management) może legalnie modyfikować core_pattern (Ansible/Puppet/sysctl) — zwykle poza cgroupami kontenerów. Whitelistuj znane narzędzia/ścieżki exe.
• Sesje debug (kubectl exec -it) w środowiskach deweloperskich z TTY — oznacz jako low risk, jeśli obraz i namespace są zaufane.
• Agreguj tylko z kontenerów (process.container.id != null / ścieżka cgroup).

---

Playbook reagowania (SOC / Blue Team)

1. Identyfikacja
   • Alarm z reguł (powyżej) → zapisz host, container_id, image, pod, namespace, user.
   • Sprawdź wersję runtime: runc --version; crictl --version 2>/dev/null; docker info 2>/dev/null | grep -i 'runc\|containerd'
2. Tymczasowa izolacja
   • K8s: kubectl cordon <node> i kubectl drain <node> --ignore-daemonsets --delete-emptydir-data (jeśli incydent dotyczy węzła).
   • Zatrzymaj/podmroź podejrzane workloady: kubectl delete pod <pod> -n <ns> lub skaluj do zera.
3. Triage hosta
   • Zweryfikuj core_pattern i artefakty: cat /proc/sys/kernel/core_pattern dmesg --ctime | egrep -i 'sysrq|core_pattern' ausearch -f /proc/sysrq-trigger -ts recent
4. Łatanie
   • Zaktualizuj runc min. do 1.2.8/1.3.3/1.4.0‑rc.3 (wraz z restartem node). Sprawdź doradztwa dystrybucyjne (Ubuntu/SUSE).
5. Hardening
   • Włącz polityki: blokuj TTY w prod (OPA Gatekeeper „Disallow Interactive TTY”).
   • Wymuś readOnlyRootFilesystem, seccomp, ograniczenia capabilities, oraz deny‑listy hostPath.
6. Dowody/raport
   • Zachowaj logi: auditd, kube‑apiserver audit, journald (dockerd/containerd), CloudTrail.
   • IOC: obrazy, digests, namespace, użytkownik/API client.

---

Przykłady z kampanii / case studies

• Zbiorcze doradztwa AWS: trzy luki runc (CVE‑2025‑31133/52565/52881) — brak ryzyka cross‑tenant, zalecenia aktualizacji platform zależnych od runc.
• Analizy branżowe (Sysdig/ARMO): opisują wektory ucieczki przez procfs i praktyczne wskazówki detekcyjne w środowiskach kontenerowych.
• oss‑sec: ogłoszenie do vendorów o trzech poważnych lukach runc umożliwiających zapis do dowolnych plików /proc i full breakout.

---

Lab (bezpieczne testy) — przykładowe komendy

Wyłącznie w odizolowanym labie/VM, nie w produkcji. Celem jest weryfikacja detekcji i twardnienia, nie eksploatacja.

1. Weryfikacja wersji i polityk runc --version kubectl get psp,podsecuritypolicies 2>/dev/null || true
2. Uruchomienie kontrolowanej pracy z TTY (sygnał do telemetrii) kubectl run tty-demo --image=busybox --restart=Never --tty=true --stdin=true -- sh -c 'sleep 300' # Sprawdź w kube-audit/CloudTrail/ECS czy widać tty/pseudoTerminal=true
3. Walidacja reguł
   • Sprawdź, czy alerty NIE pojawiają się dla zwykłych kontenerów bez TTY.
   • Zasymuluj „niegroźne” odczyty procfs (bez zapisu), aby upewnić się, że reguły nie generują FP dla read‑only.
4. Hardening
   • Zastosuj OPA Gatekeeper k8sdisallowinteractivetty i sprawdź blokadę tworzenia podów z tty: true.

---

Mapowania (Mitigations, powiązane techniki)

• Mitigations (ATT&CK):
  • M1051 Update Software (aktualizacja runc)
  • M1048 Application Isolation and Sandboxing (seccomp, blokada mount, deny hostPath)
  • M1026 Privileged Account Management (brak root/privileged)
  • M1038 Execution Prevention (read‑only FS, minimalne obrazy)
• Techniki powiązane: T1068 Exploitation for Privilege Escalation (eksploitacja podatności w celu ucieczki), T1610 Deploy Container (wykorzystywanie specjalnie zbudowanego obrazu).

---

Źródła / dalsza lektura

• NVD: opis, zakres, wersje, CVSS, CWE. (NVD)
• GHSA opencontainers/runc (szczegóły techniczne, patchset, metryki). (GitHub)
• AWS Security Bulletin (EKS/ECS). (Amazon Web Services, Inc.)
• Ubuntu CVE tracker (opis dystrybucyjny). (Ubuntu)
• Sysdig: przegląd i detekcja dla trzech CVE runc. (sysdig.com)
• ARMO: omówienie skutków i zaleceń. (armosec.io)
• oss‑sec: zawiadomienie do vendorów. (seclists.org)
• MITRE ATT&CK T1611 Escape to Host (opis techniki, mitigacje). (MITRE ATT&CK)
• ECS pseudoTerminal (API). (AWS Documentation)

---

Checklisty dla SOC / CISO

SOC (operacyjnie):

• Włącz zbieranie auditd + kube‑audit + dzienniki runtime (docker/containerd) na węzłach.
• Aktywuj reguły detekcji dla zapisu do /proc/sysrq-trigger i /proc/sys/kernel/core_pattern z kontekstu kontenera.
• Koreluj tworzenie podów/kontenerów z TTY (tty: true / pseudoTerminal:true).
• Utrzymuj inventory wersji runc i sygnalizuj wersje < 1.2.8 / 1.3.3 / 1.4.0‑rc.3.
• Testuj polityki Gatekeeper blokujące TTY w prod.

CISO (strategicznie):

• Zleć natychmiastowe aktualizacje runc w całym łańcuchu (Docker/containerd/CRI‑O, node AMI).
• Wymuś standardy bezpieczeństwa kontenerów: brak privileged, brak hostPath do ///proc, seccomp/SELinux, RO‑rootfs.
• Wprowadź „no‑TTY‑by‑default” w produkcji oraz przegląd wyjątków.
• Ustal RTO/RPO dla incydentów kontenerowych i gotowość do cordon/drain węzłów.

---

Status ryzyka: High (CNA CVSS v4 8.4). Zastosuj aktualizacje runc (≥1.2.8/1.3.3/1.4.0‑rc.3) i polityki ograniczające TTY, a także zbieraj telemetrię z hostów i warstwy orkiestracji do korelacji zdarzeń.