Критичные уязвимости NVIDIA Container Toolkit

Обнаружены критические проблемы безопасности в NVIDIA Container Toolkit, связанные с неполноценным патчем для CVE-2024-0132, что открывает возможность побега из контейнера и несанкционированного доступа к файловой системе хоста.
Критичные уязвимости NVIDIA Container Toolkit
Изображение носит иллюстративный характер

Уязвимость CVE-2024-0132 представляет собой дефект типа "time-of-check time-of-use" с оценкой критичности CVSS 9.0. Ошибка позволяет злоумышленнику, уже имеющему возможность выполнять код внутри контейнера, получать права root и осуществлять произвольное выполнение команд на хост-системе.

Патч, выпущенный NVIDIA в сентябре 2024 года, оказался частичным и не устранил все уязвимости. Анализ, проведенный Trend Micro, выявил, что указанное исправление не препятствует полному использованию ошибки для обхода контейнерной изоляции, создавая серьезные риски для безопасности инфраструктуры.

Исследователь Abdelrahman Esmail из Trend Micro отметил: «Эти проблемы могут позволить злоумышленникам нарушить изоляцию контейнера, получить доступ к критическим ресурсам хоста и вызвать серьезные операционные сбои». При этом flaw обнаружен в функции mount_files, где отсутствие надлежащей блокировки позволяет специально сформированным контейнерам эксплуатировать недостатки системы, особенно при включенной опции allow-cuda-compat-libs-from-container в версии 1.17.4.

Помимо основной проблемы, обнаружена дополнительная уязвимость для повышения привилегий, получившая идентификатор CVE-2025-23359 с оценкой CVSS 9.0. Компания Wiz зафиксировала данное нарушение в феврале 2025 года, отметив, что оно является обходом патча CVE-2024-0132 и было учтено в обновлении версии 1.17.4.

В системах Docker на Linux выявлена смежная проблема, способная привести к отказу в обслуживании. При создании нового контейнера с множественными точками монтирования, настроенными с использованием параметра bind-propagation=shared, записи остаются в таблице монтирования даже после завершения работы контейнера. Это приводит к экспоненциальному росту количества дескрипторов файлов (fd) и, в конечном итоге, к невозможности создания новых контейнеров, что нарушает возможность удаленного подключения, например, через SSH.

Для минимизации угроз рекомендуется вести постоянный мониторинг таблицы монтирования Linux на предмет аномального роста, строго ограничивать доступ к API Docker только уполномоченным пользователям и применять надежные политики контроля доступа. Регулярный аудит связей файловой системы контейнера с хостом, проверка точек монтирования томов и анализ сокет-подключений являются важными мерами для своевременного обнаружения и устранения потенциальных нарушений.


Новое на сайте

20327Кости прерий: как истребление бизонов породило целую индустрию — и сама себя же уничтожила 20326Кто и зачем взламывает серверы Ollama и ComfyUI ради ключей от AWS? 20325Как злоумышленники спрятали командный сервер внутри блокчейна и почему его невозможно... 20324Брюссель заставляет Android делиться секретами с чужими ИИ-помощниками 20323WordPress: как два бага слились в одну критическую дыру, которую назвали wp2shell 20322Как китайские хакеры обманули DigiCert и украли сертификаты для подписи кода? 20321Что скрывается за уязвимостью, которую агентство США внесло в список активно используемых... 20320Автономные системы наступают быстрее, чем инфраструктура для управления ими: кто выиграет... 20319Почему в OpenSSL нашли дыру, съедающую память серверов, но не дали ей даже номер CVE? 20317SonicWall SMA 1000: как два бага превратили VPN-шлюз в бэкдор для атакующих 20316Может ли уязвимость в клиенте Zoom для Windows открыть доступ к чужому аккаунту без... 20315TELEPUZ: новый вредонос на C, который научился прятаться в Telegram, Steam и блокчейне... 20314Дома из дёрна: как исландцы триста лет прятались от холода под слоем земли и травы 20313Как один токен от чужого сервиса мог впустить злоумышленника в чужой аккаунт n8n?
Ссылка