Kolejna podatność została zidentyfikowana w bibliotece Log4j 2 (CVE-2021-45105), która w odróżnieniu od dwóch poprzednich problemów jest klasyfikowana jako niebezpieczna, ale nie krytyczna. Nowy problem pozwala spowodować odmowę usługi i objawia się w postaci pętli i awarii podczas przetwarzania niektórych linii. Luka została naprawiona w wydanej kilka godzin temu wersji Log4j 2.17. Niebezpieczeństwo wynikające z luki jest łagodzone przez fakt, że problem pojawia się wyłącznie na systemach z Javą 8.
Luka dotyczy systemów korzystających z zapytań kontekstowych (wyszukiwanie kontekstu), takich jak ${ctx:var}, w celu określenia formatu wyjściowego dziennika. Wersjom Log4j od 2.0-alpha1 do 2.16.0 brakowało ochrony przed niekontrolowaną rekursją, co umożliwiło osobie atakującej manipulowanie wartością użytą podczas podstawienia w celu spowodowania pętli, co prowadziło do wyczerpania miejsca na stosie i awarii. W szczególności problem występował podczas podstawienia wartości takich jak „${${::-${::-$${::-j}}}}”.
Dodatkowo można zauważyć, że badacze z Blumiry zaproponowali możliwość ataku na podatne na ataki aplikacje Java, które nie akceptują żądań z sieci zewnętrznej; w ten sposób mogą zostać zaatakowane na przykład systemy twórców lub użytkowników aplikacji Java. Istota metody polega na tym, że jeśli w systemie użytkownika znajdują się podatne na ataki procesy Java, które akceptują połączenia sieciowe tylko od lokalnego hosta lub przetwarzają żądania RMI (Remote Method Invocation, port 1099), atak może zostać przeprowadzony poprzez wykonany kod JavaScript gdy użytkownicy otwierają złośliwą stronę w swojej przeglądarce. Do nawiązania połączenia z portem sieciowym aplikacji Java podczas takiego ataku wykorzystywane jest API WebSocket, do którego w odróżnieniu od żądań HTTP nie są stosowane ograniczenia tego samego pochodzenia (WebSocket można także wykorzystać do skanowania portów sieciowych na serwerze lokalnym) host w celu określenia dostępnych procedur obsługi sieci).
Interesujące są także opublikowane przez Google wyniki oceny podatności bibliotek powiązanych z zależnościami Log4j. Według Google problem dotyczy 8% wszystkich pakietów w repozytorium Maven Central. W szczególności na luki narażone były 35863 4 pakiety Java powiązane z Log4j poprzez bezpośrednie i pośrednie zależności. Jednocześnie Log17j jest używany jako bezpośrednia zależność pierwszego poziomu tylko w 83% przypadków, a w 4% pakietów, których to dotyczy, powiązanie odbywa się za pośrednictwem pakietów pośrednich zależnych od Log21j, tj. uzależnienia drugiego i wyższego stopnia (12% – drugi stopień, 14% – trzeci, 26% – czwarty, 6% – piąty, 35863% – szósty). Tempo usuwania luki w dalszym ciągu pozostawia wiele do życzenia – tydzień po wykryciu luki, z 4620 13 zidentyfikowanych pakietów, problem został już naprawiony jedynie w XNUMX XNUMX, tj. przy XNUMX%.
Tymczasem amerykańska Agencja ds. Cyberbezpieczeństwa i Ochrony Infrastruktury wydała nadzwyczajną dyrektywę wymagającą od agencji federalnych zidentyfikowania systemów informatycznych dotkniętych luką Log4j i zainstalowania aktualizacji blokujących problem do 23 grudnia. Do 28 grudnia organizacje mają obowiązek składać sprawozdania ze swojej pracy. Aby ułatwić identyfikację problematycznych systemów, przygotowano listę produktów, w których potwierdzono występowanie podatności (na liście znajduje się ponad 23 tys. aplikacji).
Źródło: opennet.ru