Патч не спас: критический баг в NVIDIA Container Toolkit пришлось исправлять дважды

Как хакеры продолжили обходить защиту даже после официального исправления?


c8cbfmgdqxc8409f3izagoadd95eig5c.jpg


В сентябре 2024 года компания NVIDIA выпустила обновление для устранения критической уязвимости CVE-2024-0132 в своём инструменте Container Toolkit. Проблема заключалась в расхождении между моментом проверки и использованием объекта (TOCTOU), что позволяло злоумышленникам организовать так называемый «побег из контейнера» и получать доступ к ресурсам хостовой системы. Уязвимость получила высокий балл по шкале CVSS — 9.0. Однако, как выяснилось, защита оказалась неполной, и в начале 2025 года эксперты зафиксировали возможность её обхода.

Анализ, проведённый специалистами Trend Micro, подтвердил : исправление от NVIDIA не закрывает уязвимость полностью. Более того, исследование выявило ещё одну связанную проблему производительности, затрагивающую Docker на Linux и способную вызвать отказ в обслуживании. Это делает ситуацию потенциально опасной не только в плане безопасности, но и с точки зрения стабильности работы серверов.

Открытие новой уязвимости получило идентификатор CVE-2025-23359 и тот же высокий рейтинг опасности — 9.0 баллов. Её суть кроется в функции mount_files, отвечающей за монтирование файловых систем. В процессе обнаружено отсутствие блокировок, что открывает возможность изменения объекта до завершения операции. Если злоумышленник уже имеет доступ к выполнению кода внутри контейнера, он может использовать эту уязвимость для повышения привилегий и запуска произвольного кода от имени хоста.

Интересно, что ещё в феврале 2025 года компания Wiz предупредила о возможности обхода исходной уязвимости, но лишь сейчас данные подтверждены технически. Обе проблемы были закрыты в версии 1.17.4 NVIDIA Container Toolkit, однако применимость обновления зависит от включения определённых параметров — например, «allow-cuda-compat-libs-from-container».

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

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

Факт наличия сразу двух критических проблем — как в области безопасности, так и производительности — подчёркивает важность многоуровневой защиты при работе с контейнерами. Даже при наличии официальных исправлений, их корректность и полнота должны проверяться дополнительными средствами.