Уязвимост в 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 и с всички "capabilities" в кореновото пространство на имената. Предполага се, че достъпът до настройката на release_agent имат само администратори, но в действителност проверките са ограничени до предоставяне на достъп на потребител с права на root, което не изключва промяна на настройката от контейнер или от потребител с права на root без администраторски права (CAP_SYS_ADMIN).

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

По подразбиране cgroupfs се монтира в контейнера в режим само за четене, но няма проблем да се пре-монтира тази pseudo-fs в режим запис при наличие на права CAP_SYS_ADMIN или чрез създаване с помощта на системен повик unshare на вложен контейнер с отделно user namespace, в който за създадения контейнер са достъпни правата CAP_SYS_ADMIN.

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

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

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

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