Visual Studio Code legt pauze van 2 uur op voor updaten van npm-packages

Visual Studio Code legt een standaardpauze van 2 uur op voor het automatisch updaten van nieuwe extensies zoals npm-packages. Dit volgt op incidenten met npm-packages, waarmee hackaanvallen zijn uitgevoerd. Microsoft hanteert wel uitzonderingen voor de verplichte pauze.

De nieuwste release (versie 1.123) van Microsofts ontwikkelsoftware Visual Studio Code brengt een standaardvertraging van 2 uur voor het automatisch updaten van extensies die recent zijn gepubliceerd. Deze pauze geeft volgens Microsoft een extra laag bescherming tegen problematische of mogelijk gecompromitteerde releases. De afgelopen maanden zijn npm-packages gehackt zodat kwaadwillenden vergaande aanvallen konden uitvoeren.

De nu ingestelde standaardpauze is van toepassing als automatische updates zijn ingeschakeld. Gebruikers kunnen de pauze opheffen door zelf op de Update-knop te klikken.

Geldt niet voor Microsoft zelf

In bepaalde gevallen geldt de 'afkoeltijd' van 2 uur niet. Dit is het geval voor extensies van 'vertrouwde uitgevers zoals Microsoft, GitHub en OpenAI', merkt GitHub-eigenaar Microsoft op in een voetnoot. Voor die extensies worden automatische updates onmiddellijk uitgevoerd. Een recente grote supplychainaanval via npm-packages gebeurde juist via een vertrouwde uitgever: Linux-aanbieder Red Hat.

Visual Studio Code. Bron: Microsoft

Reacties (24)

[Slonzo]

Volgens de changelog gaat het om extensions in VS Code, dus NIET om npm packages.
https://code.visualstudio.com/updates/v1_123#_editor-experience

[donald_dick]

2 uur is wel een beetje aan de korte kant?

[xFeverr]

pnpm laat je een dag wachten standaard, dan is 2 uur wel kort ja.

Maar het voelt ook als lapmiddel. Als iedereen 2 uur wacht dan is het effect toch precies hetzelfde?

[kuurtjes]

Op deze manier heeft de originele developer wel 2 uur de tijd om het terug te draaien. Veel te kort want je kan als aanvaller gewoon wachten tot als hij gaat slapen, maar het kan wel wat mensen redden.

[Niemand_Anders]

Misschien is een betere optie dat een package release niet automatisch publiek wordt gemaakt, maar dat je die moet bevestigen op de website icm MFA token.

Zodra er een release is aangemaakt, krijg je dan gewoon een mailtje om de release te bevestigen.

[watercoolertje]

De truuc is dus om langer te wachten dan de rest maar niet te lang

Je hebt natuurlijk helemaal gelijk, als iedereen uitstelt is niemand de 'tester'...

[closefuture]

Als iedereen 2 uur wacht dan is het effect toch precies hetzelfde?

Niet dat ik denk dat het echt heel veel uitmaakt maar waarschijnlijk is de gedachte dat als er binnen 2 uur ontdekt word dat iemands NPM account gehacked is de besmette versie nog teruggetrokken kan worden.

[Henk Poley]

Het probleem met Axios was overigens al binnen een paar minuten gevonden: https://x.com/dez_/status/2038956586706542741

Blijft nog een ding of je npm binnen die 2 uur kan bewegen om er op te reageren.

[Wailing_Banshee]

Ja, het zou mooier zijn als je dat zou kunnen instellen. En ook kunt aangeven dat je niemand vertrouwd...

[BrianHD]

Het blijft dweilen met de kraan open. Als attacker zet je dan toch gewoon een datetime in de toekomst die sowieso voorbij de window van VS Code is alvorens je je payload activeert?

[Christoxz]

Maar de logica voor je 'payload activatie' is dan al 2 uur openbaar en als het dus binnen die 2 uur is gespot, kan de update terug getrokken worden.

Dweilen met de kraan open? Nah. Kat en muis spel, ja.

[gimbal]

