Një dobësi tjetër është identifikuar në bibliotekën Log4j 2 (CVE-2021-45105), e cila, ndryshe nga dy problemet e mëparshme, klasifikohet si e rrezikshme, por jo kritike. Çështja e re ju lejon të shkaktoni një refuzim të shërbimit dhe manifestohet në formën e sytheve dhe përplasjeve kur përpunoni linja të caktuara. Dobësia u rregullua në versionin Log4j 2.17 të lëshuar disa orë më parë. Rreziku i cenueshmërisë zbutet nga fakti se problemi shfaqet vetëm në sistemet me Java 8.
Dobësia prek sistemet që përdorin pyetje kontekstuale (Context Lookup), si p.sh. ${ctx:var}, për të përcaktuar formatin e daljes së regjistrit. Versionet e Log4j nga 2.0-alpha1 në 2.16.0 nuk kishin mbrojtje kundër rekursionit të pakontrolluar, gjë që lejoi një sulmues të manipulonte vlerën e përdorur në zëvendësim për të shkaktuar një lak, duke çuar në shterjen e hapësirës së stivës dhe një përplasje. Në veçanti, problemi ndodhi kur zëvendësohen vlera të tilla si "${${::-${::-$${::-j}}}}".
Për më tepër, mund të vërehet se studiuesit nga Blumira kanë propozuar një opsion për të sulmuar aplikacionet vulnerabël Java që nuk pranojnë kërkesa të jashtme të rrjetit; për shembull, sistemet e zhvilluesve ose përdoruesve të aplikacioneve Java mund të sulmohen në këtë mënyrë. Thelbi i metodës është që nëse ka procese të cenueshme Java në sistemin e përdoruesit që pranojnë lidhje rrjeti vetëm nga hosti lokal, ose përpunojnë kërkesat RMI (Remote Method Invocation, port 1099), sulmi mund të kryhet nga kodi JavaScript i ekzekutuar. kur përdoruesit hapin një faqe me qëllim të keq në shfletuesin e tyre. Për të krijuar një lidhje me portin e rrjetit të një aplikacioni Java gjatë një sulmi të tillë, përdoret WebSocket API, për të cilin, ndryshe nga kërkesat HTTP, nuk zbatohen kufizime me origjinë të njëjtë (WebSocket mund të përdoret gjithashtu për të skanuar portet e rrjetit në lokal host në mënyrë që të përcaktohen trajtuesit e disponueshëm të rrjetit).
Gjithashtu me interes janë rezultatet e publikuara nga Google për vlerësimin e cenueshmërisë së bibliotekave të lidhura me varësitë e Log4j. Sipas Google, problemi prek 8% të të gjitha paketave në depon e Maven Central. Në veçanti, 35863 paketa Java të lidhura me Log4j përmes varësive direkte dhe indirekte u ekspozuan ndaj dobësive. Në të njëjtën kohë, Log4j përdoret si një varësi direkte e nivelit të parë vetëm në 17% të rasteve, dhe në 83% të paketave të prekura, lidhja kryhet përmes paketave të ndërmjetme që varen nga Log4j, d.m.th. varësitë e nivelit të dytë dhe më të lartë (21% - niveli i dytë, 12% - i treti, 14% - i katërti, 26% - i pesti, 6% - i gjashti). Ritmi i rregullimit të cenueshmërisë lë ende shumë për të dëshiruar, një javë pasi u identifikua dobësia, nga 35863 paketa të identifikuara, problemi është rregulluar deri më tani në vetëm 4620, d.m.th. në 13%.
Ndërkohë, Agjencia e SHBA-së për Sigurinë Kibernetike dhe Mbrojtjen e Infrastrukturës lëshoi një direktivë emergjente që u kërkon agjencive federale të identifikojnë sistemet e informacionit të prekura nga dobësia Log4j dhe të instalojnë përditësime që bllokojnë problemin deri më 23 dhjetor. Deri më 28 dhjetor, organizatave u kërkohet të raportojnë për punën e tyre. Për të thjeshtuar identifikimin e sistemeve problematike, është përgatitur një listë e produkteve që janë konfirmuar se shfaqin dobësi (lista përfshin më shumë se 23 mijë aplikacione).
Burimi: opennet.ru