У бібліотеці Log4j 2 виявлено ще одну вразливість (CVE-2021-45105), яка на відміну від двох минулих проблем, віднесена до категорії небезпечних, але не критичних. Нова проблема дозволяє викликати відмову в обслуговуванні та проявляється у вигляді зациклювання та аварійного завершення при обробці певних рядків. Уразливість усунена в опублікованому кілька годин тому випуску Log4j 2.17. Небезпека уразливості згладжує те, що проблема проявляється лише на системах з Java 8.
Уразливості схильні до систем, що використовують при визначенні формату виведення в лог контекстні запити (Context Lookup), такі як ${ctx:var}. У версіях Log4j, починаючи з 2.0-alpha1 і закінчуючи 2.16.0, був відсутній захист від неконтрольованої рекурсії, що дозволяло атакуючому через маніпуляції зі значенням, що використовується при підстановці, викликати зациклювання, що призводить до вичерпання місця в стеку та аварій. Зокрема, проблема виникала під час встановлення таких значень, як «${${::-${::-$${::-j}}}}».
Додатково можна відзначити, що дослідники з компанії Blumira запропонували варіант атаки на вразливі Java-програми, які не приймають зовнішні мережеві запити, наприклад, можна атакувати таким чином системи розробників або користувачів Java-додатків. Суть методу в тому, що за наявності на системі користувача вразливих Java-процесів, що приймають мережеві з'єднання тільки з локального хоста (localhost), або обробляють RMI-запити (Remote Method Invocation, 1099 порт), атака може бути здійснена JavaScript-кодом, що виконується при відкритті користувачам у браузері шкідливої сторінки. Для організації з'єднання з мережним портом Java-програми при подібній атаці використовується API WebSocket, до якого на відміну від HTTP-запитів не застосовуються обмеження same-origin (WebSocket також може використовуватися сканування мережних портів на локальному хості з метою визначення наявних мережних обробників).
Також інтерес представляє опубліковані Google результати оцінки вразливості бібліотек, пов'язаних залежностями з Log4j. За даними Google, проблема торкається 8% від усіх пакетів у репозиторії Maven Central. Зокрема, уразливості виявилися схильні до 35863 Java-пакетів, пов'язаних з Log4j прямими і непрямими залежностями. При цьому Log4j використовується як пряма залежність першого рівня тільки в 17% випадків, а в 83% охоплених вразливістю пакетів прив'язка здійснюється через проміжні пакети, залежні від Log4j, тобто. залежності другого та вищого рівня (21% - другого рівня, 12% - третього, 14% - четвертого, 26% - п'ятого, 6% - шостого). Темпи виправлення вразливості поки залишають бажати кращого, через тиждень після виявлення вразливості з 35863 виявлених пакетів проблема усунена поки що тільки 4620, тобто. 13%.
Тим часом, Агентство з кібербезпеки та захисту інфраструктури США опублікувало екстрену директиву, яка зобов'язує федеральні агенції провести визначення інформаційних систем, схильних до вразливості в Log4j, і до 23 грудня провести встановлення оновлень, що блокують проблему. До 28 грудня організаціям наказано звітувати про виконану роботу. Для спрощення виявлення проблемних систем підготовлено список продуктів, у яких підтверджено прояв уразливості (у списку понад 23 тисячі додатків).
Джерело: opennet.ru