Podatności vm2

vm2 do wersji 3.12.0 udostępnia funkcję crypto.setFips() z Node.js niezaufanemu kodowi gościa, gdy osadzający jawnie zezwoli na wbudowany moduł crypto dla NodeVM. Sanitizer nie blokuje crypto.setFips, co pozwala kodowi gościa zmienić tryb FIPS całego procesu hosta, naruszając izolację NodeVM. Naprawiono w vm2 3.12.1.

vm2, sandbox do uruchamiania niezaufanego kodu JavaScript, w wersjach do 3.11.3 włącznie używa przypisania indeksu z przechodzeniem po prototypie w defaultSandboxPrepareStackTrace, co pozwala kodowi w sandboxie przechwycić linie stosu błędów. Luka ma niski wpływ (kanał boczny informacji) i została naprawiona w wersji 3.11.4.

W vm2 w wersjach od 3.11.4 do 3.11.6 niekompletnie filtrowano zarejestrowane wewnętrzne symbole Node.js na granicy piaskownicy. Filtry w lib/setup-sandbox.js oraz sprawdzenia symboli i pułapki zapisu w lib/bridge.js używają stałej listy znanych niebezpiecznych symboli, pomijając nodejs.stream.disturbed i nodejs.stream.errored, które są eksponowane na prototypach WebStream w nowszych wersjach Node.js. Gdy osadzający udostępnia obiekt WebStream i moduł stream/web piaskownicy, kod piaskownicy może uzyskać prawdziwe symbole hosta i użyć ich jako kluczy zapisu na obiektach strumieni hosta, uszkadzając widoczny dla hosta stan strumienia. Może to obejść logikę hosta opartą na publicznych pomocnikach stanu strumienia Node.js. Nie jest to prymityw wykonania kodu hosta w zgłoszonym dowodzie podatności. To niekompletna poprawka wcześniejszego problemu filtrowania symboli nodejs.*. Naprawiono w vm2 3.11.7.

Podatność w narzędziu CLI vm2 (przed wersją 3.11.7) umożliwia ucieczkę z piaskownicy i wykonanie dowolnego kodu w procesie Node.js hosta. Atakujący może dostarczyć złośliwy plik skryptu, który używa require(__filename) do ponownego wykonania siebie w środowisku hosta, omijając izolację piaskownicy i uzyskując dostęp do modułów takich jak fs i child_process.

vm2 w wersjach przed 3.11.7 zawiera podatność obejścia listy dozwolonych modułów w funkcji isPathAllowedForModule, która używa dopasowania prefiksu ciągu znaków zamiast porównania z granicami ścieżki. Atakujący może uzyskać dostęp do niedozwolonych pakietów dzielących prefiks z modułami z listy dozwolonych, wykonując względne require z dozwolonych pakietów przy wyłączonym ładowaniu tranzytywnym.

vm2 w wersjach od 3.11.0 do 3.11.6 ujawnia bezwzględne ścieżki systemu plików hosta do kodu w sandboxie poprzez formatowanie stosu błędów. Kod dostarczony przez atakującego może wymusić na transformatorze źródła hosta zgłoszenie SyntaxError i odczytać właściwość .stack błędu, omijając redakcję ścieżek hosta po stronie sandboxa. Domyślne konfiguracje new VM() i new NodeVM() są podatne bez specjalnych opcji.

Podatność w bibliotece vm2 (npm) w wersjach do 3.12.0 umożliwia ucieczkę z sandboxa w klasach VM i NodeVM. Gdy aplikacja udostępnia funkcję hosta zwracającą Promise z innej domeny, mechanizm czyszczący odrzucenia nie obejmuje wszystkich przypadków, a kod w sandboxie może podmienić właściwości Promise i uzyskać nieprzefiltrowany obiekt hosta. Może to prowadzić do wykonania dowolnego kodu na hoście. Problem naprawiono w wersji 3.12.1.

Podatność w NodeVM biblioteki vm2 przed wersją 3.12.1 umożliwia ucieczkę z sandboxa, ponieważ lista zablokowanych modułów DANGEROUS_BUILTINS nie zawiera child_process, mimo że blokuje inne moduły uruchamiające procesy. Atakujący może zażądać modułu child_process i wykonać dowolne polecenia na hoście, gdy NodeVM jest skonfigurowany z builtin:['*'] lub jawnym zezwoleniem na child_process.

