Node.js-i turvauuendus: kas teie versioon saab veel turvapaiku?

Turvapaigad said ainult need release line'id, millel on veel tugi, ja turvalised on versioonid 22.23.4, 24.22.1 ja 26.12.1 või uuemad samas release line'is. Node.js 18 ja 20 on juba end of life'is, seepärast ei ole neil selles Node.js-i turvauuenduses turvapaika ega tulegi: kui teie rakendus töötab mõnel neist, tähendab uuendamine üleminekut teisele release line'ile.

Kolmapäeval, 21. oktoobril, andis Node.js-i projekt välja turbeväljalasked kõigile kolmele toetatud release line'ile, ja samal päeval andis PHP välja erakorralised turvapaigad turvanõrkustele, mis said nime PHP2Shell, aga need on kaks eraldi sündmust erineva tõsidusega. Node.js-i väljalase oli ette kuulutatud, projekt on hinnanud selle kõige tõsisemad turvanõrkused kõrgeks, mitte kriitiliseks, ja teadaandes ei ole mainitud ei ajutisi lahendusi ega rünnakuid päris keskkonnas. See ei luba uuendamist edasi lükata, aga nihutab tähelepanu: seekord on suurim risk mitte väljalaskes endas, vaid versioonides, mis seda ei saanud.

Mida oktoobri Node.js-i turvauuendus parandas

Node.js-i teadaandes on loetletud kümme turvanõrkust: neli on projekt hinnanud kõrgeks, kolm keskmiseks ja kolm madalaks, aga CVSS-hinnanguid projekt seekord ei avaldanud, seepärast kasutab see artikkel sedasama hinnangut.

Neist kõige tõsisem on CVE-2026-111497. Projekt nimetab seda Brotli dekooderi out-of-bounds write'iks, mis lubab koodi kaugkäitust (RCE), ja hindab seda kõrgeks. Brotli on pakkimisformaat, mille dekooder on Node.js-i sisse ehitatud, ja väljalaskemärkmetes on paik kirjeldatud muudatusena selles sisseehitatud teegis. Millist teed pidi turvanõrkuseni jõutakse, teadaanne ei ütle, ja ka Brotli arendajate paiga kirjeldus räägib ainult sellest, et vigane andmevoog tuvastatakse nüüd varem. Seepärast ei ole siin nimetatud konkreetseid funktsioone: kindlalt saab öelda ainult seda, et dekooderi viga puudutab kõige rohkem rakendusi, mis pakivad lahti Brotli andmeid allikast, mida nad usaldada ei saa.

Kolm muud turvanõrkust puudutavad TLS-sertifikaadi kontrolli, ja need ei ole üks ja seesama juhtum. Esimene, kõrge hinnanguga, puudutab ainult 26. ja 24. release line'i: hostname verification'ist saab mööda minna, kui IP-aadress on kirjutatud täislaiuses numbritega, näiteks １２７.０.０.１. Teine, samuti kõrge, puudutab kõiki kolme release line'i: kontrollist saab mööda minna, kui hostinime saab mitterangelt lugeda IP-aadressina. Kolmas on keskmine ja puudutab samuti kõiki kolme release line'i: mittestandardne IPv4 kirjapilt laseb sertifikaadis nimetatud DNS-nimel tõendada IP-aadressi. Väljalaskemärkmetes on paigad sõnastatud lühidalt: ebatüüpiliselt kirjutatud IP-aadressid lükatakse nüüd tagasi, ja eraldi on parandatud IP-aadresside normaliseerimise regressioon. Kõigil kolmel juhul on jutt hetkest, mil Node.js töötab kliendina, see tähendab loob ise krüpteeritud ühenduse teise serveriga, mitte hetkest, mil see teenindab oma külastajaid.

