Podatności containerd

W systemie containerd przed wersjami 2.3.2, 2.2.5 i 2.1.9 wykryto podatność w implementacji CRI, która nieprawidłowo ufa adnotacjom CDI z nieufnych metadanych obrazów punktów kontrolnych podczas przywracania kontenera. Osoba z uprawnieniami do tworzenia podów może ominąć standardowe przydzielanie zasobów Kubernetes i wymusić wstrzyknięcie dowolnych urządzeń lub montowań hosta do przywróconego kontenera.

Podatność w containerd przed wersjami 2.3.2, 2.2.5 i 2.1.9 pozwala atakującemu z uprawnieniami do tworzenia podów na zatrucie lokalnego cache obrazów poprzez spreparowany obraz punktu kontrolnego (checkpoint). Brak walidacji referencji obrazów w konfiguracji importu punktu kontrolnego umożliwia przypisanie dowolnego lokalnego tagu do złośliwego obrazu.

Podatność w containerd pozwala na odczyt dowolnego pliku na hoście przez polecenie kubectl logs. Błąd występuje w pluginie CRI, który przywraca plik container.log z obrazu punktu kontrolnego bez walidacji ścieżki dowiązania symbolicznego.

Podatność w containerd pozwala na wyczerpanie pamięci poprzez specjalnie spreparowany obraz kontenera, co prowadzi do zabicia procesu containerd (OOM) i uniemożliwia korzystanie z API środowiska uruchomieniowego. Problem dotyczy wersji przed 1.7.33, 2.0.10, 2.1.9, 2.2.5 i 2.3.2.

W containerd przed wersjami 1.7.32, 2.0.9, 2.2.4 i 2.3.1, kontenery z dyrektywą User ustawioną na wartość liczbową, która nie może być sparsowana jako 32-bitowa liczba całkowita, są błędnie traktowane jako nazwa użytkownika. Umożliwia to ominięcie ograniczenia runAsNonRoot w Kubernetes, jeśli spreparowany obraz zawiera wpis w /etc/passwd mapujący tę dużą liczbę na roota, co powoduje uruchomienie kontenera jako root (UID 0).

Wtyczka CRI w containerd przed wersjami 1.7.33, 2.3.2, 2.2.5, 2.1.9 i 2.0.10 propaguje etykiety z konfiguracji obrazu (instrukcja LABEL w Dockerfile) do kontenera bez walidacji. Może to umożliwić wykonanie dowolnego polecenia na hoście przez wtyczkę, która wykorzystuje etykiety kontenerów do pewnych operacji.