Log4j 2 liburutegian (CVE-2021-45105) beste ahultasun bat identifikatu da, aurreko bi arazoetan ez bezala, arriskutsu gisa sailkatuta dagoena, baina ez kritikoa. Arazo berriak zerbitzuaren ukapena eragiteko aukera ematen du eta lerro jakin batzuk prozesatzen direnean begizta eta hutsegite moduan agertzen da. Ahultasuna duela ordu batzuk kaleratutako Log4j 2.17 bertsioan konpondu zen. Ahultasunaren arriskua arintzen da arazoa Java 8 duten sistemetan bakarrik agertzen delako.
Ahultasunak testuinguruko kontsultak (Testuinguruaren bilaketa) erabiltzen dituzten sistemei eragiten die, hala nola ${ctx:var}, erregistro-irteera formatua zehazteko. 4-alpha2.0-etik 1-rako Log2.16.0j-ren bertsioek ez zuten kontrolik gabeko errekurtsioaren aurkako babesik, eta horri esker, erasotzaileak ordezkapenean erabilitako balioa manipulatzeko aukera izan zuen begizta bat sortzeko, pila-espazioa agortu eta hutsegite bat eraginez. Bereziki, arazoa "${${::-${::-$${::-j}}}} bezalako balioak ordezkatzean gertatu da.
Gainera, azpimarratzekoa da Blumirako ikertzaileek kanpoko sareko eskaerak onartzen ez dituzten Java aplikazio zaurgarriak erasotzeko aukera bat proposatu dutela; adibidez, Java aplikazioen garatzaileen edo erabiltzaileen sistemak eraso daitezkeela horrela. Metodoaren funtsa da erabiltzailearen sisteman sare-konexioak tokiko ostalaritik soilik onartzen dituzten Java prozesu ahulak badaude edo RMI eskaerak prozesatzen badira (Urruneko Metodo-deiketa, 1099 ataka), exekutaturiko JavaScript kodearen bidez egin daiteke erasoa. erabiltzaileek beren arakatzailean orri gaizto bat irekitzen dutenean. Eraso batean Java aplikazio baten sareko atakarako konexioa ezartzeko, WebSocket APIa erabiltzen da, eta, HTTP eskaerei ez bezala, jatorri bereko murrizketak ez zaizkie aplikatzen (WebSocket sareko atakak eskaneatzeko ere erabil daiteke tokiko tokian). ostalari eskuragarri dauden sare-kudeatzaileak zehazteko).
Era berean, interesgarriak dira Log4j mendekotasunekin lotutako liburutegien ahultasuna ebaluatzeko Googlek argitaratutako emaitzak. Google-ren arabera, arazoak Maven Central biltegiko pakete guztien % 8ri eragiten dio. Bereziki, zuzeneko eta zeharkako mendekotasunen bidez Log35863j-i lotutako 4 Java pakete ahuleziak jasan zituzten. Aldi berean, Log4j lehen mailako menpekotasun zuzen gisa erabiltzen da kasuen % 17an bakarrik, eta kaltetutako paketeen % 83an, Log4j-ren menpe dauden tarteko paketeen bidez egiten da lotzea, hau da. bigarren eta goi mailako mendekotasunak (% 21 - bigarren maila, % 12 - hirugarren, % 14 - laugarren, % 26 - bosgarren, % 6 - seigarren). Ahultasuna konpontzeko erritmoak asko uzten du oraindik; ahultasuna identifikatu eta astebetera, identifikatutako 35863 paketeetatik, arazoa orain arte 4620tan bakarrik konpondu da, hau da. %13an.
Bien bitartean, AEBetako Zibersegurtasun eta Azpiegituren Babeserako Agentziak larrialdietarako zuzentarau bat eman zuen, agentzia federalei Log4j ahultasunak kaltetutako informazio sistemak identifikatzea eta arazoa blokeatzen duten eguneraketak instalatzea eskatzen diena abenduaren 23rako. Abenduaren 28rako, erakundeek euren lanaren berri eman behar dute. Sistema arazotsuen identifikazioa errazteko, ahultasunak erakusten dituzten produktuen zerrenda prestatu da (zerrendak 23 mila aplikazio baino gehiago biltzen ditu).
Iturria: opennet.ru