In oare kwetsberens is identifisearre yn 'e Log4j 2-bibleteek (CVE-2021-45105), dy't, yn tsjinstelling ta de foarige twa problemen, wurdt klassifisearre as gefaarlik, mar net kritysk. It nije probleem lit jo in ûntkenning fan tsjinst feroarsaakje en manifestearret him yn 'e foarm fan loops en crashes by it ferwurkjen fan bepaalde rigels. De kwetsberens waard reparearre yn 'e Log4j 2.17 release in pear oeren lyn frijlitten. It gefaar fan 'e kwetsberens wurdt fermindere troch it feit dat it probleem allinich ferskynt op systemen mei Java 8.
De kwetsberens hat ynfloed op systemen dy't kontekstuele queries brûke (Context Lookup), lykas ${ctx:var}, om it logútfierformaat te bepalen. Log4j-ferzjes fan 2.0-alpha1 oant 2.16.0 misten beskerming tsjin ûnkontrolearre rekursje, wêrtroch in oanfaller de wearde koe manipulearje dy't brûkt waard yn 'e ferfanging om in loop te feroarsaakjen, wat liedt ta útputting fan stackromte en in crash. Benammen it probleem barde by it ferfangen fan wearden lykas "${${::-${::-$${::-j}}}}".
Derneist kin wurde opmurken dat ûndersikers fan Blumira in opsje hawwe foarsteld om kwetsbere Java-applikaasjes oan te fallen dy't gjin eksterne netwurkfersiken akseptearje; bygelyks kinne de systemen fan ûntwikkelders of brûkers fan Java-applikaasjes op dizze manier oanfallen wurde. De essinsje fan 'e metoade is dat as d'r kwetsbere Java-prosessen binne op it systeem fan 'e brûker dy't netwurkferbiningen allinich akseptearje fan 'e lokale host, of RMI-oanfragen ferwurkje (Remote Method Invocation, poarte 1099), de oanfal kin wurde útfierd troch JavaScript-koade útfierd. as brûkers in kweade side iepenje yn har browser. Om by sa'n oanfal in ferbining te meitsjen mei de netwurkpoarte fan in Java-applikaasje, wurdt de WebSocket API brûkt, dêr't, yn tsjinstelling ta HTTP-oanfragen, gjin beheiningen fan deselde oarsprong tapast wurde (WebSocket kin ek brûkt wurde om netwurkhavens op 'e lokale te scannen host om beskikbere netwurkhannelers te bepalen).
Ek fan belang binne de resultaten publisearre troch Google fan it beoardieljen fan de kwetsberens fan biblioteken dy't ferbûn binne mei Log4j-ôfhinklikens. Neffens Google hat it probleem ynfloed op 8% fan alle pakketten yn it Maven Central repository. Benammen 35863 Java-pakketten ferbûn mei Log4j troch direkte en yndirekte ôfhinklikens waarden bleatsteld oan kwetsberens. Tagelyk wurdt Log4j allinich yn 17% fan 'e gefallen brûkt as direkte ôfhinklikens fan' e earste nivo, en yn 83% fan 'e troffen pakketten wurdt de bining útfierd troch tuskenpakketten dy't ôfhinklik binne fan Log4j, d.w.s. ferslaving fan it twadde en heger nivo (21% - twadde nivo, 12% - tredde, 14% - fjirde, 26% - fyfde, 6% - seisde). It tempo fan it reparearjen fan de kwetsberens lit noch folle te winskjen oer; in wike neidat de kwetsberens waard identifisearre, fan 35863 identifisearre pakketten, is it probleem oant no ta repareare yn mar 4620, d.w.s. oant 13%.
Underwilens hat de US Cybersecurity and Infrastructure Protection Agency in needrjochtline útjûn dy't federale ynstânsjes fereasket om ynformaasjesystemen te identifisearjen dy't beynfloede binne troch de Log4j-kwetsberens en updates te ynstallearjen dy't it probleem blokkearje troch 23 desimber. Oant 28 desimber moatte organisaasjes rapportearje oer harren wurk. Om de identifikaasje fan problematyske systemen te ferienfâldigjen, is in list mei produkten makke dy't befêstige binne om kwetsberens te eksposearjen (de list befettet mear as 23 tûzen applikaasjes).
Boarne: opennet.ru