Несколько дней назад появилась новость о том, что следственная группа г. Qualys обнаружила уязвимость отказа в обслуживании из-за исчерпания стека в systemd, поэтому любой непривилегированный пользователь может воспользоваться этой уязвимостью заблокировать systemd.
Уязвимость уже внесены в каталог как (CVE-2021-33910) Упоминается, что это влияет на systemd из-за сбоя при попытке смонтировать каталог с размером пути более 8 МБ через FUSE и в котором процесс инициализации элемента управления (PID1) исчерпывает память стека и блокируется, помещая система в состоянии «паники».
Эта уязвимость была представлена в systemd v220 (апрель 2015 г.) коммитом 7410616c («ядро: переработка имени модуля и логика проверки»), который заменил strdup () в куче на strdupa () в батарее. Успешное использование этой уязвимости позволяет любому непривилегированному пользователю вызвать отказ в обслуживании через панику ядра.
Как только исследовательская группа Qualys подтвердила наличие уязвимости, Qualys приняла участие в ответственном раскрытии уязвимости и согласовала действия с автором и дистрибутивами с открытым исходным кодом, чтобы объявить об уязвимости.
Исследователи отмечают, что Проблема связанных с CVE-2021-33910 возникает из-за того, что systemd отслеживает и анализирует содержимое / proc / self / mountinfo и он обрабатывает каждую точку монтирования в функции unit_name_path_escape (), которая вызывает выполнение операции под названием «strdupa ()», которая заботится о размещении данных в стеке, а не в куче.
Вот почему с тех пор максимально допустимый размер стека ограничен функцией "RLIMIT_STACK", обработка слишком длинного пути к точке монтирования приводит к зависанию процесса "PID1" что приводит к остановке системы.
Кроме того, они упоминают, что для того, чтобы атака была функциональной, можно использовать простейший модуль FUSE в сочетании с использованием сильно вложенного каталога в качестве точки монтирования, размер пути которого превышает 8 МБ.
также Важно отметить, что исследователи Qualys упомянуть конкретный случай с уязвимостью, так как особенно с systemd версии 248, эксплойт не работает из-за ошибки, присутствующей в коде systemd, которая приводит к сбою / proc / self / mountinfo. Также интересно, что очень похожая ситуация возникла в 2018 году, когда при попытке написать эксплойт для уязвимости CVE-2018-14634 в ядре Linux, в которой исследователи Qualys обнаружили три другие критические уязвимости в systemd.
Об уязвимости команда Red Hat упомянула любой продукт, совместимый с RHEL, также может быть затронут.
Это включает в себя:
- Контейнеры продуктов, основанные на образах контейнеров RHEL или UBI. Эти образы регулярно обновляются, а статус контейнера, указывающий, доступно ли исправление для этой ошибки, можно просмотреть в Индексе работоспособности контейнера, который является частью каталога контейнеров Red Hat (https://access.redhat.com/containers). .
- Продукты, которые извлекают пакеты из канала RHEL. Убедитесь, что базовый пакет systemd Red Hat Enterprise Linux обновлен в этих средах продукта.
Из-за широты поверхности атаки этой уязвимости, Qualys рекомендует пользователям применять соответствующие патчи. (которые уже были выпущены несколько дней назад) для этой уязвимости немедленно.
Как уже упоминалось, проблема появилась с systemd 220 (апрель 2015 г.) и уже исправлено в главный репозиторий systemd и был исправлен в большинстве дистрибутивов Linux main, а также его производные, вы можете проверить статус по следующим ссылкам (Debian, Ubuntu, Fedora, RHEL, СУЗЕ, Арка).
Наконец, если вам интересно узнать об этом больше об этой уязвимости, вы можете проверить подробности о ней По следующей ссылке.