Kitas pažeidžiamumas buvo nustatytas Log4j 2 bibliotekoje (CVE-2021-45105), kuri, skirtingai nei ankstesnės dvi problemos, yra klasifikuojama kaip pavojinga, bet ne kritinė. Naujasis leidimas leidžia sukelti paslaugų atsisakymą ir pasireiškia kilpų ir strigčių pavidalu apdorojant tam tikras eilutes. Pažeidžiamumas buvo ištaisytas prieš kelias valandas išleistame Log4j 2.17 leidime. Pažeidžiamumo pavojų sumažina tai, kad problema atsiranda tik sistemose su Java 8.
Pažeidžiamumas paveikia sistemas, kurios naudoja kontekstines užklausas (Context Lookup), pvz., ${ctx:var}, kad nustatytų žurnalo išvesties formatą. Log4j versijose nuo 2.0-alpha1 iki 2.16.0 trūko apsaugos nuo nekontroliuojamos pasikartojimo, o tai leido užpuolikui manipuliuoti pakeitime naudojama reikšme ir sukelti kilpą, dėl kurios išeikvota dėklo vieta ir įvyko gedimas. Visų pirma, problema iškilo pakeičiant reikšmes, tokias kaip „${${::-${::-$${::-j}}}}“.
Be to, galima pastebėti, kad „Blumira“ mokslininkai pasiūlė galimybę atakuoti pažeidžiamas „Java“ programas, kurios nepriima išorinių tinklo užklausų, pavyzdžiui, tokiu būdu galima atakuoti „Java“ programų kūrėjų ar vartotojų sistemas. Metodo esmė ta, kad jei vartotojo sistemoje yra pažeidžiamų „Java“ procesų, kurie tinklo ryšius priima tik iš vietinio pagrindinio kompiuterio, arba apdoroja RMI užklausas (Remote Method Invocation, 1099 prievadas), ataka gali būti įvykdyta naudojant JavaScript kodą. kai vartotojai naršyklėje atidaro kenkėjišką puslapį. Norint užmegzti ryšį su „Java“ programos tinklo prievadu tokios atakos metu, naudojama „WebSocket“ API, kuriai, skirtingai nei HTTP užklausoms, netaikomi tos pačios kilmės apribojimai („WebSocket“ taip pat gali būti naudojamas nuskaityti tinklo prievadus vietinėje prieglobą, kad nustatytų galimus tinklo tvarkykles).
Taip pat įdomūs yra „Google“ paskelbti bibliotekų, susijusių su „Log4j“ priklausomybėmis, pažeidžiamumo vertinimo rezultatai. „Google“ teigimu, problema paliečia 8% visų „Maven Central“ saugykloje esančių paketų. Visų pirma, 35863 4 „Java“ paketai, susiję su Log4j dėl tiesioginių ir netiesioginių priklausomybių, buvo paveikti pažeidžiamumų. Tuo pačiu metu Log17j kaip tiesioginė pirmojo lygio priklausomybė naudojama tik 83% atvejų, o 4% paveiktų paketų surišimas atliekamas per tarpinius paketus, kurie priklauso nuo Log21j, t.y. antrojo ir aukštesnio lygio priklausomybės (12% - antrasis lygis, 14% - trečias, 26% - ketvirtas, 6% - penktas, 35863% - šeštas). Pažeidžiamumo taisymo tempas dar palieka daug norimų rezultatų praėjus savaitei po pažeidžiamumo nustatymo, iš 4620 13 nustatytų paketų iki šiol problema buvo ištaisyta tik XNUMX XNUMX, t.y. XNUMX proc.
Tuo tarpu JAV kibernetinio saugumo ir infrastruktūros apsaugos agentūra paskelbė nepaprastosios padėties direktyvą, reikalaujančią, kad federalinės agentūros nustatytų informacines sistemas, paveiktas Log4j pažeidžiamumo, ir iki gruodžio 23 d. įdiegtų naujinimus, kurie blokuoja problemą. Iki gruodžio 28 d. organizacijos turi atsiskaityti už savo darbą. Siekiant supaprastinti probleminių sistemų identifikavimą, buvo parengtas produktų, kuriuose patvirtinta, kad yra pažeidžiamumų, sąrašas (sąraše yra daugiau nei 23 tūkst. programų).
Šaltinis: opennet.ru