Neljas kõrge hinnanguga turvanõrkus on funktsioonis dns.resolve, mis lõikas lühemaks nimed, milles on nullmärk. Keskmiste seas on HTTP-ühenduste korduvkasutuse viga, mille puhul vastust, mis oli ühendusse kirjutatud enne päringu saatmist, võidi käsitleda vastusena sellele päringule, ja viga, mille tõttu crypto.randomUUID() ja randomInt() juhuslikkuse vahemälu salvestati startup snapshot'idesse ja single executable application'isse, nii et iga protsess kordas samu väärtusi. Kolm madala hinnanguga turvanõrkust puudutavad ZIP-failide töötlemist ja Node.js-i permission model'it.

Juhuslikkuse vahemälu viga tasub täpsemalt läbi mõelda, sest tavalisel juhul ei muuda see midagi. See puudutab ainult projekte, mis käivituvad enda tehtud startup snapshot'ist või mida levitatakse single executable application'ina (SEA), ja seal tähendab see, et iga samast failist käivitatud protsess sai samad „juhuslikud“ väärtused. Kui sellises projektis tehti crypto.randomUUID() või randomInt() abil identifikaatoreid või ajutisi koode, võisid need protsesside vahel korduda, seepärast tasub pärast parandust kontrollida, kas mõnda neist väärtustest ei kasutata kohas, kus see peab olema äraarvamatu.

Väljalase uuendab ka mitut sisseehitatud sõltuvust, release line'ist olenevalt c-ares, OpenSSL, SQLite ja Undici, millele toetub sisseehitatud fetch. Samuti on uuendatud CA store, Node.js-i enda nimekiri usaldatavatest sertifitseerimiskeskustest, seoses kompromiteeritud eMudhra vahesertifikaadiga, ja TLS-ühendused lükkavad nüüd tagasi ahelad, milles on blokeeritud avalikud võtmed.

Millised versioonid on turvalised

Paigatud versioonid on kolm, üks igale toetatud release line'ile: 22.23.4, 24.22.1 ja 26.12.1. Kõik, mis on oma release line'is vanem, on mõjutatud. Kõik kümme turvanõrkust ei puuduta kõiki release line'e: 26. release line'il on kõik kümme, 24.-l kaheksa ja 22.-l seitse, sest kaks madala hinnanguga viga on ainult uusimas neist ja üks TLS-i viga 22.-t ei puuduta.

Uuendamine release line'i piires on väikseim võimalik samm, ja tavaliselt ka kõige turvalisem muudatus, mida tootmiskeskkonnas teha saab. Ometi võib seegi käitumist muuta, ja seekord on konkreetne näide: TLS-i kontrolli paik lükkab nüüd tagasi ebatüüpiliselt kirjutatud IP-aadressid. Kui mõni rakendus kasutas teise serveriga ühendustes kunagi sellist kirjapilti, võib ühendus pärast uuendust ebaõnnestuda. See on parandatud turvaauk, mitte uus viga, aga seda tasub teada enne uuendamist, mitte pärast.

Release line on tähtsam kui versiooninumber

Kuni Node.js 26-ni läbib iga põhiversioon ühe tsükli: kõigepealt on see praegune versioon (Current), siis saavad paarisnumbriga versioonid aktiivse pikaajalise toe (Active LTS), seejärel lähevad Maintenance LTS-i, kus saavad ainult kriitilisi veaparandusi ja turvapaiku, ja lõpuks lõpeb tugi täiesti, paaritu numbriga versioonid kuni 25. release line'ini aga pikaajalist tuge ei saanud. Alates Node.js 27-st tsükkel muutub: väljalaskegraafiku järgi saab pikaajalise toe iga release line, ja kõik 30 tugikuud jääb see aktiivsesse faasi, ilma Maintenance LTS-ita. Projekt ise kirjutab, et tootmisrakendustes tuleb kasutada ainult Active LTS või Maintenance LTS pikaajalise toe versioone.

Praegustel release line'idel toimuvad järgmised faasimuutused kahel kuupäeval. Node.js-i väljalaskegraafiku järgi läks 24. release line Maintenance LTS-i 20. oktoobril, päev enne turbeväljalaset, ja 26. saab pikaajalise toe 28. oktoobril. 22. release line on Maintenance LTS-is alates 2025. aasta 21. oktoobrist ja kaotab toe 2027. aasta 30. aprillil, 24. aga 2028. aasta 30. aprillil.

