W bibliotece Log4j 2 zidentyfikowano kolejną podatność (CVE-2021-45105), która w przeciwieństwie do dwóch poprzednich problemów została zakwalifikowana jako niebezpieczna, ale nie krytyczna. Nowy problem może prowadzić do odmowy usługi i objawia się w postaci zapętlenia oraz awaryjnego zakończenia podczas przetwarzania określonych ciągów. Podatność została naprawiona w opublikowanej kilka godzin temu wersji Log4j 2.17. Niebezpieczeństwo podatności łagodzi fakt, że problem objawia się tylko w systemach z Javą 8.
Na podatności narażone są systemy, które wykorzystują kontekstowe zapytania (Context Lookup) przy określaniu formatu zapisu do logu, takie jak ${ctx:var}. W wersjach Log4j, od 2.0-alpha1 do 2.16.0, brakowało zabezpieczeń przed niekontrolowaną rekurencją, co umożliwiało atakującemu wywołanie zapętlenia poprzez manipulację wartością używaną w podstawieniu, prowadzącą do wyczerpania miejsca na stosie i awaryjnego zakończenia procesu. W szczególności problem występował podczas podstawienia takich wartości jak „${${::-${::-$${::-j}}}}”.
Dodatkowo warto zauważyć, że badacze z firmy Blumira zaproponowali wariant ataku na podatne aplikacje Java, które nie przyjmują zewnętrznych zapytań sieciowych, na przykład można w ten sposób zaatakować systemy deweloperów lub użytkowników aplikacji Java. Istota metody polega na tym, że przy obecności na systemie użytkownika podatnych procesów Java, które akceptują połączenia sieciowe tylko z lokalnego hosta (localhost), lub przetwarzających zapytania RMI (Remote Method Invocation, port 1099), atak może zostać przeprowadzony za pomocą kodu JavaScript, wykonywanego podczas otwierania przez użytkowników złośliwej strony w przeglądarce. Aby zorganizować połączenie z portem sieciowym aplikacji Java przy takim ataku, używane jest API WebSocket, które w przeciwieństwie do zapytań HTTP nie podlega ograniczeniom same-origin (WebSocket może być także używany do skanowania portów sieciowych na lokalnym hoście w celu określenia istniejących obsługiwanych portów).
Interesującym zagadnieniem są opublikowane przez firmę Google wyniki oceny podatności bibliotek powiązanych z Log4j. Zgodnie z danymi Google, problem dotyczy 8% wszystkich pakietów w repozytorium Maven Central. W szczególności, 35863 pakiety Java powiązane z Log4j są narażone na te podatności. Log4j jest używane jako bezpośrednie zależność pierwszego poziomu tylko w 17% przypadków, natomiast w przypadku 83% podatnych pakietów powiązanie odbywa się poprzez pośrednie pakiety zależne od Log4j, tj. zależności drugiego i wyższego poziomu (21% - drugiego poziomu, 12% - trzeciego, 14% - czwartego, 26% - piątego, 6% - szóstego). Tempo naprawiania podatności wciąż pozostawia wiele do życzenia; tydzień po odkryciu luki z 35863 zidentyfikowanych pakietów problem został rozwiązany jedynie w 4620, czyli w 13%.
W międzyczasie, Amerykańska Agencja ds. Cyberbezpieczeństwa i Ochrony Infrastruktury opublikowała pilne zalecenie, zobowiązujące federalne agencje do zidentyfikowania systemów informacyjnych narażonych na podatność w Log4j, oraz do 23 grudnia zainstalowania aktualizacji, które zablokują problem. Do 28 grudnia organizacje są zobowiązane do złożenia raportu na temat podjętych działań. W celu ułatwienia identyfikacji problematycznych systemów przygotowano listę produktów, w których potwierdzono wystąpienie podatności (lista liczy ponad 23 tysiące aplikacji).
Źródło: opennet.ru
