В библиотеке 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 уязвимости оказались подвержены 35863 Java-пакетов, оказавшихся связанных с Log4j прямыми и косвенными зависимостями. В относительных показателях проблема затрагивает 8% от всех пакетов в репозитории Maven Central. При этом Log4j используется в качестве прямой зависимости (зависимости первого уровня) только в 17% случаях, а в 83% охваченных уязвимостью пакетов привязка осуществляется через промежуточные пакеты, зависимые от Log4j, т.е. зависимости второго и более высокого уровня (21% – второго уровня, 12% – третьего, 14% – четвёртого, 26% – пятого, 6% – шестого).
Темпы исправления уязвимости пока оставляют желать лучшего, через неделю после выявления уязвимости из 35863 выявленных пакетов проблема устранена пока только в 4620, т.е. в 13%.
Тем временем, Агентство по кибербезопасности и защите инфраструктуры США опубликовало экстренную директиву, обязывающую федеральные агентства произвести определение информационных систем, подверженных уязвимости в Log4j, и до 23 декабря произвести установку обновлений, блокирующих проблему. До 28 декабря организациям предписано отчитаться о проделанной работе. Для упрощения выявления проблемных систем подготовлен список продуктов, в которых подтверждено проявление уязвимости (в списке более 23 тысяч приложений).