Praktiline tähendus on lihtne: küsimus „kas meil on uusim versioon“ ei ütle iseenesest kuigi palju, kasulik on küsimus „millises release line'is me oleme ja mis kuupäevani see turvapaiku saab“. Esimene vastus muutub iga kuu, teine kord paari aasta tagant, ja just seepärast on teist lihtne unustada.

Node.js 18 ja 20: turvapaika ei tule

Node.js-i teadaandes on lause, mis on seekord tähtsam kui kõik kümme turvanõrkust: versioonid, mis on end of life'is, on turbeväljalaskes alati mõjutatud, ja neile turvapaika ei anta ei nüüd ega hiljem, sest end of life'i release line ei saa enam ühtki väljalaset.

Väljalaskegraafiku järgi kaotas 16. release line toe 2023. aasta 11. septembril, 19. release line 2023. aasta 1. juunil, 18. release line 2025. aasta 30. aprillil ja 20. release line 2026. aasta 30. aprillil. Viimane kuupäev on tähtsaim: 20. kaotas toe vähem kui kuus kuud tagasi, ja projekt, mida sellel alustati, võib endiselt töötada ilma ühegi nähtava probleemita. Just see teeb olukorra petlikuks, sest miski selle töös ei näita, et turvapaigad sellele enam ei kuulu.

Ettevõtetele, kes ei saa kiiresti toetatud release line'ile üle minna, nimetab Node.js-i teadaanne ühe võimaluse: kommertstuge versioonidele pärast Maintenance LTS-i pakuvad OpenJS Ecosystem Sustainability Program partnerid. See on tasuline teenus, ja see on ajutine lahendus, mitte ülemineku asendus.

Kuidas kontrollida, millist Node.js-i teie rakendus kasutab

Kontroll võtab minuteid, aga on üks koht, kus seda on lihtne valesti teha: Node.js-i versioon, mida terminal näitab, ei ole alati see, millega rakendus töötab.

Majutus cPaneliga. Kasutatavat versiooni näitab jaotis Software → Setup Node.js App, kus igal rakendusel on oma rida ja versioon valitakse nimekirjast. Nimekirjas on ainult need versioonid, mille serverisse on paigaldanud majutuse pakkuja. Käsk node -v võib sellises majutuses näidata teist versiooni kui see säte, seepärast vaadake just vastavat rida.

Oma server. Käsk node -v näitab versiooni, mis on süsteemi PATH-is esimene, aga protsessihaldur, näiteks PM2 või systemd teenus, võib programmi käivitada hoopis teise käivitatava failiga. Usaldusväärseim vastus on see, mida protsess ise enda kohta teatab: process.version väärtus, näiteks käivituse ajal logisse kirjutatuna.

Konteinerid. Dockeri keskkonnas määrab versiooni container image, mitte hostmasin. Container image, mis on ehitatud enne 21. oktoobrit, turvapaika ei sisalda, ükskõik mitu korda konteiner on taaskäivitatud, seepärast tuleb see uuesti ehitada uuendatud base image'iga.

Kui ligipääsu ei ole. Siis on küsimus majutuse pakkujale või arendajale, kes seda hoiab. Sõnastus, mis säästab kirjavahetust: „Millist Node.js-i versiooni meie rakendus kasutab? Kas see on oma release line'is vähemalt 22.23.4, 24.22.1 või 26.12.1? Kui see on end of life'i release line'is, näiteks 18 või 20, millal on üleminek plaanis?“

Mida teha täna

Tänane järjekord on selline: kõigepealt uuendada Node.js paigatud versioonini oma release line'is ja taaskäivitada iga protsess, mis seda kasutab, siis ehitada uuesti kõik, kuhu runtime on sisse ehitatud, ja alles seejärel plaanida üleminek projektidele, mis töötavad end of life'i release line'idel.

