Een isolated-vm kwetsbaarheid maakt duidelijk dat een “sandbox” niet automatisch een garantie is voor volledige afscherming. Onderzoekers meldden een probleem in de Node.js library isolated-vm dat in bepaalde situaties kan leiden tot remote code execution (RCE) op het host-systeem. Dat is vooral zorgwekkend omdat isolated-vm bedoeld is om onbetrouwbare JavaScriptcode veilig te laten draaien.
In dit artikel leggen we uit wat er misging, waarom de kwetsbaarheid draait om het kopiëren van data tussen geïsoleerde V8-instanties, en welke acties je vandaag kunt nemen als je deze component gebruikt.
Wat is isolated-vm en waarom wordt het gebruikt?
isolated-vm stelt ontwikkelaars in staat om gebruik te maken van de V8 “Isolate”-interface. Elke Isolate draait als een volledig gescheiden V8-instantie met eigen heapgeheugen, eigen uitvoeringstoestand en een aparte garbage collector. In theorie kun je daardoor meerdere stukjes JavaScript op één machine draaien zonder containers of virtuele machines nodig te hebben.
In de praktijk wordt isolated-vm vaak ingezet om onvertrouwde code toch te laten uitvoeren, bijvoorbeeld in applicaties waar gebruikersscripts of extensies mogen draaien. De kernideeën zijn daarbij isolatie en het gecontroleerd uitwisselen van gegevens tussen omgevingen.
De kern van de isolated-vm kwetsbaarheid: type confusion in ExternalCopy
De kwetsbaarheid heeft betrekking op een bug met type confusion in een functie die data kopieert tussen Isolates. Concreet gaat het om de ExternalCopy-functionaliteit: die serializeert data in de ene Isolate en reconstrueert die in de andere.
Er is nog geen CVE-nummer toegewezen aan het probleem, maar de impact wordt serieus beschreven. Een geslaagde exploit kan resulteren in een crash (denial-of-service) of in misbruik dat leidt tot controle-flow hijacking van het hostproces. Daarmee ontstaat het potentiële pad naar RCE op de host.
Waarom het kopiëren van data hier zo belangrijk is
Voor performance maakt ExternalCopy gebruik van een transferList. In plaats van alle data via een “standaard” pad te kopiëren, worden grotere ArrayBuffers op een lijst gezet. De onderliggende geheugenblokken worden vervolgens overgedragen door het bronbuffer los te koppelen en door te geven aan de bestemming.
Het probleem zat in hoe de reconstructie de transferList afhandelde: de reconstructor liep bij het verwerken tweemaal over de byte-array-lijst. Daarbij werd in de tweede iteratie vertrouwd op wat eerder “werd gezien” in de eerste iteratie, terwijl een aanvaller de omstandigheden kon beïnvloeden.
TOCTOU en manipulatie via getters
Onderzoekers wijzen erop dat het itereren over de JavaScript array in de transferList niet per se dezelfde waarden teruggeeft tussen de twee passes. Dat komt doordat een element kan worden gedefinieerd als een getter, waardoor de waarde bij elk bezoek anders kan uitpakken.
Dit opent de deur naar een time-of-check/time-of-use (TOCTOU)-zwakte: eerst wordt iets gecontroleerd, later wordt er opnieuw gebruik van gemaakt terwijl de inhoud ondertussen anders kan zijn. In de beschreven aanpak kan de aanvaller daardoor een attacker-controlled pointer laten derefereren.
Wie kan misbruik maken? Host en “caller-influenced” arrays
Op papier ligt de toegang tot de ExternalCopy-constructor bij de host. Toch kan een guest—dus de code die in de sandbox draait—de kwetsbaarheid triggeren door slim gebruik te maken van het mechanisme waarmee de host iets aan de sandbox aanbiedt.
De advisory beschrijft dat een guest een ivm.Reference kan gebruiken om een schadelijke transferList samen te stellen en de trigger te activeren.
De impact is daarmee breed: volgens het bericht zijn embedders die onbetrouwbare code in een isolate uitvoeren en zelfs maar één Reference delen, mogelijk geraakt. Ook hostcode die een array doorgeeft die door een afnemer/behandelaar kan worden beïnvloed (caller-influenced), is direct vatbaar als die array als transferList eindigt.
Gevolgen: van crash tot controle over de host
Het exploitpad dat wordt geschetst, leidt in de meest directe gevallen tot een crash. Maar ernstiger is dat het ook kan omslaan naar controle-flow hijacking van het hostproces. Juist omdat isolated-vm in een Node.js-hostomgeving draait, betekent “hostcontrole” dat een aanvaller mogelijk verder kan dan alleen de sandbox.
Het advies is dan ook: behandel deze isolated-vm kwetsbaarheid als een probleem dat je niet moet afwachten.
Welke versies zijn gepatcht?
De patches voor de kwetsbaarheid zijn opgenomen in isolated-vm 6.2.0 en isolated-vm 7.0.1. Dat betekent dat je actie moet nemen om naar ten minste één van deze versies (of hoger) te upgraden.
Het is daarbij niet voldoende om alleen te “vinken” dat de library aanwezig is. Controleer ook of je build- of dependency-keten exact de gepatchte versie bevat. Een lockfile en een reproducible build helpen om dit betrouwbaar te verifiëren.
Wat veranderde er volgens de toelichting van de onderzoekers?
De toelichting maakt duidelijk dat de kwetsbaarheid niet in de “logica op JavaScript-niveau” zat, maar in de native glue code: de C++ binding die waarden serializeert en over de boundary heen reconstruueert.
Omdat die laag in een geheugen-onveilige taal werkt en raw V8-handles en pointerinformatie manipuleert, ontstond er ruimte voor een fout die isolatie kon omzetten naar een escape. De correctie voorkomt dat user JavaScript kan draaien tijdens de copy-operatie, zodat de aanvaller de timing en waarden niet kan manipuleren.
Wat kun je nu doen in je omgeving?
Als je isolated-vm gebruikt om ontrusted code uit te voeren, pak dan deze stappen op:
- Upgrade isolated-vm naar versie 6.2.0 of 7.0.1 (of hoger) en check je dependency tree.
- Identificeer waar transferList wordt samengesteld. Kijk welke arrays door de applicatie kunnen worden beïnvloed door externe input.
- Beperk gedeelde References. Hoe minder exposure richting de sandbox, hoe kleiner het aanvalsvlak.
- Test je embedder-case. Vooral als je embedder untrusted code draait en daarnaast data of buffers uitwisselt tussen isolates.
Wil je dit koppelen aan breder patch- en response-werk? Lees dan ook hoe je in je security-operaties sneller kunt reageren op wijzigingen en signalen met Wazuh AI voor sneller reageren in je SOC. Dat helpt vooral bij het tijdig detecteren van impact zodra een library-versie wijzigt of als er anomalieën optreden.
Vergelijkbare les uit andere patch-incidenten
Dit soort kwetsbaarheden laat zien dat “veiligheidscomponenten” in dezelfde dependency-keten kunnen falen op onverwachte plaatsen: bindings, copy-mechanismen, en performance-optimalisaties. Dat is terugkerend patroon in supply-chain en dependency-gerelateerde security.
Als je organisatie afhankelijk is van meerdere leverancierscomponenten, is het ook nuttig om patchbeslissingen te structureren. Bijvoorbeeld door alle kritieke CVE’s en advisories te clusteren per stack en per release-window. Zo verklein je de kans dat één gemiste dependency een kettingreactie veroorzaakt.
Voor een voorbeeld van het belang van tijdige updates in concrete vendor-ecosystemen kun je parallel kijken naar recente patchrondes, zoals Microsoft 22 security patches met updates op hoogst mogelijke CVSS.
Conclusie: treat isolated-vm kwetsbaarheid als urgent
De isolated-vm kwetsbaarheid draait om een type confusion in ExternalCopy, waarbij het kopiëren van data tussen V8-isolates misbruikt kan worden via een TOCTOU-zwakte in de verwerking van de transferList. In het ergste scenario kan dit leiden tot een escape met controle over het hostproces, en daarmee mogelijk RCE.
De kernactie is eenvoudig maar dringend: upgrade naar isolated-vm 6.2.0 of 7.0.1 en controleer hoe jouw applicatie References en caller-influenced arrays doorgeeft aan de copy-functies. Daarmee verlaag je het risico aanzienlijk en herstel je de isolatie-intentie waar isolated-vm voor bedoeld is.
Bron: https://www.securityweek.com/critical-isolated-vm-vulnerability-leads-to-rce-on-host/
