Nog 'n kwesbaarheid is geïdentifiseer in die Log4j 2-biblioteek (CVE-2021-45105), wat, anders as die vorige twee probleme, as gevaarlik geklassifiseer word, maar nie krities nie. Die nuwe uitgawe laat jou toe om 'n ontkenning van diens te veroorsaak en manifesteer hom in die vorm van lusse en ineenstortings wanneer sekere lyne verwerk word. Die kwesbaarheid is reggestel in die Log4j 2.17-vrystelling wat 'n paar uur gelede vrygestel is. Die gevaar van die kwesbaarheid word versag deur die feit dat die probleem slegs op stelsels met Java 8 voorkom.
Die kwesbaarheid affekteer stelsels wat kontekstuele navrae (Context Lookup), soos ${ctx:var}, gebruik om die log-uitvoerformaat te bepaal. Log4j-weergawes van 2.0-alpha1 tot 2.16.0 het nie beskerming teen onbeheerde herhaling gehad nie, wat 'n aanvaller in staat gestel het om die waarde wat in die vervanging gebruik word, te manipuleer om 'n lus te veroorsaak, wat gelei het tot uitputting van stapelspasie en 'n ineenstorting. Die probleem het veral voorgekom met die vervanging van waardes soos "${${::-${::-$${::-j}}}}".
Daarbenewens kan daarop gelet word dat navorsers van Blumira 'n opsie voorgestel het om kwesbare Java-toepassings aan te val wat nie eksterne netwerkversoeke aanvaar nie; byvoorbeeld die stelsels van ontwikkelaars of gebruikers van Java-toepassings kan op hierdie manier aangeval word. Die essensie van die metode is dat as daar kwesbare Java-prosesse op die gebruiker se stelsel is wat netwerkverbindings slegs vanaf die plaaslike gasheer aanvaar, of RMI-versoeke verwerk (Remote Method Invocation, poort 1099), die aanval uitgevoer kan word deur JavaScript-kode wat uitgevoer word wanneer gebruikers 'n kwaadwillige bladsy in hul blaaier oopmaak. Om 'n verbinding met die netwerkpoort van 'n Java-toepassing tydens so 'n aanval te vestig, word die WebSocket API gebruik, waarop, anders as HTTP-versoeke, dieselfde oorsprongbeperkings nie toegepas word nie (WebSocket kan ook gebruik word om netwerkpoorte op die plaaslike te skandeer gasheer om beskikbare netwerkhanteerders te bepaal).
Ook van belang is die resultate wat deur Google gepubliseer is om die kwesbaarheid van biblioteke wat met Log4j-afhanklikhede geassosieer word, te assesseer. Volgens Google raak die probleem 8% van alle pakkette in die Maven Central-bewaarplek. Veral 35863 4 Java-pakkette wat met Log4j geassosieer word deur direkte en indirekte afhanklikhede is aan kwesbaarhede blootgestel. Terselfdertyd word Log17j slegs in 83% van gevalle as 'n direkte eerstevlakafhanklikheid gebruik, en in 4% van geaffekteerde pakkette word die binding uitgevoer deur middel van tussenpakkette wat afhanklik is van Log21j, d.w.s. verslawings van die tweede en hoër vlak (12% - tweede vlak, 14% - derde, 26% - vierde, 6% - vyfde, 35863% - sesde). Die tempo van regstelling van die kwesbaarheid laat nog veel te wense oor; 'n week nadat die kwesbaarheid geïdentifiseer is, uit 4620 geïdentifiseerde pakkette, is die probleem tot dusver in slegs 13 opgelos, d.w.s. op XNUMX%.
Intussen het die Amerikaanse agentskap vir kuberveiligheid en infrastruktuurbeskerming 'n noodvoorskrif uitgereik wat van federale agentskappe vereis om inligtingstelsels te identifiseer wat deur die Log4j-kwesbaarheid geraak word en opdaterings te installeer wat die probleem teen 23 Desember blokkeer. Organisasies moet teen 28 Desember verslag doen oor hul werk. Om die identifisering van problematiese stelsels te vereenvoudig, is 'n lys produkte voorberei wat bevestig is om kwesbaarhede te toon (die lys bevat meer as 23 duisend toepassings).
Bron: opennet.ru