Несколько дней назад новость была выпущена подробности были раскрыты уязвимость что было найдено в реализации механизма ограничение ресурсов контрольные группы v1 в ядре Linux, которое уже внесено в каталог под CVE-2022-0492.
Эта уязвимость обнаруженаe можно использовать для выхода из изолированных контейнеров и подробно описано, что проблема присутствует, начиная с ядра Linux 2.6.24.
В сообщении блога упоминается, что уязвимость связана с логической ошибкой в обработчике файла release_agent, поэтому надлежащие проверки не выполнялись, когда драйвер запускался с полными разрешениями.
Файл release_agent используется для определения программы, которую выполняет ядро. когда процесс заканчивается в контрольной группе. Эта программа запускается от имени пользователя root со всеми «возможностями» в корневом пространстве имен. Предполагалось, что доступ к конфигурации release_agent будет иметь только администратор, но в реальности проверки сводились к предоставлению доступа пользователю root, что не исключало изменения конфигурации из контейнера или неадминистративным пользователем root (CAP_SYS_ADMIN) .
ранее, эта функция не была бы воспринята как уязвимость, но ситуация изменилась с появлением пространств имен идентификаторов пользователей (user namespaces), которые позволяют создавать отдельных пользователей root в контейнерах, не пересекающихся с пользователем root основной среды.
Соответственно, для атаки достаточно в контейнере со своим пользователем root в отдельном пространстве идентификатора пользователя, чтобы подключить обработчик release_agent, который после завершения процесса будет работать со всеми привилегиями родительской среды.
По умолчанию cgroupfs монтируется в контейнер только для чтения, но нет проблем перемонтировать эту псевдофс в режиме записи с правами CAP_SYS_ADMIN или путем создания вложенного контейнера с отдельным пространством имён пользователя с помощью системного вызова stop sharing, в котором права CAP_SYS_ADMIN доступны для созданного контейнера.
Атака можно сделать, имея привилегии root в изолированном контейнере либо запустив контейнер без флага no_new_privs, запрещающего получение дополнительных привилегий.
В системе должна быть включена поддержка пространств имен. пользователь (включен по умолчанию в Ubuntu и Fedora, но не включен в Debian и RHEL) и иметь доступ к корневой cgroup v1 (например, Docker запускает контейнеры в корневой cgroup RDMA). Атака также возможна с привилегиями CAP_SYS_ADMIN, в этом случае поддержка пространств имен пользователей и доступ к корневой иерархии cgroup v1 не требуются.
Помимо выхода из изолированного контейнера, уязвимость также позволяет запускать процессы пользователем root без «возможностей» или любым пользователем с правами CAP_DAC_OVERRIDE (для атаки требуется доступ к файлу /sys/fs/cgroup/*/release_agent, принадлежащему root) для получения доступа ко всем «возможностям» системы.
Помимо контейнеров, уязвимость также может позволить корневым хост-процессам без возможностей или некорневым хост-процессам с возможностью CAP_DAC_OVERRIDE повышать привилегии до полных возможностей. Это может позволить злоумышленникам обойти меры защиты, используемые некоторыми службами, которые удаляют возможности в попытке ограничить влияние в случае компрометации.
Unit 42 рекомендует пользователям обновиться до фиксированной версии ядра. Для запущенных контейнеров включите Seccomp и убедитесь, что AppArmor или SELinux включены. Пользователи Prisma Cloud могут обратиться к разделу «Защита Prisma Cloud», чтобы ознакомиться с мерами по смягчению последствий, предоставляемыми Prisma Cloud.
Обратите внимание, что уязвимость нельзя использовать при использовании механизмов защиты Seccomp, AppArmor или SELinux для дополнительной изоляции контейнера, поскольку Seccomp блокирует системный вызов unshare(), а AppArmor и SELinux не позволяют монтировать cgroupfs в режиме записи.
Наконец, стоит отметить, что это было исправлено в версиях ядра 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.
В конце концов если вам интересно узнать об этом больше, вы можете проверить подробности в по следующей ссылке.