Podatność w vm2 do wersji 3.12.0 (naprawiona w 3.12.1) dotyczy nieprawidłowej obsługi odbiorcy `this` o wartości null w pułapce apply mostka. Gdy kod w sandboxie wywołuje funkcję hosta w trybie nieścisłym bez odbiorcy, niezdefiniowany odbiorca jest przekazywany do hosta, a V8 podstawia globalny obiekt domeny hosta. vm2 zwraca ten obiekt do sandboxa, co umożliwia pełną ucieczkę i dostęp do procesu. Wymaga to, aby aplikacja udostępniała co najmniej jedną funkcję hosta w trybie nieścisłym.

W vm2 przed wersją 3.11.6 konfiguracja builtin: ['*'] nie ogranicza dostępu do modułów os i dns, co pozwala kodowi w piaskownicy na odczytanie informacji o procesie hosta i topologii sieci. Atakujący mogą użyć funkcji dns.setServers(), aby przejąć globalny resolver DNS procesu hosta.

W vm2 do wersji 3.11.6 włącznie, w polityce require NodeVM, wpisy z prefiksem node: nie są poprawnie normalizowane, co pozwala ominąć listę zakazanych modułów. Atakujący w piaskownicy może uzyskać dostęp do modułu child_process, co daje możliwość wykonywania poleceń w systemie.

W wersjach vm2 od 3.10.1 do 3.11.6 istnieje możliwość ucieczki z piaskownicy za pomocą WebAssembly.compileStreaming i instantiateStreaming. Atakujący może uzyskać dostęp do obiektu process w środowisku Node.js 26, co daje pełną kontrolę nad procesem hosta.

W wersjach vm2 przed 3.11.8 występuje luka umożliwiająca ucieczkę z piaskownicy przez obiekty console._stdout i console._stderr. Atakujący może nadpisać metodę emit w EventEmitter.prototype i wykonać kod w procesie hosta, omijając ograniczenia generowania kodu.

W wersjach vm2 od 3.11.0 do 3.11.8 nie są odpowiednio chronione prototypy TypedArray i ArrayBuffer przed modyfikacją przez kod w piaskownicy. Atakujący może zmienić prototypy, co wpływa na tablice hosta i może prowadzić do nieautoryzowanych działań.

vm2 w wersjach przed 3.11.7 zawiera błąd nieprawidłowej autoryzacji w mechanizmie sprawdzania listy dozwolonych pakietów zewnętrznych, który używa niedokładnego dopasowania podciągu zamiast pełnej walidacji granic nazwy pakietu. Atakujący mogą obejść listę dozwolonych, żądając pakietu o kolidującej nazwie zawierającej podciąg dozwolonego pakietu, co powoduje załadowanie i wykonanie nieautoryzowanych pakietów hosta w kontekście hosta.

vm2 w wersjach od 3.9.6 do 3.11.6 jest podatny na obejście listy dozwolonych wbudowanych modułów NodeVM, co umożliwia ucieczkę z sandboxa w Node.js 24 i nowszych, gdy osadzający jawnie zezwoli na wbudowany moduł node:test. W Node.js 24+ module.builtinModules ujawnia klucz node:test, który nie jest objęty ochroną DANGEROUS_BUILTINS vm2, a ponieważ requireImpl() usuwa tylko jeden prefiks 'node:', kod sandboxa wywołujący require('node:node:test') otrzymuje proxy do modułu hosta, a wywołania node:test.run() z atakującym kontrolowanym execArgv (np. --eval) wykonują dowolny kod JavaScript w nieograniczonym procesie hosta.

vm2 w wersjach przed 3.11.7 ujawnia współdzieloną pulę buforów Node (Buffer pool) kodowi w sandboxie, umożliwiając ujawnienie pamięci hosta używanej przez Buffer.from, Buffer.concat i powiązane alokacje. Kod w sandboxie może czytać i zapisywać bufory hosta, uzyskując ArrayBuffers z małych alokacji, co prowadzi do ujawnienia wrażliwych danych i potencjalnej odmowy usługi.

vm2 w wersjach przed 3.11.7 zawiera podatność na zdalne wykonanie kodu, gdy require.external jest włączone bez jawnego require.root wykluczającego node_modules. Kod w sandboxie może zażądać własnego pakietu vm2, utworzyć nieograniczoną instancję NodeVM i wykonać dowolne polecenia systemu operacyjnego hosta poprzez child_process.

vm2 w wersjach od 3.10.2 do 3.11.6 zawiera podatność na ucieczkę z sandboxa w Node.js 26, gdzie Promise.prototype.finally() omija zabezpieczenia vm2 z powodu nieaktualnego protectora PromiseThenLookupChain w V8 14.6. Atakujący mogą to wykorzystać, tworząc funkcję asynchroniczną zwracającą Promise z kontrolowanym przez atakującego konstruktorem Symbol.species, co pozwala dotrzeć do konstruktora Function hosta i obiektu process w celu wykonania dowolnego kodu.

