Június elején a népszerű node-ip csomag GitHub repojának tulajdonosa, Fedor Indutny azonnali hatállyal read-only-ra tette a repot. Így lekorlátozva a lehetőségét annak, hogy mások pull request-et nyissanak, hibát jelezzenek vagy hozzászóljanak a repohoz.
Ilyen általában akkor történik, ha a fejlesztője már nem akar foglalkozni tovább a repoval, ám ebben az esetben egészen másról van szó. Heti 17-28 millió letöltésével nem épp egy hanyatló, kis érdeklődésre számottartó csomagról beszélünk. Az ok egészen más, és erre az okra végül maga Indutny posztja adja meg a választ.
A szóban forgó kétes CVE jegy
Indutny posztjában arról beszél, hogy valaki egy megkérdőjelezhető CVE jegyet nyitott, ami az ő repoját érinti. A jegyet critical szintűre állították be, így aki telepíteni vagy frissíteni szerette volna npm-ből a node-ip csomagot hibát kapott.
A fejlesztőt így elárasztották a hozzászólások. Sokan pánikolni kezdtek, hiszen egy milliók által használt csomagban súlyos biztonsági sebezhetőséget találtak. Sokan követelték, hogy azonnali hatállyal javítsa ki a hibát.
Az ominózus CVE jegyet (CVE-2023-42282) 9.8-as, tehát critical besorolással hozták létre, és a beküldő szerint az alábbi súlyos probléma van a csomagban elrejtve: nem megfelelően kezeli a csomag a nem-standard módon megadott privát IP címeket. Ez a gyakorlatban azt jelenti, hogy pl a “0x7F.1…” -ként megadott IP címet, ami 127.1… lenne, valójában publikus IP-ként kezeli.
Ha pedig egy szoftver kizárólag erre építve tesz különbséget privát és publikus IP-k között, akkor egy nem-standard IP címmel átverhető, ami előre nem látható viselkedést eredményehet a kódban.
Egy friss verzióban bár Indutny valóban beépített egy patchet ennek kijavítására, állítása szerint elképzelhetetlennek tartja, hogy ez a hiba, annyira kritikus lenne, mint ahogy azt a kiíró állítja. Panaszát beküldte a GitHub-nak és felvette a kapcsolatot a hibajegy kiírójával is. A GitHub jogosnak érezhette érvelését, mert critical-ról low-ra állította a jegy súlyosságát. A jegy kiírója viszont azóta sem válaszolt neki.
A fejlesztő nincs is könnyű helyzetben, hiszen magát a CVE Numbering Authorities-t (CNA) kell megtalálnia, aki eredetileg kiírja a CVE jegyet. Ezt viszont nem tartalmazza a jegy. És bár a GitHub levette a súlyossági szintet alacsonyra, más platformokon továbbra is kritikusként szerepel.
Szia Uram! CVE érdekel?
A CVE rendszere alapvetően azért jött létre, hogy a kiberbiztonsági szakemberek megfelelő módon tudják jelenteni az általuk felfedezett biztonsági problémákat.
Viszont aggasztóan terjed egy újfajta trend is: egyesek (főleg bug bounty hunterek) gyakorlatilag portfóliót építenek abból, hogy hány és milyen súlyosságú hibát jelentettek. Ezért hajlamosak eltúlozni egy-egy hiba jelentőségét, csak azért, hogy jobb fényben tüntessék fel magukat.
Nem először fordul elő
Hasonló eset volt, amikor 2023-ban Daniel Stenberg, a népszerű curl projekt készítője élesen bírált egy hamis riasztást, a CVE-2020-19909-et. Eredetileg ez is 9.8-as kritikus besorolást kapott, ahogy megnézhető az NVD oldalán is, majd levették 3.3-as alacsony besorolásra a megvitatást követően.
A micromatch npm csomag kapcsán is hasonló történhetett. A heti 64 millió letöltéssel járó npm csomaghoz “high severity” besorolású hiba érkezett, CVE-2024-4067.
A projekt készítője, Jon Schlinkert megtalálta a hibajegyet kiíró tagot, akitől konkrét esetet, de legalább egy proof-of-concept-et várt volna, ezt viszont megkeresése óta nem kapott. Schlinkert nem tagadja, hogy lehet ilyen hiba a csomagban, de ennek kihasználásához gyakorlatilag a programozónak magának kell elkövetnie a hibát, hiszen annyira mélyen beágyazottan történik a problémás függvény meghívása, amihez kívülről (pl egy böngészőn keresztül) nem férhet hozzá senki.
Ez nagyjából olyan, mintha valaki azért írna ki hibajegyet, mert végtelen ciklust írt valamilyen programozási nyelvben.
Mi lehet a megoldás?
Az ehhez hasonló, ismétlődő események felvetik a kérdést, hogyan lehet mégis egyensúlyt teremteni?
A vélt sebezhetőségek szüntelen bejelentése kimerítheti a nyílt forráskódú fejlesztőket, akik közül sokan önkéntesek. Ez sok nyílt forráskódú projekt megakadásához vezethet.
Másfelől, vajon etikus lenne-e, ha a biztonsági szakemberek, beleértve a kezdőket is, elhallgatnák azt, amit biztonsági hibának vélnek – mindezt azért, hogy ne okozzanak kellemetlenséget a projekt fenntartóinak?
Egy harmadik probléma az aktív karbantartó nélküli projektek esetében merül fel. Az évek óta nem érintett, elhagyott szoftverprojektek olyan sebezhetőségeket tartalmaznak, amelyeket még ha nyilvánosságra is hoznak, soha nem javítanak ki, és nincs mód az eredeti karbantartójukkal való kapcsolatfelvételre.
Ilyen esetekben a közvetítők, beleértve a CNA-kat és a hibabejelentő platformokat is, bizonytalanságban maradnak.
Egy lehetséges megoldás lehet az ilyen esetekben, a POC megkövetelése, amiben le kell írni, hogyan milyen módon sikerült előidézni a sebezhetőséget. Másfelől lehetne megoldás, hogy nem egyből kerül megállapításra egy sebezhetőség súlyossága, hanem többen ránéznek és reviewzzák az észrevételt.
Ameddig ezek nincsenek, sajnos a nyílt forráskódú projektek készítőinek számolniuk kell a hibás CVE jelentésekkel.