Обход изоляции в vm2 приводит к выполнению кода и раскрытию данных

Библиотека vm2, которая создаёт изолированную среду для запуска недоверенного кода в Node.js, содержит четыре уязвимости. Все они ломают защиту, ради которой библиотеку и устанавливают. В итоге удалённый нарушитель может выполнить произвольный код, получить доступ к защищаемой информации и вызвать отказ в обслуживании. Проблемы затрагивают выпуски с 3.11.0 по 3.11.6 включительно, а одна из них сохраняется и в 3.11.7. Сведения о них внесены в Банк данных угроз безопасности информации под номерами BDU:2026-14935, BDU:2026-14936, BDU:2026-14942 и BDU:2026-14945. Производитель подтвердил каждую уязвимость, а готовые эксплойты уже выложены в открытый доступ.

Детали уязвимостей

Речь идёт о библиотеке, которую распространяют через npm, то есть через пакетный менеджер для Node.js. Сам Node.js представляет собой среду выполнения JavaScript на сервере. Разработчики подключают vm2, чтобы безопасно исполнять чужой код: скрипты плагинов, пользовательские формулы, фрагменты автоматизации, учебные задания. Библиотека подменяет системные объекты и не даёт такому коду выйти за отведённые рамки. Именно эту границу исследователи и обошли, причём сразу несколькими способами.

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

Вторая проблема связана с обработкой доверенных сертификатов. Функция, задающая список корневых сертификатов для защищённых соединений, присваивает права на критичный ресурс неправильно. Из-за этого исполняемый код может подменить цепочку доверия. Последствие серьёзнее, чем утечка: нарушитель получает возможность выполнить свой код в том процессе, который запустил библиотеку. Проверка подлинности серверов после такой подмены теряет смысл.

Третья уязвимость затрагивает функции сборки и объединения буферов, то есть участков памяти для временного хранения данных. Здесь совмещены две проблемы: раскрытие информации и отказ в обслуживании. Злоумышленник либо читает чужие данные, либо доводит процесс до аварийного завершения. Четвёртая касается прототипов типизированных массивов и буферов памяти. Контроль над такими объектами ослаблен, поэтому нарушитель манипулирует выделением памяти и тоже добивается выполнения собственного кода. Все четыре уязвимости относятся к классу ошибок кода и подтверждены производителем.

Наличие публичных эксплойтов, то есть вредоносного кода, который использует уязвимость, меняет расклад. Атакующему не нужно разбираться в устройстве библиотеки: готовый инструмент уже есть, а порог входа снижается до копирования чужой наработки. Оценки по CVSS 3.1 и CVSS 4.0 достигают десяти баллов. Вектор атаки сетевой, привилегии не требуются, участие пользователя не предполагается, а влияние выходит за пределы уязвимого компонента. По шкале CVSS 2.0 базовая оценка одной из проблем составляет 9,7.

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

Исправления уже опубликованы. Производитель разместил рекомендации в своём репозитории на GitHub и закрыл уязвимости в новых выпусках. Всем, кто использует vm2, следует перейти на версию, где устранены все четыре проблемы. Только после этого изоляция снова работает как задумано. Если обновление откладывается, разумно вынести исполнение недоверенного кода в отдельный процесс или контейнер и ограничить его права. Такой шаг не закрывает уязвимость, но сокращает возможный ущерб: вырваться из процесса нарушителю будет сложнее, чем из библиотеки.

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

Детали уязвимостей

Ссылки