Esiteks uuendage release line'i piires. Versioonile 22.23.4, 24.22.1 või 26.12.1, olenevalt sellest, millises release line'is te olete. Majutuse puhul teeb seda pakkuja, ja teie töö on veenduda, et rakendus kasutab uuendatud versiooni.

Teiseks taaskäivitage protsessid. Protsess, mis juba töötab, jätkab selle Node.js-iga, millega see käivitati, ja faili vahetamine kettal seda ei muuda. Sama kehtis PHP2Shelli puhul: pakett on vahetatud, aga vana protsess jätkab vana koodiga.

Kolmandaks ehitage uuesti see, kuhu runtime on sisse ehitatud. Container image'id tuleb uuesti ehitada uuendatud base image'iga. Kui levitate programmi single executable application'ina (SEA), on Node.js ise sinna sisse ehitatud, seepärast süsteemi paigaldatud versiooni uuendamine seda ei muuda, ja fail tuleb uuesti ehitada paigatud versiooniga. Sama käib startup snapshot'ide kohta, mida juhuslikkuse vahemälu viga puudutab.

Neljandaks, kui olete 18. või 20. release line'il, plaanige üleminek. See on suurem töö kui uuendamine release line'i piires, seepärast tasub alustada nüüd, ja järjekord on kirjas järgmises jaotises.

Kuidas minna üle Node.js 18-lt või 20-lt

Üleminek põhiversioonide vahel ei ole ühe käsu töö, ja seda tasub teha järgemööda. Kõigepealt tuleb valida siht. Enamasti on see 24. release line, mis saab turvapaiku kuni 2028. aasta 30. aprillini. 22. release line on mõistlik valik ainult siis, kui mõni tähtis sõltuvus 24. release line'i veel ei toeta, sest selle tugi lõpeb aasta varem.

Siis tuleb leida kõik kohad, kus projekt oma Node.js-i versiooni määrab, sest neid on peaaegu alati mitu: package.json väli engines, failid .nvmrc või .node-version, Dockerfile'i base image, continuous integration (CI) keskkonna säte ja majutuspaneeli säte. Kui vahetada ainult osa neist, töötavad eri keskkondades eri versioonid, ja vead ilmuvad seal, kus neid on kõige raskem leida.

Seejärel tuleb projekt testkeskkonnas uue versiooniga uuesti paigaldada ja testid käivitada. Eri tähelepanu vajavad paketid, milles on kompileeritud kood: need ehitatakse konkreetsele Node.js-i versioonile, seepärast võib neid pärast üleminekut olla vaja uuesti ehitada või uuendada. Node.js avaldab igale põhiversioonile muudatuste nimekirja, kus on eraldi märgitud muudatused, mis võivad olemasoleva koodi katki teha, ja seda tasub lugeda enne üleminekut, mitte pärast.

Alles siis tuleb tootmiskeskkond: versiooni vahetus, protsesside taaskäivitus ja kontroll, et process.version näitab uut versiooni. Vana versioon võib mõneks päevaks jääda kättesaadavaks tagasipöördumise juhuks, aga mitte kauemaks, sest just see on versioon, millele turvapaika enam ei tule.

Mida Node.js-i uuendus kaasa ei võta

Node.js-i uuendamine parandab runtime'i enda ja teegid, mis on sinna sisse ehitatud, aga mitte kõike, mida rakendus kasutab, ja just siia jäävad kõige sagedamini augud, mida keegi ei näe.

Eraldi paigaldatud paketid. Kui projekt kasutab oma sõltuvustes npm-i paketti undici, mitte sisseehitatud fetch, asub see pakett projekti node_modules kaustas, ja Node.js-i väljalase seda ei puuduta. Sama käib kõigi muude sõltuvuste kohta: neid uuendab paketihaldur, ja ainult siis, kui keegi selle käivitab.

