Уязвимость в io_uring позволяла пользователю без прав стать root даже в контейнерах

Недавно раскрыта информация об уязвимости (CVE-2022-29582) в реализации интерфейса асинхронного ввода-вывода io_uring, включенного в ядро ​​Linux начиная с версии 5.1, который позволяет непривилегированному пользователю стать root в системе даже при выполнении эксплойта контейнера.

Стоит отметить, что об указанной уязвимости было сообщено чуть более 3 месяцев назад (примерно в начале мая этого года), но полная информация и раскрытие информации были опубликованы только недавно.

Относительно уязвимости упоминается, что это возникает при обращении к уже освобожденному блоку памяти, проявляется в ядрах Linux, начиная с ветки 5.10.

Об уязвимости CVE-2022-29582

Эта уязвимость разрешает доступ к освобожденной памяти в результате состояния гонки при обработке тайм-аутов в функции io_flush_timeouts(), котораяe удаляет запись тайм-аута из списка и отменяет его, не проверяя создание и удаление тайм-аута в этот момент.

Обновленное общее описание io_uring уже предоставлено другими. Они объясняют это в тысячу раз лучше, чем мы, поэтому мы просто рассмотрим подсистему более подробно (см. эту статью о безопасности Grapl и эту статью о безопасности Flatt для отличного введения).

Что важнее, поле кода операции определяет тип выполняемой операции. Для каждого «кода операции», для которого он требуется, поле fd указывает файловый дескриптор, на котором должен выполняться запрошенный ввод-вывод. Почти все обычные системные вызовы ввода-вывода (чтение, отправка и т. д.) имеют эквивалентный асинхронный код операции. Каждое поле может играть разные роли в зависимости от операции.

После извлечения из SQ SQE преобразуется во внутреннее представление, описываемое структурой io_kiocb (обратный вызов ввода-вывода ядра). Эти объекты обычно называются запросами.

struct io_kiocb используется в качестве эквивалента SQE, «готового к запуску», на котором он основан, при этом любой файловый дескриптор преобразуется в struct file*s, прикрепляются учетные данные пользователя, личность (в которой будут работать ядра) и т. д. .

После завершения запрошенной операции она записывается в очередь завершения. (CQ) запись, соответствующая SQE. Такая запись называется записью очереди завершения (CQE) и содержит такие поля, как код ошибки и значение результата. Приложение пользовательского пространства может опросить CQ на наличие новых записей, чтобы определить, завершена ли обработка отправленных SQE и каков их результат.

Упоминается, что есть несколько сценариев, в которых легко заменить объект на прогресс. Но есть два ограничения:

  • LT' должен быть назначен и инициализирован в окне гонки. То есть после того, как LT освобождается, но до достижения точки в LT, к которой больше нет доступа.
  • LT' может быть только другим объектом struct io_kiocb. Из-за изоляции кучи, когда объекты в куче разделены в соответствии с их типом, слишком сложно переназначить их как объект другого типа в окне гонки.

Исследователи подготовили функциональный эксплойт который не требует включения пространств имен идентификаторов пользователей (user namespaces) для своей работы и может предоставлять root-доступ к хосту, когда непривилегированный пользователь запускает эксплойт в изолированном контейнере.

Наш эксплойт нацелен на версию ядра 5.10.90, на которой в то время Google работал удаленно. Нам пришлось адаптировать наш эксплойт к конкретным спецификациям сервера (4 ядра Skylake Xeon с частотой 2.80 ГГц, 16 ГБ ОЗУ), но с некоторой настройкой любая машина с уязвимым ядром должна быть эксплуатируемой.

Эксплойт также работает в среде nsjail. изолированы в дистрибутиве Google COS (Container Optimized OS) на базе Chromium OS и используются на Google Cloud Platform на виртуальных машинах Compute Engine. Эксплойт предназначен для работы с ветками ядра от 5.10 до 5.12. Наконец, стоит упомянуть, что проблема исправлена ​​в апреле в обновлениях 5.10.111, 5.15.34 и 5.17.3.

Наконец, если вам интересно узнать больше об уязвимости, вы можете ознакомиться с публикацией, сделанной По следующей ссылке.


Оставьте свой комментарий

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

*

*

  1. Ответственный за данные: AB Internet Networks 2008 SL
  2. Назначение данных: контроль спама, управление комментариями.
  3. Легитимация: ваше согласие
  4. Передача данных: данные не будут переданы третьим лицам, кроме как по закону.
  5. Хранение данных: база данных, размещенная в Occentus Networks (ЕС)
  6. Права: в любое время вы можете ограничить, восстановить и удалить свою информацию.