vm2 w wersjach od 3.11.3 do 3.11.6 ujawnia moduł tls hosta kodowi w sandboxie NodeVM, umożliwiając atakującym wywołanie tls.setDefaultCACertificates() i zastąpienie certyfikatów CA w całym procesie. Atakujący z dostępem do dozwolonych wbudowanych modułów tls i url mogą użyć URLSearchParams do tworzenia tablic w domenie hosta i manipulacji magazynem zaufania TLS, co umożliwia klientom HTTPS hosta akceptowanie certyfikatów kontrolowanych przez atakującego.

vm2 w wersjach od 3.11.3 do 3.11.6 ujawnia rzeczywisty https.globalAgent procesu hosta kodowi w sandboxie, gdy NodeVM jest jawnie skonfigurowany do zezwalania na require('https'). Mimo że moduły hosta są opakowane w proxy tylko do odczytu, wywołania metod takie jak Agent.prototype.on() są przekazywane do obiektu hosta, więc kod sandboxa może zarejestrować nasłuchiwacz zdarzenia 'free' agenta. Gdy niezwiązane żądanie HTTPS hosta zwalnia połączenie z puli, nasłuchiwacz otrzymuje opcje żądania hosta i TLSSocket, co pozwala odczytać nagłówek Authorization, docelowy host/port, treści odpowiedzi oraz wysyłać uwierzytelnione żądania skradzionymi poświadczeniami.

vm2 w wersjach od 3.11.3 do 3.11.6 ujawnia moduł crypto hosta Node.js sandboxowi NodeVM, gdy wbudowany moduł crypto jest dozwolony. Mimo że moduł jest prezentowany przez rekurencyjne proxy tylko do odczytu, jego wywoływalne eksporty nadal wykonują się z uprawnieniami procesu hosta, więc kod sandboxa może wywołać crypto.setEngine() ze ścieżką do dostarczonej przez atakującego biblioteki natywnej, którą OpenSSL ładuje przez dynamiczny loader systemu, wykonując kod natywny w procesie hosta przed odrzuceniem walidacji symboli. Wykorzystanie wymaga tylko wbudowanego modułu crypto i prowadzi do ucieczki z sandboxa oraz wykonania dowolnego kodu natywnego.

vm2 w wersjach od 3.11.3 do 3.11.6 ujawnia moduł node:sqlite hosta Node.js kodowi w NodeVM, gdy ten wbudowany moduł jest dozwolony jawnie lub przez builtin: ['*']. Moduł jest opakowany w vm.readonly(), co uniemożliwia przypisywanie właściwości, ale pozostawia osiągalne funkcje o uprawnieniach hosta; dodatkowo resolver traktuje każde żądanie zaczynające się od 'node:' jako żądanie modułu rdzeniowego, a runtime usuwa tylko jeden prefiks 'node:', więc żądanie 'node:node:sqlite' rozwiązuje się do skonfigurowanego wpisu node:sqlite. Kod sandboxa może utworzyć DatabaseSync w pamięci z włączonym ładowaniem rozszerzeń i wywołać DatabaseSync.loadExtension() na bibliotece natywnej z niezaufanego pakietu, co daje wykonanie dowolnego kodu natywnego poza sandboxem z uprawnieniami procesu hosta.

vm2 3.11.6 jest podatny na ucieczkę z sandboxa prowadzącą do zdalnego wykonania kodu w procesie hosta Node.js. Poprawka dla GHSA-m283-3h24-438v jest niekompletna: brama w lib/bridge.js:1624 sprawdza tożsamość tylko bezpośredniego celu wywołania przy decyzji o przebudowie/sanityzacji odrzuconej wartości Promise hosta. Zarejestrowanie handlera odrzucenia przez Function.prototype.call lub .apply (np. p.then.call(p, undefined, cb)) sprawia, że przechwycony cel to Function.prototype.call hosta, więc sanitizer nie uruchamia się i surowy błąd hosta trafia do kodu sandboxa z nienaruszonymi właściwościami. Jeśli osadzający ujawni sandboxowi Promise z domeny hosta, która odrzuca z błędem Error zawierającym nieprymitywną właściwość odwołującą się do obiektu hosta (np. err.detail = process), niezaufany kod w sandboxie uzyskuje w pełni funkcjonalne proxy do tego obiektu hosta i może wykonywać dowolne polecenia z uprawnieniami procesu hosta.

