В библиотеке 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 2 (в Java-пакетах практикуется привязка к конкретной версии, а не открытому диапазону, допускающему установкой самой свежей версии). В Java-приложениях устранение уязвимости затруднено тем, что часто программы включают в поставку копию библиотек и обновления версии Log4j 2 в системных пакетах недостаточно.
Тем временем, Агентство по кибербезопасности и защите инфраструктуры США опубликовало экстренную директиву, обязывающую федеральные агентства произвести определение информационных систем, подверженных уязвимости в Log4j, и до 23 декабря произвести установку обновлений, блокирующих проблему. До 28 декабря организациям предписано отчитаться о проделанной работе. Для упрощения выявления проблемных систем подготовлен список продуктов, в которых подтверждено проявление уязвимости (в списке более 23 тысяч приложений).
Уязвимости подвержены системы, использующие при определении формата вывода в лог контекстные запросы (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 2 (в Java-пакетах практикуется привязка к конкретной версии, а не открытому диапазону, допускающему установкой самой свежей версии). В Java-приложениях устранение уязвимости затруднено тем, что часто программы включают в поставку копию библиотек и обновления версии Log4j 2 в системных пакетах недостаточно.
Тем временем, Агентство по кибербезопасности и защите инфраструктуры США опубликовало экстренную директиву, обязывающую федеральные агентства произвести определение информационных систем, подверженных уязвимости в Log4j, и до 23 декабря произвести установку обновлений, блокирующих проблему. До 28 декабря организациям предписано отчитаться о проделанной работе. Для упрощения выявления проблемных систем подготовлен список продуктов, в которых подтверждено проявление уязвимости (в списке более 23 тысяч приложений).