CA store. Vaikimisi ei kasuta Node.js operatsioonisüsteemi sertifitseerimiskeskuste nimekirja, vaid enda sisseehitatud nimekirja, ja dokumentatsioonis on öeldud, et see on Mozilla nimekirja koopia, mis fikseeritakse väljalaske hetkel. Seega saab programm sellise muudatuse nagu selle väljalaske reaktsioon kompromiteeritud eMudhra vahesertifikaadile kätte ainult koos runtime'i uuendusega, mitte koos operatsioonisüsteemi uuendustega, kui seda ei ole eraldi seadistatud kasutama süsteemi nimekirja.

Kuidas järgmist väljalaset mitte maha magada

Node.js kuulutab turbeväljalasked ette oma turbelehel, märkides plaanitud väljalaskepäeva, ja seekord läks just nii. See kolmapäev ei olnud üllatus neile, kes seda lehte jälgivad: uuenduse sai ette planeerida, mitte otsida selleks aega samal päeval.

Praktikas tähendab see, et keegi peab selle jälgimise eest vastutama. Hallatavas veebimajutuses teeb seda pakkuja, aga oma serveris või projektis, mida hoiab enda meeskond, tasub teada, kes täpselt jälgib projekti teadaandeid, kes otsustab uuendamise üle ja kes kontrollib, et pärast seda kõik töötab. Kui nendele küsimustele on vastus „mitte keegi konkreetne“, siis just seal ongi suurim risk, mitte mõnes kümnest turvanõrkusest.

Kui Node.js on teile ainult build tool

Paljudel Laraveli ja WordPressi veebilehtedel ei tööta Node.js serveris üldse: see käitab Vite'i või sarnast tööriista, mis valmistab lähtekoodist CSS-i ja JavaScripti failid, ja seejärel peatub. Sellisel juhul erineb olukord rakendusest, mis ise päringuid teenindab, sest build'i protsess ei vasta internetist tulevatele päringutele ega paki lahti andmeid, mida saadavad tundmatud külastajad.

Erinevus ei tähenda, et see ei ole tähtis. Build tool'id töötavad arendajate arvutites ja continuous integration'i keskkonnas, laadivad alla pakette ja loovad ühendusi teiste serveritega, ja turvanõrkuste kirjeldused on liiga lühikesed, et kindlalt öelda, millised neist teedest on mõjutatud. Node.js-i tasub uuendada ka seal, ainult õiges järjekorras: kõigepealt serverid, kus Node.js töötab otse võrgus, seejärel arendajate arvutid ja CI-keskkond.

On ka teine põhjus, mis selle nädalaga seotud ei ole. Build'i keskkond jääb tihti sellele Node.js-i versioonile, millega projekti kunagi alustati, ja siis ühel päeval keeldub uue tööriista versioon sellega lihtsalt töötamast. Üleminek toetatud release line'ile toimub siis kiirustades ja sobimatul hetkel, seepärast on seda lihtsam teha nüüd, kui see on plaanitud töö.

Mida see meie majutuses tähendas

Meie hallatav veebimajutus on koht meie enda serveris, ja iga klient valib seal versiooni majutuspaneeli kaudu. Meie serveris töötavad Node.js-i 22. ja 24. release line juba paigatud versioonidega 22.23.4 ja 24.22.1. Klientidel, kelle projektid neid release line'e kasutavad, ei ole midagi teha peale selle, et veenduda, kas protsess on pärast uuendust taaskäivitatud.

Ausalt tuleb öelda ka teine pool. Serveris on valikus endiselt ka release line'id, mis on end of life'is, ja neile turvapaika ei ole — ei meie ega kellegi teise serveris, sest Node.js sellist turvapaika ei anna. Kui teie projektile on valitud mõni neist, tähendab uuendamine üleminekut 22. või 24. release line'ile, ja seda on kõige parem teha koos kontrolliga, et pärast üleminekut töötab kõik nii nagu enne.

Meie hallatav veebimajutus algab 45 € kuus, ja hooldatud runtime'id on osa sellest, mille eest selles summas makstakse. Kui teie rakendus töötab veel Node.js 18 või 20 peal, arutame ülemineku läbi, enne kui seda sunnib peale mõne järgmise turbeväljalaske päev.