vm2, sandbox do uruchamiania niezaufanego kodu Node.js, w wersjach 3.11.4–3.11.6 błędnie traktuje tablicę przekazaną jako opcja 'require' (np. require: []) jako prawidłową konfigurację, co omija zabezpieczenie przed zagnieżdżaniem. Atakujący może następnie zażądać modułu hosta vm2, utworzyć wewnętrzny NodeVM z wybraną listą dozwolonych wbudowanych modułów (np. child_process) i wykonać dowolne polecenia z uprawnienami procesu Node.js hosta, uciekając z sandboxa. Problem naprawiono w wersji 3.11.7.

vm2 w wersjach przed 3.11.8 zawiera niekompletną poprawkę sanityzacji Error.cause, która pozwala na ucieczkę z sandboxa, gdy obiekty AggregateError opakowane przez hosta są ponownie przetwarzane w ramach jednego przejścia obsługi wyjątku. Atakujący może wykorzystać obejście wykrywania cykli w handleException, aby uzyskać dostęp do nieoczyszczonych proxy hosta osadzonych w tablicy błędów, co umożliwia pełne zdalne wykonanie kodu i ujawnienie informacji o procesie z sandboxa.

vm2 to otwartoźródłowa piaskownica dla Node.js. Przed wersją 3.11.6, lib/bridge.js i lib/setup-sandbox.js nie blokują pośredniego wywołania przez Function.prototype.call wokół niebezpiecznych mutatorów prototypów hosta, co pozwala kodowi piaskownicy na zerwanie łańcucha prototypów i dotarcie do e.constructor.constructor w celu wykonania dowolnych poleceń na hoście. Problem naprawiono w wersji 3.11.6.

vm2 to otwartoźródłowa piaskownica dla Node.js. Przed wersją 3.11.6, funkcja handleException() w lib/setup-sandbox.js oczyszcza SuppressedError.error, SuppressedError.suppressed i AggregateError.errors, ale nie oczyszcza Error.cause, co pozwala kodowi piaskownicy uzyskać potężny obiekt hosta, taki jak process, z funkcji hosta, która rzuca błąd z tym obiektem jako przyczyną, a następnie wykonać dowolne polecenia na hoście. Problem naprawiono w wersji 3.11.6.

W vm2, przed wersją 3.11.4, występowała podatność na ucieczkę z piaskownicy, która umożliwiała wykonanie dowolnego kodu w procesie hosta podczas wykonywania nieufnego kodu z obsługą asynchroniczną. Problem ten został naprawiony w wersji 3.11.4.

vm2 to otwarte źródło vm/sandbox dla Node.js. Przed wersją 3.11.4, vm2 ma podatność na wyjście z piaskownicy, co pozwala atakującym na wykonanie dowolnych poleceń na systemie gospodarza.

vm2 to otwarte źródło vm/sandbox dla Node.js. W wersjach przed 3.11.4, NodeVM blokuje kilka niebezpiecznych wbudowanych funkcji Node.js, jednak lista zablokowanych elementów nie obejmowała process oraz inspector/promises, co pozwala na obejście tych ograniczeń.

W wersjach przed 3.11.4 biblioteka vm2 zawierała lukę, która pozwalała na obejście zabezpieczeń związanych z opcjami 'nesting: true' i 'require: false'. Sprawdzenie równości ścisłej w kodzie nie działało poprawnie, co umożliwiało wykorzystanie nieautoryzowanych wymagań.

vm2 to otwarte źródło vm/sandbox dla Node.js. Przed wersją 3.11.4, poprzez kombinację określonych wywołań, możliwe było uzyskanie konstruktora TypeError hosta, co pozwalało na ucieczkę z sandboxa i uruchamianie dowolnego kodu.

W bibliotece vm2 dla Node.js przed wersją 3.11.3 wykryto podatność umożliwiającą przechwycenie wyjątku hosta za pomocą wyrażenia yield* w asynchronicznym generatorze. Zamknięcie generatora funkcją return powoduje oczekiwanie na wartość, a wyjątki w then mogą być przechwycone i przekazane jako następna wartość do iteratora yield*, co pozwala na ucieczkę z sandboksa i wykonanie dowolnych poleceń na systemie.

Podatność w bibliotece vm2 dla Node.js umożliwia ominięcie sandboksa. Problem został naprawiony w wersji 3.11.2.

Podatność w bibliotece vm2 dla Node.js przed wersją 3.11.2 pozwala na ucieczkę z piaskownicy poprzez metodę neutralizeArraySpeciesBatch, która może wywołać kod po stronie hosta za pomocą gettera na prototypie tablicy. Umożliwia to atakującym uzyskanie obiektów hosta i funkcji Function, co prowadzi do wykonania dowolnych poleceń na systemie.

