Eng aner Schwachstelle gouf an der Log4j 2 Bibliothéik (CVE-2021-45105) identifizéiert, déi, am Géigesaz zu den zwee virdrun Problemer, als geféierlech, awer net kritesch klasséiert ass. Déi nei Ausgab erlaabt Iech e Verweigerung vum Service ze verursaachen a manifestéiert sech a Form vu Schleifen a Crashen beim Veraarbechtung vu bestëmmte Linnen. D'Vulnerabilitéit gouf an der Log4j 2.17 Verëffentlechung fixéiert, déi virun e puer Stonnen verëffentlecht gouf. D'Gefor vun der Schwachstelle gëtt reduzéiert duerch d'Tatsaach datt de Problem nëmmen op Systemer mat Java 8 erschéngt.
D'Vulnerabilitéit beaflosst Systemer déi kontextuell Ufroe benotzen (Context Lookup), wéi ${ctx:var}, fir de Logausgangsformat ze bestëmmen. Log4j Versioune vun 2.0-alpha1 bis 2.16.0 feelen Schutz géint onkontrolléiert Rekursioun, wat en Ugräifer erlaabt huet de Wäert, deen an der Substitutioun benotzt gëtt, ze manipuléieren fir eng Loop ze verursaachen, wat zu Ausschöpfung vum Stackraum an engem Crash féiert. Besonnesch ass de Problem geschitt beim Ersatz vu Wäerter wéi "${${::-${::-$${::-j}}}}".
Zousätzlech kann et bemierkt ginn datt d'Fuerscher vu Blumira eng Optioun proposéiert hunn fir vulnérabel Java Uwendungen z'attackéieren déi net extern Netzwierk Ufroen akzeptéieren; zum Beispill kënnen d'Systemer vun Entwéckler oder Benotzer vun Java Uwendungen op dës Manéier attackéiert ginn. D'Essenz vun der Method ass datt wann et vulnérabel Java Prozesser um System vum Benotzer sinn, déi Netzwierkverbindunge nëmme vum lokalen Host akzeptéieren, oder RMI Ufroe veraarbecht (Remote Method Invocation, Port 1099), kann den Attack duerch JavaScript Code ausgefouert ginn. wann d'Benotzer eng béiswëlleg Säit an hirem Browser opmaachen. Fir eng Verbindung zum Netzhafen vun enger Java Applikatioun während sou engem Attack z'etabléieren, gëtt d'WebSocket API benotzt, op déi, am Géigesaz zu HTTP-Ufroen, Restriktiounen vun der selwechter Hierkonft net applizéiert ginn (WebSocket kann och benotzt ginn fir Netzwierkporten op der lokaler ze scannen Host fir verfügbare Netzwierkhanteren ze bestëmmen).
Och interessant sinn d'Resultater publizéiert vu Google fir d'Schwachheet vu Bibliothéiken ze bewäerten, déi mat Log4j Ofhängegkeeten verbonne sinn. Laut Google betrëfft de Problem 8% vun alle Packagen am Maven Central Repository. Besonnesch 35863 Java Packagen verbonne mat Log4j duerch direkt an indirekt Ofhängegkeete ware Schwachstelle ausgesat. Zur selwechter Zäit gëtt Log4j als direkt Ofhängegkeet vum éischte Niveau nëmmen a 17% vun de Fäll benotzt, an an 83% vun de betraffene Packagen gëtt d'Bindung duerch Zwësche Packagen duerchgefouert, déi vu Log4j ofhänken, d.h. Ofhängegkeeten vum zweeten a méi héije Niveau (21% - zweeten Niveau, 12% - drëtt, 14% - véiert, 26% - fënneft, 6% - sechst). Den Tempo fir d'Schwachheet ze fixéieren léisst nach ëmmer vill ze wënschen; eng Woch nodeems d'Schwachheet identifizéiert gouf, vun 35863 identifizéierte Packagen, ass de Problem bis elo an nëmmen 4620 fixéiert, d.h. op 13%.
Mëttlerweil huet d'US Cybersecurity and Infrastructure Protection Agency eng Noutdirektiv erausginn, déi Féderalen Agenturen erfuerderen, Informatiounssystemer z'identifizéieren, déi vun der Log4j Schwachstelle betraff sinn an Updates z'installéieren, déi de Problem bis den 23. Dezember blockéieren. Bis den 28. Dezember mussen d'Organisatiounen iwwer hir Aarbecht mellen. Fir d'Identifikatioun vu problematesche Systemer ze vereinfachen, ass eng Lëscht vu Produkter virbereet, déi bestätegt goufen Schwachstelle ze weisen (d'Lëscht enthält méi wéi 23 Tausend Uwendungen).
Source: opennet.ru