Podatność w implementacji CRI w containerd pozwala użytkownikowi z uprawnieniami do tworzenia podów na ominięcie standardowych mechanizmów alokacji zasobów Kubernetes poprzez manipulację metadanymi obrazu checkpoint. Może to skutkować nieautoryzowanym dostępem do urządzeń hosta i montowaniem zasobów w przywracanym kontenerze.
▸ Pokaż oryginał (EN)
containerd is an open-source container runtime. In Versions prior to 2.3.2, 2.2.5 and 2.1.9, the CRI implementation improperly trusts Container Device Interface (CDI) annotations found within untrusted checkpoint image metadata during container restoration. When restoring a container from a checkpoint, containerd preserves CDI-related annotations from the checkpoint archive rather than relying solely on the pod's create-time specification. This allows a user with pod creation permissions to bypass standard Kubernetes resource allocation and device plugin enforcement, injecting arbitrary CDI edits (such as device nodes and host mounts) into the restored container. Successful exploitation requires that the node has CDI enabled and contains a matching host CDI specification for the requested device; environments where CDI is disabled or lacking sensitive device specifications are not affected. This issue has been fixed in versions 2.3.2, 2.2.5 and 2.1.9.
Podczas przywracania kontenera z punktu kontrolnego (checkpoint) containerd błędnie ufa adnotacjom Container Device Interface (CDI) znajdującym się w metadanych niezaufanego obrazu checkpoint, zamiast polegać wyłącznie na specyfikacji kontenera zdefiniowanej podczas jego tworzenia. Atakujący może spreparować archiwum checkpoint zawierające złośliwe adnotacje CDI, takie jak dodatkowe węzły urządzeń (device nodes) lub montowania z systemu hosta. W efekcie przywrócony kontener otrzymuje dostęp do zasobów hosta wykraczający poza pierwotnie zdefiniowane uprawnienia, omijając mechanizmy egzekwowania polityk Kubernetes i pluginów urządzeń. Atak jest możliwy wyłącznie w środowiskach, w których CDI jest włączone i na węźle istnieje pasująca specyfikacja CDI dla żądanego urządzenia.
Atakujący może wstrzyknąć dowolne edycje CDI do przywracanego kontenera, uzyskując nieautoryzowany dostęp do urządzeń hosta i montowań — co prowadzi do naruszenia integralności systemu hosta oraz środowiska kontenerowego (eskalacja uprawnień w zakresie dostępu do zasobów).
Należy zaktualizować containerd do wersji 2.3.2, 2.2.5 lub 2.1.9 (odpowiednio do używanej gałęzi). Jako obejście tymczasowe należy rozważyć wyłączenie obsługi CDI w środowiskach, w których funkcja ta nie jest wymagana.
containerd w wersjach wcześniejszych niż 2.3.2, 2.2.5 oraz 2.1.9, przy włączonej obsłudze CDI i obecności wrażliwych specyfikacji CDI na węźle
Podatność dotyczy wyłącznie środowisk z włączonym CDI i pasującą specyfikacją CDI na węźle; środowiska bez CDI lub bez wrażliwych specyfikacji urządzeń nie są podatne.
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:H/SI:H/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:XLinuxfoundation Containerd
APPLinuxfoundation2.1.0 – 2.1.9 (bez)2.2.0 – 2.2.5 (bez)2.3.0 – 2.3.2 (bez)
Powiązane podatności
containerd CRI plugin: brak walidacji etykiet obrazu umożliwia RCE na hoście
containerd: ominięcie runAsNonRoot przez duży numeryczny identyfikator użytkownika
containerd: odczyt dowolnego pliku hosta przez niezwalidowany symlink w checkpoint
containerd is an open-source container runtime. Versions 0.1.0 through 1.7.28, 2.0.0-beta.0 through 2.0.6, 2.1...
containerd is a container runtime. A time-of-check to time-of-use (TOCTOU) vulnerability was found in containe...