Wprowadzenie do problemu / definicja
W bibliotece isolated-vm dla Node.js wykryto krytyczną podatność, która może umożliwić ucieczkę z izolowanego środowiska wykonywania kodu JavaScript i przejęcie kontroli nad procesem hosta. Problem dotyczy mechanizmu odpowiedzialnego za bezpieczne uruchamianie niezaufanego kodu w odseparowanych instancjach silnika V8.
To szczególnie istotne dla organizacji, które traktują sandbox oparty na isolated-vm jako podstawową warstwę ochrony przy przetwarzaniu kodu dostarczanego przez użytkowników, klientów lub zewnętrzne integracje.
W skrócie
- Podatność dotyczy mechanizmu ExternalCopy w bibliotece isolated-vm.
- Błąd typu type confusion może prowadzić do obejścia izolacji i wykonania kodu na hoście.
- Źródłem problemu jest niespójność w obsłudze transferList podczas kopiowania danych między izolatami V8.
- Skutki obejmują awarię procesu, przejęcie przepływu wykonania oraz potencjalne zdalne wykonanie kodu.
- Poprawki wprowadzono w wersjach 6.2.0 oraz 7.0.1 biblioteki isolated-vm.
Kontekst / historia
isolated-vm jest szeroko stosowaną biblioteką w ekosystemie Node.js do uruchamiania niezaufanego kodu JavaScript w osobnych izolatach V8. Rozwiązanie to jest wykorzystywane między innymi w platformach rozszerzeń, środowiskach serverless, systemach automatyzacji, parserach skryptów użytkownika oraz aplikacjach SaaS obsługujących kod klientów.
Model bezpieczeństwa tego rozwiązania opiera się na logicznej separacji pamięci, stanu wykonania i mechanizmów garbage collection zapewnianej przez V8. W praktyce jednak poziom ochrony zależy również od natywnej warstwy pośredniczącej, która obsługuje komunikację i przekazywanie danych pomiędzy hostem a sandboxem. To właśnie w tej warstwie wykryto błąd podważający założenia izolacji.
Analiza techniczna
Podatność wynika z błędu type confusion w obsłudze ExternalCopy, czyli mechanizmu używanego do serializacji danych w jednym izolacie i ich odtworzenia w drugim. Dla poprawy wydajności biblioteka wykorzystuje transferList, co pozwala przekazywać większe bufory bez pełnego kopiowania pamięci.
Problem pojawia się podczas przetwarzania listy transferu danych. Rekonstruktor przechodzi po strukturach bajtowych dwukrotnie, a drugi przebieg ufa wynikom pierwszego. Taki model okazuje się niebezpieczny, gdy elementy listy są definiowane dynamicznie, na przykład z użyciem getterów zwracających różne wartości przy kolejnych odczytach. W efekcie dochodzi do klasycznego scenariusza time-of-check/time-of-use.
Atakujący działający wewnątrz sandboxa może wykorzystać mechanizm ivm.Reference do przygotowania złośliwej struktury transferList i uruchomienia podatnego przepływu. To może doprowadzić do dereferencji wskaźnika kontrolowanego przez napastnika, a w dalszej kolejności do awarii procesu, naruszenia granicy izolacji lub przejęcia sterowania wykonaniem.
Kluczowe jest to, że problem nie leży w samym modelu izolatów V8, lecz w natywnej warstwie C++, która operuje na pamięci niskiego poziomu, uchwytach V8 i wskaźnikach. Właśnie ta warstwa, mająca wzmacniać bezpieczeństwo, stała się punktem potencjalnej ucieczki z sandboxa.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem luki jest możliwość zdalnego wykonania kodu na hoście. W środowiskach, które uruchamiają niezaufany kod JavaScript przez isolated-vm, oznacza to ryzyko pełnego przejęcia procesu hosta, a w sprzyjających warunkach także dalszej eskalacji uprawnień.
Zagrożenie jest szczególnie wysokie w usługach wielodostępnych, platformach uruchamiania kodu klientów, systemach workflow oraz aplikacjach, w których sandbox był traktowany jako główna granica bezpieczeństwa. Nawet jeśli pełne wykonanie kodu nie powiedzie się w każdym scenariuszu, podatność może zostać wykorzystana do wywołania denial of service poprzez wymuszenie awarii procesu.
Szczególnie narażone są implementacje, które udostępniają do sandboxa referencje do obiektów hosta lub przekazują do transferList dane zależne od użytkownika. Taki wzorzec integracji jest częsty, dlatego wiele wdrożeń może być praktycznie podatnych na wykorzystanie.
Rekomendacje
Najważniejszym krokiem jest natychmiastowa aktualizacja biblioteki isolated-vm do wersji 6.2.0 lub 7.0.1 albo nowszej, zgodnej z używaną gałęzią aplikacji. Należy przy tym sprawdzić zarówno zależności bezpośrednie, jak i pośrednie.
- przeprowadzić inwentaryzację usług uruchamiających niezaufany kod JavaScript;
- ograniczyć ekspozycję obiektów hosta do sandboxa do absolutnego minimum;
- unikać przekazywania struktur zależnych od użytkownika do mechanizmów transferu pamięci;
- uruchamiać procesy wykonujące niezaufany kod z minimalnymi uprawnieniami systemowymi;
- wdrożyć dodatkowe warstwy izolacji, takie jak kontenery, separacja użytkowników systemowych, seccomp, AppArmor lub podobne mechanizmy;
- monitorować awarie procesów Node.js, nietypowe restarty usług oraz anomalie pamięci;
- rozszerzyć testy bezpieczeństwa o scenariusze obejścia sandboxa i fuzzing warstwy integracyjnej.
Organizacje powinny również przyjąć podejście defense-in-depth. Sandbox biblioteczny nie powinien być jedyną barierą ochronną wszędzie tam, gdzie przetwarzany jest niezaufany kod.
Podsumowanie
Luka w isolated-vm pokazuje, jak groźne mogą być błędy w warstwach pośrednich łączących bezpieczny model wysokiego poziomu z natywną obsługą pamięci. Nawet jeśli same izolaty V8 pozostają silnym mechanizmem separacji, pojedynczy błąd type confusion w kodzie C++ może całkowicie osłabić ochronę sandboxa.
Dla zespołów bezpieczeństwa, administratorów platform i specjalistów DevSecOps to wyraźny sygnał, że uruchamianie niezaufanego kodu wymaga nie tylko szybkiego zarządzania poprawkami, ale także wielowarstwowej architektury zabezpieczeń i regularnej oceny ryzyka.