Ujawniono szczegóły podatności (CVE-2022-0492) w implementacji mechanizmu ograniczenia zasobów cgroups v1 w jądrze Linux, która może być wykorzystywana do wyjścia z izolowanych kontenerów. Problem występuje od jądra Linux 2.6.24 i został usunięty w wydaniach jąder 5.16.12, 5.15.26, 5.10.97, 5.4.177, 4.19.229, 4.14.266 oraz 4.9.301. Można śledzić publikację aktualizacji pakietów w dystrybucjach na tych stronach: Debian, SUSE, Ubuntu, RHEL, Fedora, Gentoo, Arch Linux.
Podatność jest spowodowana błędem logicznym w obsłudze plików release_agent, przez co nie były przeprowadzane odpowiednie kontrole podczas uruchamiania obsługi z pełnym zestawem uprawnień. Plik release_agent jest używany do określenia programu, który jest uruchamiany przez jądro przy zakończeniu procesu w cgroup. Program ten jest uruchamiany z prawami roota i ze wszystkimi 'capabilities' w przestrzeni nazw. Zakładano, że dostęp do ustawienia release_agent ma tylko administrator, ale w rzeczywistości kontrole ograniczały się do przyznawania dostępu użytkownikowi root, co nie wykluczało zmiany ustawienia z kontenera lub przez użytkownika root bez praw administratora (CAP_SYS_ADMIN).
Wcześniej taka cecha nie byłaby postrzegana jako podatność, ale sytuacja zmieniła się wraz z pojawieniem się przestrzeni nazw identyfikatorów użytkowników (user namespaces), które umożliwiają tworzenie w kontenerach oddzielnych użytkowników roota, którzy nie kolidują z użytkownikiem root głównego środowiska. W związku z tym do przeprowadzenia ataku wystarczy w kontenerze, mającym swojego użytkownika roota w oddzielnej przestrzeni identyfikatorów użytkowników, podłączyć swój obsługiwacz release_agent, który po zakończeniu procesu zostanie wykonany z pełnymi uprawnieniami głównego środowiska.
Domyślnie cgroupfs jest montowany w kontenerze w trybie tylko do odczytu, ale nie ma problemów z ponownym montowaniem tego pseudo fs w trybie zapisu, jeśli są uprawnienia CAP_SYS_ADMIN lub poprzez utworzenie za pomocą wywołania systemowego unshare zagnieżdżonego kontenera z oddzielną przestrzenią nazw użytkownika, w której dla utworzonego kontenera dostępne są uprawnienia CAP_SYS_ADMIN.
Atakę można przeprowadzić posiadając uprawnienia root w izolowanym kontenerze lub uruchamiając kontener bez flagi no_new_privs, która zabrania uzyskania dodatkowych przywilejów. W systemie powinna być włączona obsługa przestrzeni nazw użytkowników (domyślnie włączona w Ubuntu i Fedory, ale nie aktywowana w Debianie i RHEL) oraz dostęp do głównego cgroup v1 (na przykład Docker uruchamia kontenery w głównym cgroup RDMA). Atak jest również możliwy przy posiadaniu przywilejów CAP_SYS_ADMIN, w tym przypadku wsparcie dla przestrzeni nazw użytkowników i dostęp do głównej hierarchii cgroup v1 nie jest wymagany.
Oprócz wyjścia z izolowanego kontenera, podatność ta pozwala także procesom uruchomionym przez użytkownika root bez „uprawnień” lub przez dowolnego użytkownika z prawami CAP_DAC_OVERRIDE (do ataku wymagany jest dostęp do pliku /sys/fs/cgroup/*/release_agent, który należy do roota) uzyskać dostęp do wszystkich systemowych „uprawnień”.
Zauważono, że podatność nie może być wykorzystana przy stosowaniu mechanizmów ochrony Seccomp, AppArmor lub SELinux do dodatkowej izolacji kontenerów, ponieważ Seccomp blokuje dostęp do wywołania systemowego unshare(), a AppArmor i SELinux nie pozwalają na zamontowanie cgroupfs w trybie zapisu.
Źródło: opennet.ru
