Уязвимост в cgroups v1, позволяваща излизане от изолиран контейнер

Бяха разкрити подробности за уязвимост (CVE-2022-0492) при внедряването на механизма за ограничаване на ресурсите cgroups v1 в ядрото на Linux, който може да се използва за избягване на изолирани контейнери. Проблемът съществува от ядрото на Linux 2.6.24 и е коригиран във версии на ядрото 5.16.12, 5.15.26, 5.10.97, 5.4.177, 4.19.229, 4.14.266 и 4.9.301. Можете да следите публикациите на актуализации на пакети в дистрибуции на тези страници: Debian, SUSE, Ubuntu, RHEL, Fedora, Gentoo, Arch Linux.

Уязвимостта се дължи на логическа грешка в манипулатора на файла release_agent, който не успява да извърши правилни проверки при стартиране на манипулатора с пълни привилегии. Файлът release_agent се използва за дефиниране на програмата, която да бъде изпълнена от ядрото, когато процес в cgroup бъде прекратен. Тази програма работи като root и с всички „възможности“ в пространството на имената на root. Предполагаше се, че само администраторът има достъп до настройката release_agent, но в действителност проверките бяха ограничени до предоставяне на достъп на root потребител, което не изключва настройката да бъде променена от контейнера или от root потребител без администраторски права (CAP_SYS_ADMIN ).

Преди това подобна функция не би била възприемана като уязвимост, но ситуацията се промени с появата на потребителски пространства от имена (потребителски пространства от имена), които ви позволяват да създавате отделни root потребители в контейнери, които не се припокриват с root потребителя на основна среда. Съответно, за атака е достатъчно да свържете своя манипулатор на release_agent в контейнер, който има собствен root потребител в отделно пространство за потребителски идентификатор, който след завършване на процеса ще бъде изпълнен с пълни привилегии на основната среда.

По подразбиране cgroupfs се монтира в контейнер в режим само за четене, но няма проблем с повторното монтиране на този псевдофайл в режим на запис, ако имате права CAP_SYS_ADMIN или чрез създаване на вложен контейнер с отделно потребителско пространство от имена, използвайки системното извикване за премахване на споделянето, в което Правата CAP_SYS_ADMIN са налични за създадения контейнер.

Атаката може да бъде извършена, ако имате права на root в изолиран контейнер или когато изпълнявате контейнер без флага no_new_privs, който забранява получаването на допълнителни привилегии. Системата трябва да има активирана поддръжка за потребителски пространства от имена (активирана по подразбиране в Ubuntu и Fedora, но не активирана в Debian и RHEL) и да има достъп до основната cgroup v1 (например Docker изпълнява контейнери в основната RDMA cgroup). Атаката е възможна и ако имате привилегии CAP_SYS_ADMIN, в който случай не се изисква поддръжка за потребителски пространства от имена и достъп до основната йерархия на cgroup v1.

В допълнение към бягството от изолиран контейнер, уязвимостта също така позволява процеси, стартирани от root потребител без "възможности" или всеки потребител с CAP_DAC_OVERRIDE права (атаката изисква достъп до файла /sys/fs/cgroup/*/release_agent, който е притежаван от root), за да получите достъп до всички системни „възможности“.

Отбелязва се, че уязвимостта не може да бъде използвана при използване на защитните механизми Seccomp, AppArmor или SELinux за допълнителна изолация на контейнери, тъй като Seccomp блокира достъпа до системното повикване unshare(), а AppArmor и SELinux не позволяват монтиране на cgroupfs в режим на запис.

Източник: opennet.ru