Krytyczna luka w isolated-vm umożliwia ucieczkę z sandboxa JavaScript i grozi potencjalnym RCE

Wprowadzenie do problemu / definicja

W ekosystemie Node.js biblioteka isolated-vm jest wykorzystywana do uruchamiania niezaufanego kodu JavaScript w odizolowanych instancjach silnika V8. Taki model ma ograniczać wpływ potencjalnie złośliwego kodu na proces hosta i stanowić dodatkową warstwę ochrony dla aplikacji przetwarzających skrypty użytkowników.

Ujawniona podatność pokazuje jednak, że bezpieczeństwo sandboxa nie zależy wyłącznie od samego mechanizmu izolacji V8. Równie istotna jest warstwa pośrednicząca odpowiedzialna za przekazywanie danych między środowiskiem gościa a hostem.

W skrócie

Badacze opisali krytyczną lukę oznaczoną jako GHSA-864f-rcv7-6rh4, która dotyczy biblioteki isolated-vm w wersjach do 7.0.0 włącznie. Problem został usunięty w wydaniach 6.2.0 oraz 7.0.1.

Błąd może prowadzić do uszkodzenia pamięci procesu hosta przez kod wykonywany w sandboxie. W praktyce oznacza to ryzyko awarii usługi, ucieczki z izolacji, a w najbardziej niebezpiecznym scenariuszu także przejęcia przepływu sterowania i potencjalnego zdalnego wykonania kodu.

Podatność dotyczy komponentu ExternalCopy.
Źródłem problemu jest błąd typu type confusion.
Atak może zostać zainicjowany z poziomu sandboxowanego JavaScript.
Najbardziej narażone są środowiska uruchamiające niezaufany kod w tym samym procesie co logika aplikacyjna.

Kontekst / historia

isolated-vm to popularny projekt open source używany w usługach automatyzacji, platformach pluginów, środowiskach wielodostępnych oraz rozwiązaniach typu code execution. W wielu architekturach biblioteka ta pełni rolę granicy bezpieczeństwa między kodem użytkownika a resztą aplikacji.

Publicznie dostępne informacje wskazują, że podatność została odkryta przez badacza z Endor Labs. Następnie problem opisano w publicznym advisory, przy czym część szczegółów dotyczących eksploatacji ograniczono, aby utrudnić szybkie przygotowanie gotowych narzędzi ataku.

To ważny przypadek, ponieważ nie chodzi jedynie o błąd wpływający na stabilność. Luka podważa podstawowe założenie, że kod działający w sandboxie pozostaje skutecznie odseparowany od procesu hosta.

Analiza techniczna

Rdzeń podatności znajduje się w klasie ExternalCopy, która odpowiada za serializację i odtwarzanie obiektów JavaScript między różnymi izolatami V8. Ponieważ izolaty utrzymują osobny stan i własną pamięć, bezpośrednie przekazywanie obiektów nie jest możliwe. Właśnie dlatego biblioteka implementuje dodatkową warstwę C++ obsługującą transfer danych.

Zgodnie z analizą badaczy problem wynika z błędu type confusion w obsłudze opcji transferList w ExternalCopy. Tego rodzaju wada powoduje, że program traktuje strukturę danych jak obiekt innego typu niż rzeczywisty, co może prowadzić do nieprawidłowych operacji na pamięci.

W praktyce otwiera to drogę do nadpisywania lub odczytu pamięci w sposób nieprzewidziany przez projektantów biblioteki. Szczególnie niebezpieczne jest to, że łańcuch ataku może zostać uruchomiony z użyciem standardowo przekazywanego obiektu ivm.Reference, czyli mechanizmu umożliwiającego ograniczoną interakcję sandboxa z hostem.

Badacze wykazali możliwość przejścia od kontrolowanego wywołania awarii procesu do przejęcia przepływu sterowania po stronie hosta. Oznacza to, że problem nie leży w samym mechanizmie V8 Isolate, lecz w warstwie integracyjnej odpowiedzialnej za bezpieczne przenoszenie wartości przez granicę izolacji.

