V knjižnici Log4j 2 (CVE-2021-45105) je bila ugotovljena še ena ranljivost, ki je za razliko od prejšnjih dveh težav razvrščena kot nevarna, vendar ne kritična. Nova težava vam omogoča, da povzročite zavrnitev storitve in se kaže v obliki zank in zrušitev pri obdelavi določenih vrstic. Ranljivost je bila odpravljena v izdaji Log4j 2.17, izdani pred nekaj urami. Nevarnost ranljivosti zmanjša dejstvo, da se težava pojavi le v sistemih z Javo 8.
Ranljivost vpliva na sisteme, ki uporabljajo kontekstualne poizvedbe (kontekstno iskanje), kot je ${ctx:var}, za določanje izhodne oblike dnevnika. Različice Log4j od 2.0-alpha1 do 2.16.0 niso imele zaščite pred nenadzorovano rekurzijo, kar je napadalcu omogočilo, da manipulira z vrednostjo, uporabljeno pri zamenjavi, da povzroči zanko, kar vodi do izčrpanja prostora sklada in zrušitve. Še posebej se je težava pojavila pri zamenjavi vrednosti, kot je "${${::-${::-$${::-j}}}}".
Poleg tega je mogoče opozoriti, da so raziskovalci iz Blumire predlagali možnost napada na ranljive aplikacije Java, ki ne sprejemajo zunanjih omrežnih zahtev; na ta način je mogoče napasti sisteme razvijalcev ali uporabnikov aplikacij Java. Bistvo metode je, da če so v uporabnikovem sistemu ranljivi procesi Java, ki sprejemajo omrežne povezave samo od lokalnega gostitelja ali obdelujejo zahteve RMI (Remote Method Invocation, vrata 1099), lahko napad izvede koda JavaScript, ki se izvede ko uporabniki v brskalniku odprejo zlonamerno stran. Za vzpostavitev povezave z omrežnimi vrati aplikacije Java med takšnim napadom se uporablja WebSocket API, za katerega za razliko od zahtev HTTP ne veljajo omejitve istega izvora (WebSocket se lahko uporablja tudi za skeniranje omrežnih vrat na lokalnem gostitelj za določitev razpoložljivih omrežnih upravljavcev).
Zanimivi so tudi rezultati ocenjevanja ranljivosti knjižnic, povezanih z odvisnostmi Log4j, ki jih je objavil Google. Po podatkih Googla težava vpliva na 8 % vseh paketov v repozitoriju Maven Central. Zlasti 35863 paketov Java, povezanih z Log4j prek neposrednih in posrednih odvisnosti, je bilo izpostavljenih ranljivostim. Hkrati se Log4j uporablja kot neposredna prvostopenjska odvisnost le v 17% primerov, v 83% prizadetih paketov pa se vezava izvaja prek vmesnih paketov, ki so odvisni od Log4j, tj. zasvojenosti druge in višje stopnje (21 % - druga stopnja, 12 % - tretja, 14 % - četrta, 26 % - peta, 6 % - šesta). Hitrost odpravljanja ranljivosti je še vedno nezaželena, teden dni po odkritju ranljivosti je bila od 35863 prepoznanih paketov težava doslej odpravljena le v 4620, tj. pri 13 %.
Medtem je Agencija ZDA za kibernetsko varnost in zaščito infrastrukture izdala nujno direktivo, ki od zveznih agencij zahteva, da identificirajo informacijske sisteme, na katere vpliva ranljivost Log4j, in namestijo posodobitve, ki blokirajo težavo do 23. decembra. Do 28. decembra morajo organizacije poročati o svojem delu. Za poenostavitev prepoznavanja problematičnih sistemov je bil pripravljen seznam izdelkov, za katere je bilo potrjeno, da kažejo ranljivosti (seznam vključuje več kot 23 tisoč aplikacij).
Vir: opennet.ru