Вони виявили в cgroups v1 вразливість, яка дозволяє вийти з ізольованого контейнера

Кілька днів тому новина була оприлюднена деталі розкрито вразливість що було знайдено в реалізації механізму обмеженість ресурсів cgroup v1 в ядрі Linux, яке вже внесено в каталог CVE-2022-0492.

Ця вразливість виявлена ​​se можна використовувати для виходу із ізольованих контейнерів і детально описано, що проблема присутня з ядра Linux 2.6.24.

У дописі блогу про це йдеться вразливість пов'язана з логічною помилкою в обробнику файлу release_agent, тому належні перевірки не проводилися, коли драйвер запускався з повними дозволами.

Файл release_agent використовується для визначення програми, яку виконує ядро коли процес закінчується в cgroup. Ця програма працює як root з усіма «можливостями» в кореневому просторі імен. Лише адміністратор мав мати доступ до конфігурації release_agent, але насправді перевірки були обмежені наданням доступу користувачам root, що не перешкоджало зміні конфігурації з контейнера або користувачем root без права адміністратора (CAP_SYS_ADMIN ) .

Раніше ця функція не була б сприйнята як уразливість, але ситуація змінилася з появою просторів імен ідентифікаторів користувачів (просторів імен користувача), які дозволяють створювати окремих користувачів root у контейнерах, які не перекриваються з користувачем root основного середовища.

Отже, для атаки достатньо в контейнері, який має власного користувача root в окремому просторі ідентифікатора користувача, щоб підключити ваш обробник release_agent, який після завершення процесу працюватиме з усіма привілеями батьківського середовища.

За замовчуванням cgroupfs монтується в контейнер лише для читання, але немає проблем з перемонтуванням цих псевдофайлів у режимі запису з правами CAP_SYS_ADMIN або шляхом створення вкладеного контейнера з окремим простором імен користувача за допомогою системного виклику для припинення спільного доступу, в якому права 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), щоб отримати доступ до всіх «можливостей» системи.

Крім контейнерів, вразливість може також дозволити процесам 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. Ви можете стежити за випуском оновлень пакетів у дистрибутивах на цих сторінках: DebianSUSEUbuntuRHELFedoraGentooArch Linux.

В кінці кінців якщо вам цікаво дізнатись більше про це, ви можете перевірити деталі в наступне посилання.


Будьте першим, щоб коментувати

Залиште свій коментар

Ваша електронна адреса не буде опублікований. Обов'язкові для заповнення поля позначені *

*

*

  1. Відповідальний за дані: Мігель Анхель Гатон
  2. Призначення даних: Контроль спаму, управління коментарями.
  3. Легітимація: Ваша згода
  4. Передача даних: Дані не передаватимуться третім особам, за винятком юридичних зобов’язань.
  5. Зберігання даних: База даних, розміщена в мережі Occentus Networks (ЄС)
  6. Права: Ви можете будь-коли обмежити, відновити та видалити свою інформацію.