Z punktu widzenia bezpieczeństwa aplikacyjnego jest to klasyczny przykład sytuacji, w której bezpieczny komponent bazowy zostaje osłabiony przez kod łączący różne elementy systemu. Takie mosty komunikacyjne, serializatory i natywne rozszerzenia często stają się krytyczną powierzchnią ataku.

Konsekwencje / ryzyko

Najprostszym skutkiem wykorzystania luki jest wywołanie awarii procesu hosta, a więc skuteczny denial of service. W środowiskach wielodostępnych może to oznaczać restart usługi, utratę zadań klientów lub spadek dostępności platformy.

Znacznie groźniejszy jest scenariusz ucieczki z sandboxa. Jeżeli model bezpieczeństwa aplikacji zakłada, że kod klienta działa wyłącznie w odizolowanym środowisku, przełamanie tej granicy może umożliwić wpływ na pamięć i logikę procesu hosta.

W konsekwencji atakujący może potencjalnie uzyskać wykonanie kodu z uprawnieniami procesu aplikacyjnego. To z kolei może prowadzić do dostępu do sekretów, zmiennych środowiskowych, tokenów usługowych, danych klientów oraz innych zasobów znajdujących się w tym samym kontekście uruchomieniowym.

Ryzyko jest szczególnie wysokie w usługach uruchamiających kod użytkownika, platformach SaaS z funkcjami skryptowymi, systemach CI/CD, rozwiązaniach opartych o pluginy oraz wszędzie tam, gdzie niezaufany JavaScript współdzieli proces z wrażliwą logiką biznesową.

Rekomendacje

Najważniejszym krokiem jest natychmiastowa aktualizacja biblioteki isolated-vm do wersji zawierających poprawkę. Organizacje powinny również zidentyfikować wszystkie miejsca, w których pakiet występuje bezpośrednio lub jako zależność tranzytywna.

Przeprowadzić inwentaryzację aplikacji i obrazów kontenerów wykorzystujących isolated-vm.
Zaktualizować środowiska do wersji 6.2.0 lub 7.0.1 i nowszych, zależnie od linii wydawniczej.
Ograniczyć uruchamianie niezaufanego kodu w tym samym procesie co komponenty o wysokim poziomie zaufania.
Rozważyć separację procesową lub kontenerową zamiast polegania wyłącznie na izolacji wewnątrz V8.
Monitorować awarie procesów, błędy segmentacyjne i nietypowe zachowania usług Node.js.
Zminimalizować zakres obiektów ivm.Reference przekazywanych do sandboxa.
Przeskanować zależności pod kątem advisory GHSA-864f-rcv7-6rh4.
Zweryfikować, czy procesy obsługujące sandbox działają z minimalnymi uprawnieniami systemowymi.

W praktyce dodatkowe ograniczenia systemowe, takie jak separacja uprawnień, ograniczenie dostępu do sieci, sekretów i systemu plików, mogą znacząco zmniejszyć skutki ewentualnego udanego ataku.

Podsumowanie

Nowa luka w isolated-vm to ważne ostrzeżenie dla zespołów, które traktują sandbox JavaScript jako twardą i samowystarczalną granicę bezpieczeństwa. Problem nie wynika z naruszenia samego V8 Isolate, lecz z błędu w mechanizmie transferu danych między izolowanymi kontekstami.

Dla organizacji korzystających z Node.js priorytetem powinno być szybkie wdrożenie poprawek, ponowna ocena modelu zagrożeń oraz ograniczenie zaufania do pojedynczej warstwy ochrony. Bezpieczne uruchamianie niezaufanego kodu wymaga bowiem nie tylko poprawnego silnika, ale także bezpiecznej serializacji, minimalnych uprawnień i dodatkowej separacji wykonania.