Ja maar dat is het ding. Als je geen oplossing hebt voor de kraan die niet dicht wil dan... ga je maar dweilen. Het is alsnog beter dan niets doen.

[Rhizix]

Man man man, wie nu nog npm gebruikt ipv pnpm vraagt er zelf wel om zou ik zeggen.
2 uur lijkt me trouwens wel zeer kort?

[Christoxz]

De VS extensies updates hebben niet veel te maken met npm of pnpm.

[PixelPionier]

Vaak wordt er bij dat soort aanvallen misbruik gemaakt van een gecompromiteerd account. Goed om te weten dat accounts van Microsoft, Github en OpenAI kennelijk niet gecompromiteerd kunnen worden.

[daantje.nl]

Word gecompenseerd met downtime. Wat down is, kan niet gehacked worden... /s

[sspiff]

Leuk, maar:

• 2 uur wachten lijkt me niet voldoende. Het duurt vaak langer voor een aanval ontdekt wordt, zeker bij kleinere bedrijven
• Grote, "vertrouwde" spelers zijn niet immuun, zoals de recent hack van Red Hat laat zien

Het blijft mij een mysterie waarom niemand een meer betrouwbare package manager voor Node / JavaScript / TypeScript bouwt.

Om The Onion te parafraseren: "There's no way to prevent this, says the only package manager where this regularly happens".

[NoTechSupport]

Helemaal met je eens, behalve je parafrasering, het is ook wel de grootste package manager. Wat voor features moeten ze van andere package managers overnemen om dit te voorkomen?

Ik denk dat verdacht gedrag op accounts detecteren (inloggen vanuit een ander deel van de wereld) zou kunnen helpen.

[ge-flopt]

Ik zie 2 problemen:
- 2 uur voordat je automatisch een nieuw NPM package krijgt. Wat wordt er in die 2 uur met dat pakket gedaan? Gescanned oid op kwaadwillende software, of iets anders?
- Vals gevoel van zekerheid. Je laat mensen denken dat er iets met het package gedaan is, terwijl ik dit gewoon er niet uit haal dat dit ook daadwerkelijk gedaan wordt.

[eborn]

- Er wordt niets mee gedaan, maar de hoop is dat er vanuit de open source community iemand binnen die 2 uur er naar kijkt en denkt: dit klopt niet.
- De huidige installatie flow heeft geen enkele zekerheid, maar er is werkelijk (bijna) niemand die alle dependencies van alle packages gaat nalopen. Helemaal in het geval van dev omgevingen waar nog eens veel meer packages op geinstalleerd worden die ook allemaal regelmatig van versie veranderen.

[XC9]

Waarom zegt de titel van het artikel "npm packages"? Ik zou bijna zeggen dat het click-bait is.

[TimoDimo]

Inderdaad, dit gaat toch om alle VS Code extensies? Of snap ik het nu verkeerd?

[Stukfruit]

Geldt niet voor Microsoft zelf

En zo hebben ze, opzettelijk of niet, weer een extra hoepel toegevoegd waar je als je niet "vertrouwd" bent doorheen moet springen en wat eventueel misbruikt kan worden.

Jammer. Het klonk goed tot dit stukje.

[joco]

is het probleem niet echt dat packages die je installeerd plotseling gewoon code kunnen gaan executeren wanneer ze geinstalleerd worden?

Dat is toch het grote probleem eigenlijk? Volgens mij moet je gewoon dat standaard niet toe laten tot een gebruiker zegt ok van dit pakket mag je het wel doen (en dan een fingerprint van dat pakket op pakken met wat ie wil executeren en dan dan in de package_lock.json plaatsen)

Op het moment dat je dan dat ergens anders installeerd (op je build server) dan mag dat alleen dat direct executeren als die fingerprint dus in de package_lock file staat.. zolang dat niet het geval is moet een gebruiker dan dus echt zelf ja tegen zeggen.. (dus npm of welke package manager dan ook is hier verantwoordelijk voor)

Als je dan plotseling een update krijgt, voldoet de fingerprint niet meer en moet de gebruiker dat dus eerst weer "Accept and store" tegen zeggen.