Критическая уязвимость в открытой JavaScript-песочнице isolated-vm позволяет недоверенному коду покинуть изолированную среду и повредить память основного приложения. Практические атаки доходят от аварийного завершения процесса до перехвата потока управления на хосте, что создаёт возможность удалённого выполнения кода, или RCE. Ошибка затрагивает все выпуски вплоть до 7.0.0 включительно.
isolated-vm представляет собой библиотеку для Node.js, запускающую недоверенный JavaScript внутри V8 Isolate — независимого экземпляра движка Google V8. Несколько таких сред могут работать одновременно, не обмениваясь данными напрямую и не вмешиваясь в состояние друг друга. Масштаб последствий связан с популярностью проекта: свыше 2900 звёзд и около 190 форков на GitHub, почти 1 миллион загрузок из npm за неделю, предшествовавшую публикации сведений об уязвимости.
Каждый V8 Isolate хранит собственное состояние и располагает отдельной кучей памяти. Поэтому объект JavaScript нельзя просто передать из главного потока Node.js в рабочий изолят. Эту задачу в isolated-vm решает класс ExternalCopy: он сериализует объект за пределами изолята хоста, а затем десериализует его внутри гостевой среды. Именно в этом мостике между двумя областями памяти и обнаружилась опасная ошибка.
Исследователи Endor Labs нашли в ExternalCopy уязвимость смешения типов, связанную с обработкой параметра transferList. Код внутри песочницы способен воспользоваться ею для порчи памяти процесса-хоста. Для начала атаки достаточно одного объекта ivm.Reference — стандартного механизма, с помощью которого хост предоставляет гостевому коду доступ к какой-либо функции или ресурсу. Иными словами, потенциально опасным оказывается сам привычный способ наделить песочницу хоть какими-то полномочиями.
Уязвимость обнаружил и сообщил о ней исследователь Endor Labs Cristian-Alexandru Staicu, а его техническое описание получила редакция The Hacker News. Суть ошибки он сформулировал так: «Смешение типов при обработке параметра transferList в ExternalCopy позволяет коду, выполняющемуся внутри песочницы, повреждать память процесса-хоста». Исследователи начали с управляемого сбоя по заданному адресу, после чего смогли перехватить поток управления процессом.
Минимальный подтверждённый результат атаки — надёжный отказ в обслуживании. Гостевой код, получивший ivm.Reference, может вызвать контролируемое обращение к памяти и завершить хост-процесс ошибкой сегментации SIGSEGV. Сопровождающий isolated-vm Marcel Laverdet написал в уведомлении: «Минимальное продемонстрированное воздействие — надёжный сбой по контролируемому адресу, то есть отказ в обслуживании, который способен вызвать любой гость, получивший ivm.Reference — стандартный способ предоставить песочнице какие-либо полномочия».
Предельный сценарий заметно опаснее обычного падения приложения. Staicu сообщил: «Начав всего с одного ivm.Reference — стандартного способа, которым хосты вообще предоставляют песочнице какие-либо возможности, — мы развили эксплуатацию ошибки от сбоя по контролируемому адресу до перехвата потока управления хоста, продемонстрировав полный выход гостя из песочницы на хост». Laverdet дал ту же оценку короче: «Максимальное продемонстрированное воздействие — перехват потока управления процесса-хоста, то есть потенциальное удалённое выполнение кода на хосте».
Сам защитный механизм Google V8 при этом устоял. Граница V8 Isolate не была взломана напрямую; проблема находилась в написанном на C++ связующем коде, который переносит значения через эту границу. Staicu пояснил: «Главный урок состоит в том, что нарушен был не сам механизм изоляции. Граница V8 Isolate устояла. Ошибка возникла в связующем C++-коде, который преобразует значения при передаче через эту границу. Полностью надёжный строительный блок оказался скомпрометирован обёрнутым вокруг него слоем привязки». Небезопасный маршалинг в ExternalCopy фактически отменил гарантии, ради которых и применялась песочница.
Уязвимость зарегистрирована в бюллетене GitHub как GHSA-864f-rcv7-6rh4. На момент раскрытия отдельный идентификатор CVE ещё не был присвоен. Исправления вошли в версии 6.2.0 для ветки 6.x и 7.0.1 для ветки 7.x. Обе версии выпустили ранее в том же месяце, когда появился отчёт, однако точная дата в опубликованных данных не указана.
Пользователям ветки 6.x необходимо установить как минимум isolated-vm 6.2.0, а пользователям 7.x — 7.0.1 или более новую версию; предпочтителен последний доступный релиз. Проверять следует и прямые зависимости, и пакеты, которые подключают isolated-vm транзитивно. Полное техническое описание эксплуатации пока не опубликовано, чтобы затруднить воспроизведение атаки злоумышленниками, но подтверждённых SIGSEGV, выхода из гостевой среды и перехвата потока управления уже достаточно для срочного обновления.
Изображение носит иллюстративный характер
isolated-vm представляет собой библиотеку для Node.js, запускающую недоверенный JavaScript внутри V8 Isolate — независимого экземпляра движка Google V8. Несколько таких сред могут работать одновременно, не обмениваясь данными напрямую и не вмешиваясь в состояние друг друга. Масштаб последствий связан с популярностью проекта: свыше 2900 звёзд и около 190 форков на GitHub, почти 1 миллион загрузок из npm за неделю, предшествовавшую публикации сведений об уязвимости.
Каждый V8 Isolate хранит собственное состояние и располагает отдельной кучей памяти. Поэтому объект JavaScript нельзя просто передать из главного потока Node.js в рабочий изолят. Эту задачу в isolated-vm решает класс ExternalCopy: он сериализует объект за пределами изолята хоста, а затем десериализует его внутри гостевой среды. Именно в этом мостике между двумя областями памяти и обнаружилась опасная ошибка.
Исследователи Endor Labs нашли в ExternalCopy уязвимость смешения типов, связанную с обработкой параметра transferList. Код внутри песочницы способен воспользоваться ею для порчи памяти процесса-хоста. Для начала атаки достаточно одного объекта ivm.Reference — стандартного механизма, с помощью которого хост предоставляет гостевому коду доступ к какой-либо функции или ресурсу. Иными словами, потенциально опасным оказывается сам привычный способ наделить песочницу хоть какими-то полномочиями.
Уязвимость обнаружил и сообщил о ней исследователь Endor Labs Cristian-Alexandru Staicu, а его техническое описание получила редакция The Hacker News. Суть ошибки он сформулировал так: «Смешение типов при обработке параметра transferList в ExternalCopy позволяет коду, выполняющемуся внутри песочницы, повреждать память процесса-хоста». Исследователи начали с управляемого сбоя по заданному адресу, после чего смогли перехватить поток управления процессом.
Минимальный подтверждённый результат атаки — надёжный отказ в обслуживании. Гостевой код, получивший ivm.Reference, может вызвать контролируемое обращение к памяти и завершить хост-процесс ошибкой сегментации SIGSEGV. Сопровождающий isolated-vm Marcel Laverdet написал в уведомлении: «Минимальное продемонстрированное воздействие — надёжный сбой по контролируемому адресу, то есть отказ в обслуживании, который способен вызвать любой гость, получивший ivm.Reference — стандартный способ предоставить песочнице какие-либо полномочия».
Предельный сценарий заметно опаснее обычного падения приложения. Staicu сообщил: «Начав всего с одного ivm.Reference — стандартного способа, которым хосты вообще предоставляют песочнице какие-либо возможности, — мы развили эксплуатацию ошибки от сбоя по контролируемому адресу до перехвата потока управления хоста, продемонстрировав полный выход гостя из песочницы на хост». Laverdet дал ту же оценку короче: «Максимальное продемонстрированное воздействие — перехват потока управления процесса-хоста, то есть потенциальное удалённое выполнение кода на хосте».
Сам защитный механизм Google V8 при этом устоял. Граница V8 Isolate не была взломана напрямую; проблема находилась в написанном на C++ связующем коде, который переносит значения через эту границу. Staicu пояснил: «Главный урок состоит в том, что нарушен был не сам механизм изоляции. Граница V8 Isolate устояла. Ошибка возникла в связующем C++-коде, который преобразует значения при передаче через эту границу. Полностью надёжный строительный блок оказался скомпрометирован обёрнутым вокруг него слоем привязки». Небезопасный маршалинг в ExternalCopy фактически отменил гарантии, ради которых и применялась песочница.
Уязвимость зарегистрирована в бюллетене GitHub как GHSA-864f-rcv7-6rh4. На момент раскрытия отдельный идентификатор CVE ещё не был присвоен. Исправления вошли в версии 6.2.0 для ветки 6.x и 7.0.1 для ветки 7.x. Обе версии выпустили ранее в том же месяце, когда появился отчёт, однако точная дата в опубликованных данных не указана.
Пользователям ветки 6.x необходимо установить как минимум isolated-vm 6.2.0, а пользователям 7.x — 7.0.1 или более новую версию; предпочтителен последний доступный релиз. Проверять следует и прямые зависимости, и пакеты, которые подключают isolated-vm транзитивно. Полное техническое описание эксплуатации пока не опубликовано, чтобы затруднить воспроизведение атаки злоумышленниками, но подтверждённых SIGSEGV, выхода из гостевой среды и перехвата потока управления уже достаточно для срочного обновления.
