Обнаружены критические уязвимости в Docker: контейнеры могут выйти из изоляции

По данным Hothardware, специалисты в области безопасности обнаружили несколько критических уязвимостей в инструментах, используемых для работы с контейнеризацией в Docker. Эти уязвимости затрагивают компонент runC, который, согласно описанию Docker, отвечает за инфраструктурные задачи и обеспечивает удобство разработки для программистов.

Уязвимости в runC и их потенциальные последствия

RunC представляет собой универсальный runtime для контейнеров, позволяющий распределенным приложениям работать на разных типах оборудования и операционных систем. В связи с тем, что он предоставляет контейнерам доступ к ресурсам хост-системы, такие уязвимости становятся особенно опасными.

Одна из уязвимостей, обозначенная как CVE-2025-31133, связана с возможностью маскировки путей и защиты чувствительных файлов. При использовании bind-монтирования файла dev/null контейнера поверх другого файла злоумышленник может заменить dev/null на симлинк, что открывает путь к выходу из изоляции контейнера и непосредственному доступу к хост-системе.

Аналогичный механизм действует и в случае CVE-2025-52565. Эта уязвимость позволяет злоумышленнику использовать способность runC к монтированию файлов. Создавая bind-монтирование dev/console, атакующий может заставить runC выполнить симлинк на другой файл или путь, что ведет к выходу из изолированной среды контейнера.

Третья уязвимость, CVE-2025-52881, касается обхода проверки доступа к файлам procfs. Злоумышленник может использовать существующий файл из procfs, чтобы перенаправить доступ к чувствительным системным файлам, таким как /proc/sysrq-trigger. Это открывает возможность для выполнения вредоносных действий, включая принудительную перезагрузку хост-системы, а также выход из контейнера.

Рекомендации для пользователей runC

Системные администраторы, применяющие библиотеку runC в Docker или других инструментах, должны как можно скорее обновить используемое ПО. Хотя уязвимости пока не были использованы в реальных атаках, их публикация делает вероятным появление эксплойтов в ближайшее время.

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

Интересно: Как обеспечить защиту контейнерной среды, если сама её основа — уязвима?

i

Создано специально для ASECTOR

Концептуальное изображение

Когда безопасность основы становится проблемой

Обнаружение критических уязвимостей в runC — это не только техническая неприятность для разработчиков. Это сигнал о системном риске в архитектуре, которая сегодня лежит в основе десятков тысяч серверов, от облаков до локальных кластеров. runC — это не только библиотека, а инфраструктурный слой, который определяет, насколько изолированы друг от друга процессы в контейнерах. Если он сломан, то вся система безопасности теряет смысл.

Уязвимость как узел в цепочке

Одна из обнаруженных уязвимостей позволяет злоумышленнику замаскировать один файл под другой, используя специфические механизмы монтирования. Это похоже на то, как в реальной жизни можно поменять замок на двери, не вызывая подозрений у соседей. Если контейнер — это комната, а хост-система — дом, то уязвимость в runC — это ключ, который открывает дверь в соседнюю квартиру. Атакующий может выйти за пределы изоляции и получить доступ к ресурсам, которые ему не предназначены.

Такие атаки особенно опасны в средах, где контейнеры используются для запуска стороннего кода. Например, в CI/CD-системах или облачных сервисах, где разные клиенты делят общую инфраструктуру. Если контейнер одного пользователя может выйти за пределы своей изоляции, это может повлечь утечку данных, компрометацию всей системы или даже перераспределение ресурсов в пользу злоумышленника.

Кто выигрывает, а кто теряет

На первый взгляд, уязвимости в runC — это проблема разработчиков и администраторов. Но на деле это также событие, которое влияет на рынок ИТ-безопасности. Компании, предоставляющие решения для мониторинга контейнеров и защиты инфраструктуры, получают дополнительный импульс. Это может быть как производители систем мониторинга, так и разработчики альтернативных runtime-ов, которые предлагают более безопасные модели изоляции.

С другой стороны, предприятия, которые не успеют обновиться, рискуют столкнуться с серьезными последствиями. Особенно это касается тех, кто использует контейнеры в критически важных системах. В таких случаях уязвимость может привести не только к утечке данных, но и к остановке бизнес-процессов. Это, в свою очередь, создает дополнительную нагрузку на ИТ-отделы и увеличивает стоимость инцидентов.

Важный нюанс: Уязвимость в инфраструктуре — это не техническая проблема, а вызов для всей системы безопасности, где каждый компонент должен работать в синхроне. Один слабый звено — и вся система под угрозой.

Как это повлияет на будущее

Уязвимости в runC — это не первый случай, когда инфраструктурный компонент становится уязвимым. Но он важен тем, что демонстрирует, насколько глубоко встроены контейнеры в современные ИТ-системы. Это заставляет пересмотреть подходы к архитектуре безопасности. Возможно, в будущем мы увидим более строгие требования к аудиту runtime-ов, а также рост интереса к альтернативным технологиям изоляции, таким как виртуализация или sandbox-технологии.

Для российского бизнеса это означает, что важно не только оперативно обновлять ПО, но и пересматривать стратегию использования контейнеров. Особенно это актуально для тех, кто работает с государственными системами или финтех-продуктами, где требования к безопасности особенно высоки.

Ключевой вывод: Безопасность контейнерной среды начинается с её основы. Если runtime-ы, на которых она строится, не защищены — вся система уязвима.

Уроки из других уязвимостей

Анализ текущей ситуации в контексте других недавних инцидентов показывает, что рост киберугроз напрямую связан с низкой скоростью исправления известных уязвимостей. Например, более 15% успешных атак брокеров первоначального доступа связаны с эксплуатацией уязвимостей, в основном давно известных и не исправленных [!]. Это подчеркивает, что даже базовые меры безопасности, такие как регулярное обновление ПО, остаются критически важными.

Также важно учитывать, что уязвимости могут стать точкой входа не только для атак на конкретную систему, но и для вторжений через подрядчиков. Более половины российских ИТ-подрядчиков имеют низкий уровень кибербезопасности [!]. Это делает их потенциальными векторами атак, что требует усиления контроля над безопасностью третьих лиц.

Важный момент: Обновления не должны быть ритуалом. Они — часть повседневной практики, которая минимизирует риски и уменьшает вероятность инцидентов.

Рекомендации для бизнеса

Для минимизации рисков ключевым становится аудит текущих конфигураций, а также контроль за процессом обновления. Особенно это актуально для тех, кто использует контейнеры в критически важных системах или инфраструктуре. Следует также учитывать, что уязвимости могут быть частью более широких атак, как это было в случае с уязвимостью в плагине WordPress, где несанкционированный доступ к конфигурационным файлам мог привести к компрометации всей системы [!].

Важно: В условиях роста масштаба и сложности атак, включая комбинации фишинга и скрытых вторжений, эффективная система управления угрозами позволяет сортировать поток событий и выделять приоритетные действия [!].

Что дальше

Одним из последствий уязвимостей в инфраструктурных компонентах является рост интереса к альтернативным технологиям изоляции. Уязвимость в Redis позволяет выполнить произвольный код на сервере [!]. Такие случаи усиливают потребность в более строгих стандартах безопасности и аудите даже тех систем, которые считаются надежными.

Вывод: Каждая уязвимость — это не только баг. Это возможность для злоумышленников. И если бизнес не готов к оперативным действиям, он рискует потерять контроль над своими данными и репутацией.