Kategoria: CVE

TL;DR

CVE‑2025‑52881 to luka w runc (>=1.0, dotyczy m.in. Docker/containerd/CRI‑O), która pozwala przekierować zapisy do /proc podczas startu nowego kontenera (wyścigi + współdzielone montowania). Skutkiem może być ominięcie etykiet LSM, zapis do niebezpiecznych plików procfs (np. core_pattern, sysrq-trigger), DoS hosta lub ucieczka z kontenera (ATT&CK T1611). Naprawiono w runc 1.2.8, 1.3.3, 1.4.0‑rc.3 – aktualizacja jest kluczowa.

Krótka definicja techniczna

W runc 1.2.7 / 1.3.2 / 1.4.0‑rc.2 atakujący może przekierować operacje zapisu runc do alternatywnych plików procfs poprzez zestaw wyścigów przy współdzielonych montowaniach (np. symlink w tmpfs), co umożliwia zarówno bypass LSM (zapisy do proc/self/attr/*), jak i semi‑dowolny zapis do plików /proc/sys/* (np. kernel/core_pattern), prowadząc do eskalacji/ucieczki lub DoS.

Gdzie występuje / przykłady platform

• Linux / kontenery OCI: Docker, containerd, CRI‑O (runc jako runtime).
• Kubernetes (K8s): klastry korzystające z runc na węzłach roboczych (w tym minikube/kind).
• Chmury: EKS/ECS/Fargate, AKS, GKE oraz Amazon Linux / Bottlerocket – dostawcy opublikowali zaktualizowane AMI/obrazy; AWS podkreśla brak ryzyka „cross‑customer”, ale rekomenduje aktualizacje.
• Środowiska buildów: Docker BuildKit / docker buildx build (równoległe uruchomienia z niestandardowymi mountami).

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

Mechanizm CVE‑2025‑52881. Runc podczas startu kontenera wykonuje różne zapisy do procfs (np. etykiety LSM w proc/self/attr/*, ustawienia sysctl w proc/sys/*). Przy odpowiednio przygotowanej sytuacji wyścigu z współdzielonymi montowaniami (shared mounts) atakujący może sprawić, że ścieżka docelowa zapisów „wskoczy” na inny plik procfs (m.in. przez symlink w tmpfs), co omija wcześniejsze zabezpieczenia (z 2019 r.) sprawdzające „czy to jest procfs”, bo przekierowanie dalej wskazuje na procfs – tylko nie ten plik. Dzięki temu można m.in.:

• Wyłączyć lub ominąć stosowanie LSM (AppArmor/SELinux) do procesu kontenera,
• Zapisać w /proc/sys/kernel/core_pattern i wykorzystać „kernel upcalls” do wykonania pomocy core dump na hoście,
• Zapisać do /proc/sysrq-trigger i wywołać awaryjne akcje jądra (DoS).

Klasa problemu łączy CWE‑363 (Race Condition enabling link following) i CWE‑61 (Symlink Following).

Konsekwencja w ATT&CK. To typowy wektor T1611: Escape to Host – ucieczka z kontenera do hosta, z potencjałem późniejszej persystencji i ruchu bocznego. MITRE wskazuje kontenery/ESXi/Linux/Windows jako platformy dla tej techniki (w tym kontekście dotyczy Linux/runc).

Wersje naprawione: runc 1.2.8 / 1.3.3 / 1.4.0‑rc.3 (wiele commitów + aktualizacja filepath-securejoin). Dystrybucje (Ubuntu, Amazon Linux/Bottlerocket) opublikowały pakiety i nowe AMI.

Artefakty i logi (tabela)

Detekcja (praktyczne reguły)

Sigma (Linux/auditd) — wykrycie „niebezpiecznych” zapisów do procfs przez runc/CRI:

title: Runc/CRI writes to dangerous procfs targets (CVE-2025-52881 class)
id: 6b7e7b7c-6a6f-4d2a-9d3b-52881d3f0cve
status: experimental
description: Detect runc/containerd/crio writing to procfs targets linked to container escape/DoS
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2025-52881
  - https://github.com/opencontainers/runc/security/advisories/GHSA-cgrx-mc8f-2prm
logsource:
  product: linux
  service: auditd
detection:
  syscall:
    syscall|contains:
      - open
      - openat
      - openat2
      - write
  proc_targets:
    name|contains:
      - "/proc/sysrq-trigger"
      - "/proc/sys/kernel/core_pattern"
    name|startswith:
      - "/proc/self/attr/"
      - "/proc/sys/"
  procs:
    exe|endswith:
      - "/runc"
      - "/containerd-shim-runc-v2"
      - "/crio"
  condition: syscall and procs and proc_targets
level: high
tags:
  - attack.t1611
  - cve.2025-52881

Splunk (SPL) – auditd + journald

(index=linux_audit OR sourcetype=linux:audit) ("type=SYSCALL" OR "SYSCALL=")
| rex field=_raw "exe=(?<exe>[^ ]+)"
| rex field=_raw "name=(?<name>[^ ]+)"
| search exe IN ("/usr/bin/runc","/usr/sbin/runc","/usr/bin/containerd-shim-runc-v2","/usr/bin/crio") 
| search name="/proc/sysrq-trigger" OR name="/proc/sys/kernel/core_pattern" OR name LIKE "/proc/self/attr/%"
| stats count min(_time) as first max(_time) as last by host exe name
| where count>0

KQL (Azure / Defender for Containers + K8s Audit)

// K8s audit: podejrzana propagacja montowań
KubeAudit
| where verb in ("create","update")
| where objectRef.resource == "pods"
| extend m = tostring(requestObject.spec.containers[0].volumeMounts)
| where m has "mountPropagation" and m has "Bidirectional"
| project TimeGenerated, userAgent, user.username, namespace=tostring(objectRef.namespace), pod=tostring(objectRef.name), requestObject

// Linux syslog z AMA: wzmianki o sysrq/core_pattern (proxy dla DoS/escape symptomów)
Syslog
| where ProcessName in~ ("runc","containerd-shim-runc-v2","crio")
| where SyslogMessage has_any ("sysrq-trigger","core_pattern","/proc/self/attr/")
| project TimeGenerated, Computer, ProcessName, SyslogMessage

AWS – CloudTrail (CLI/JMESPath) — heurystyka zmian definicji z mountami/tmpfs

Uwaga: CloudTrail nie rejestruje operacji wewnątrz kontenera. Poniższe służy do wykrywania zmian definicji z ryzykowną konfiguracją, które mogą ułatwić wyścigi z montowaniami.

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=RegisterTaskDefinition \
  --query "Events[?contains(CloudTrailEvent,'\"tmpfs\"') || contains(CloudTrailEvent,'\"mountPoints\"') || contains(CloudTrailEvent,'\"privileged\":true')].[EventTime,Username,Resources]"

Dla EKS: monitoruj rollouty AMI/NodeGroup po publikacjach AWS (patchowane runc w nowych AMI).

Elastic / EQL (Elastic Defend)

file where
  event.category == "file" and event.action in ("open","openat","write") and
  process.name in ("runc","containerd-shim-runc-v2","crio") and
  file.path regex~ """^/proc/(sysrq-trigger|sys/.*|self/attr/.*)"""

Heurystyki / korelacje

• Korelacja czasu: Pod/Task start → w ~sekundach pojawiają się zapisy do /proc przez runc → następnie nietypowe zdarzenia jądra (sysrq/panika) albo procesy na hoście uruchomione przez helpery kernela (rdzeń → core_pattern).
• Konfiguracje sprzyjające: mountPropagation: Bidirectional, nadużycia tmpfs/symlinków w łańcuchu build/run, kontenery uprzywilejowane w pipeline’ach.
• Łańcuchy z innymi lukami: 31133/52565 + 52881 (bypass LSM) → pełny container escape.

False positives / tuning

• Legalne zapisy runc do /proc/self/attr/* (etykietowanie LSM) – zwykle pojedyncze, na starcie. Ogranicz alerty do:
  • Listy docelowych plików: sysrq-trigger, core_pattern, inne proc/sys/* poza whitelistem;
  • Częstotliwości (burst > X w sekundę);
  • Kontekstu: nietypowe mount propagation / uprzywilejowany kontener / nieznany obraz.
• W środowiskach z narzędziami testowymi (np. chaos‑engineering) uwzględnij wyjątki czasowe.

Playbook reagowania (IR)

1. Triage & izolacja: cordon/drain węzła K8s z incydentem; w ECS – wycofaj dotknięte instancje/AMIs; odetnij od sieci segment management.
2. Weryfikacja wersji: sprawdź runc --version na węzłach; jeżeli <1.2.8/1.3.3/1.4.0‑rc.3 → patch ASAP.
3. Artefakty: zrzut /var/log/audit/audit.log, journalctl -k, logi containerd/CRI‑O, K8s audit.
4. Łowy zagrożeń: wyszukaj zapisy do core_pattern / sysrq-trigger; sprawdź, czy nie doszło do restarów/panik; poszukaj procesów hosta tworzących się bezpośrednio po starcie kontenera.
5. Eradykacja: odtwórz węzły na patchowanych AMI/obrazach (EKS/ECS/Bottlerocket/AL2023) i redeploy workloadów.
6. Utwierdzenie: egzekwuj PSS/Pod Security Standards; blokuj mountPropagation: Bidirectional; minimalne przywileje; eBPF/Falco policy dla procfs; rotation sekretów.
7. Retrospektywa: SCM/CI – kto zmienił definicje mountów/tmpfs? Wyciągnij wnioski do „policy as code”.

Przykłady z kampanii / case studies

• TeamTNT / Hildegard / Peirates – historycznie obserwowano użycie uprzywilejowanych kontenerów, hostPath i innych wzorców prowadzących do Escape to Host (T1611); MITRE pokazuje te przykłady w procedurach techniki.

Uwaga: To analogiczne taktyki „ucieczki do hosta”, nie specyficzne exploity CVE‑2025‑52881.

Lab— przykładowe komendy

Wyłącznie w odizolowanym labie. Poniższe testy nie wykonują destrukcyjnych zapisów; służą jedynie do weryfikacji detekcji.

A. Ścieżka detekcyjna na procfs (bezpieczne cele)

# 1) Włącz auditd reguły (minimal): monitoruj open/write do procfs przez runc
sudo auditctl -w /proc/self/attr/ -p wa -k runc_proc_attr
sudo auditctl -w /proc/sys/ -p wa -k runc_proc_sys

# 2) Uruchom „zwykły” pod (minikube/kind) i obserwuj start – runc pisze do /proc/self/attr/*
#    Detektory powinny złapać pojedyncze, krótkie zapisy (baseline).

# 3) W kontenerze wykonaj bezpieczne odczyty/zapisy:
kubectl run test --image=alpine --restart=Never -- sh -c 'echo 0 >/proc/self/oom_score_adj; cat /proc/self/status >/dev/null; sleep 2'
#    (oom_score_adj na 0 — bezpieczne; brak sysrq/core_pattern!)

B. Heurystyka K8s: mountPropagation

# manifest (do testu reguł K8s-audit; NIE używać na prod)
apiVersion: v1
kind: Pod
metadata: { name: mp-test, namespace: default }
spec:
  containers:
  - name: c
    image: alpine
    command: ["sh","-c","sleep 60"]
    volumeMounts:
      - name: v
        mountPath: /mnt
        mountPropagation: Bidirectional     # <- trigger detekcji
  volumes:
  - name: v
    emptyDir: {}

Zastosuj i potwierdź, że KQL z sekcji 7 zwraca zdarzenie.

Mapowania (Mitigations, powiązane techniki)

Mitigations (MITRE ATT&CK):

• M1051 Update Software – aktualizuj runc/AMI/OS (naprawa: 1.2.8/1.3.3/1.4.0‑rc.3).
• M1048 Application Isolation & Sandboxing / PSS – ogranicz syscalle, blokuj uprzywilejowane kontenery i propagację montowań.
• M1038 Execution Prevention – obrazy minimalne, filesystem read‑only.
• M1026 Privileged Account Management – non‑root w kontenerach.

Powiązane techniki ATT&CK:

• T1611 Escape to Host (główna),
• T1190 Exploit Public‑Facing Application – typowy wektor dojścia do kontenera przed ucieczką.

Źródła / dalsza lektura

• MITRE ATT&CK T1611: Escape to Host – opis, wersja 1.6 (24.10.2025). (MITRE ATT&CK)
• NVD CVE‑2025‑52881 – opis, CVSS v4.0, lista commitów naprawczych. (NVD)
• GitHub Security Advisory (opencontainers/runc, GHSA‑cgrx‑mc8f‑2prm) – szczegóły techniczne, skutki, wersje fixed. (GitHub)
• runc releases 1.2.8 / 1.3.3 / 1.4.0‑rc.3 – noty wydania z informacją o 3 CVE. (GitHub)
• oss‑sec ogłoszenie (Aleksa Sarai) – 3 luki runc, łańcuchowanie z 31133/52565 i rola 52881 jako LSM bypass. (SecLists)
• Ubuntu CVE‑2025‑52881 / USN‑7851‑1 – status pakietów (wysoki priorytet). (Ubuntu)
• AWS Security Bulletin AWS‑2025‑024 – wpływ na EKS/ECS/Bottlerocket/AL2023 (brak ryzyka cross‑customer, aktualizacje AMI). (Amazon Web Services, Inc.)

Checklisty dla SOC / CISO

SOC

• Czy mamy sygnatury/audyt zapisu do procfs przez runc/CRI i K8s‑audit dla mountPropagation?
• Czy EKS/ECS/hosty mają aktualne AMI/obrazy z runc ≥1.3.3 (lub backport)?
• Baseline: typowy profil zapisów proc/self/attr/* na starcie kontenera – odstępstwa = alert.
• Korelować starty kontenerów z anomaliami jądra (sysrq/paniki/rebooty).
• Monitorować definicje podów/tasków pod kątem uprzywilejowania/propagacji montowań.

CISO / Platform

• Patch policy: runc/OS/AMI w 48h; roll‑back plan; skan statusu dystrybucji (Ubuntu/AL/… ).
• PSS/PSA: zakaz privileged, hostPID, mountPropagation: Bidirectional bez wyjątku.
• Runtime ochrony: eBPF (Falco/Tracee, Elastic Defend) z regułami na procfs.
• Bezpieczne buildy: kontrola docker buildx i mountów w pipeline; SBOM i image signing.
• Ćwiczenia IR: scenariusz container escape (ATT&CK T1611) w planie ćwiczeń.