Podatność w bibliotece vm2 dla Node.js umożliwia ominięcie konfiguracji require w NodeVM z włączonym zagnieżdżaniem (nesting: true). Kod piaskownicy może zażądać modułu vm2, utworzyć nową instancję NodeVM z nieograniczonym require i wykonać dowolne polecenia systemowe na hoście.

Podatność w bibliotece vm2 dla Node.js umożliwia atakującemu ominięcie sandboksowania i dostęp do dowolnych prototypów obiektów. Problem został naprawiony w wersji 3.11.0.

Podatność w bibliotece vm2 dla Node.js (wersje 3.9.6 do 3.10.5) umożliwia atakującemu JavaScript działającemu w piaskownicy modyfikację prototypów hosta, takich jak Object.prototype, Array.prototype i Function.prototype. Dzieje się tak przez mostek, który udostępnia mutowalne proxy dla rzeczywistych prototypów hosta, a następnie przekazuje zapisy z piaskownicy do obiektów hosta za pomocą ReflectSet() i ReflectDefineProperty().

Podatność w vm2 przed wersją 3.11.0 pozwala na obejście listy dozwolonych modułów wbudowanych NodeVM. Gdy moduł 'builtin' jest dozwolony (nawet przez '*' wildcard), kod w sandboxie może użyć Module._load() do załadowania dowolnego modułu w kontekście hosta, omijając ograniczenia. Umożliwia to uruchomienie wykluczonych modułów, takich jak child_process, i zdalne wykonanie kodu.

Podatność w bibliotece vm2 dla Node.js przed wersją 3.11.0 umożliwia uzyskanie dostępu do obiektu hosta. Atakujący może wykorzystać różne metody, np. HostObject.getOwnPropertySymbols, aby uzyskać Symbol(nodejs.util.inspect.custom) i uciec z piaskownicy.

Podatność w bibliotece vm2 dla Node.js w wersji 3.10.4 umożliwia całkowite ominięcie sandboksa i wykonanie dowolnego kodu na hoście. Atakujący może uzyskać dostęp do obiektu procesu hosta i uruchamiać polecenia bez żadnej współpracy z systemem.

Podatność w bibliotece vm2 dla Node.js umożliwia atakującym ominięcie sandboksa i wykonanie dowolnego kodu poprzez mechanizm SuppressedError. Problem został naprawiony w wersji 3.11.0.

Podatność w bibliotece vm2 dla Node.js umożliwia ucieczkę z piaskownicy poprzez funkcję inspect. Atakujący może wykonać dowolne polecenia na hoście.

Podatność w bibliotece vm2 dla Node.js pozwala na obejście łatki dla CVE-2023-37466 i ucieczkę z piaskownicy VM2, co umożliwia wykonanie dowolnych poleceń na hoście. Problem został naprawiony w wersji 3.10.5.

VM2 to otwartoźródłowa maszyna wirtualna/piaskownica dla Node.js. Przed wersją 3.11.0 zawiera podatność umożliwiającą ucieczkę z piaskownicy, co pozwala atakującemu na wykonanie dowolnych poleceń na hoście.

vm2 to otwarte źródło vm/sandbox dla Node.js. W wersjach do i włącznie z 3.9.19, funkcja inspect w Node.js umożliwia atakującym ucieczkę z sandboxa i uruchamianie dowolnego kodu.

Biblioteka vm2, zaawansowane środowisko sandbox dla Node.js, zawiera krytyczne problemy bezpieczeństwa i nie powinna być używana w produkcji. W wersjach do 3.9.19 możliwe jest obejście sanitizacji handlerów `Promise`, co pozwala atakującym na ucieczkę z sandboxa i uruchomienie dowolnego kodu.

W vm2 w wersjach przed 3.11.2 nieprawidłowo ograniczono dostęp do globalnej zmiennej VM2_INTERNAL_STATE_DO_NOT_USE_OR_PROGRAM_WILL_FAIL. Atakujący może uzyskać dostęp do tego wewnętrznego obiektu stanu poprzez globalThis i pozyskać wrażliwe elementy wewnętrzne piaskownicy.

vm2 przed wersją 3.11.6 nie egzekwuje limitu bufferAllocLimit dla konstruktorów ArrayBuffer, SharedArrayBuffer i TypedArray, co pozwala atakującym alokować dowolną pamięć hosta. Atakujący mogą obejść limit alokacji bufora, używając tych wbudowanych funkcji V8 do wyczerpania pamięci procesu hosta i wywołania warunków braku pamięci.