Они выявили еще одну уязвимость Log4j 2 и пометили ее как опасную.

log4j

Несколько недель назад новости о проблемах безопасности Log4j перевернули многих пользователей сети с ног на голову, и это то, что это один из недостатков, который использовался больше всего и который многие эксперты назвали «самым опасным в мире». long time », Из уязвимостей, о которых стало известно в сети, поговорим о некоторых из них. здесь, в блоге и на этот раз мы нашли новость о другом.

И это несколько дней назад появилась новость об обнаружении очередной уязвимости в библиотеке Log4j 2 (который уже указан в CVE-2021-45105) и который, в отличие от двух предыдущих проблем, был классифицирован как опасный, но не критический.

Новая проблема допускает отказ в обслуживании и проявляется в виде петель и аварийных завершений при обработке определенных строк.

Уязвимость влияет на системы, использующие контекстный поиск, например $ {ctx: var}, чтобы определить формат вывода журнала.

Лас- Log4j версий от 2.0-alpha1 до 2.16.0 не имеет защиты от неконтролируемой рекурсии., что позволял злоумышленнику манипулировать значением, используемым в подстановке вызвать бесконечный цикл, в котором не хватит места в стеке, что приведет к зависанию процесса. В частности, проблема возникла при подстановке таких значений, как "$ {$ {:: - $ {:: - $$ {:: - j}}}}".

Кроме того, Можно отметить, что исследователи Blumira предложили атаку на уязвимые Java-приложения. которые не принимают запросы из внешних сетей, например, таким способом могут быть атакованы системы разработчиков или пользователей приложений Java.

Суть метода в том, что при наличии уязвимых Java-процессов в системе пользователя, которые принимают сетевые соединения только с локального хоста (localhost) или обрабатывают RMI-запросы (Remote Method Invocation, порт 1099), атака может быть выполнена с помощью исполняемого кода JavaScript когда пользователь открывает вредоносную страницу в браузере. Чтобы установить соединение с сетевым портом Java-приложения при такой атаке, используется WebSocket API, к которому, в отличие от HTTP-запросов, не применяются ограничения на одно происхождение (WebSocket также может использоваться для сканирования сетевых портов на локальном компьютере). хост для определения доступных сетевых драйверов).

Представляют интерес результаты оценки уязвимости библиотек, связанных с зависимостями с Log4j, опубликованные Google. По данным Google, проблема затрагивает 8% всех пакетов в репозитории Maven Central.

В частности, уязвимостям подверглись 35863 4 связанных с Log4j пакетов Java с прямыми и косвенными зависимостями. В свою очередь, Log17j используется как прямая зависимость первого уровня только в 83% случаев, а в 4% пакетов, охваченных уязвимостью, привязка осуществляется через промежуточные пакеты, которые зависят от Log21j, т.е. зависимости второго и высшего уровня (12% - второй уровень, 14% - третий, 26% - четвертый, 6% - пятый, XNUMX% - шестой).

Темпы исправления уязвимостей по-прежнему оставляют желать лучшего, через неделю после выявления уязвимости из выявленных 35863 4620 пакетов проблема исправлена, пока только в 13, то есть на XNUMX%.

Изменения пакетов необходимы для обновления требований к зависимостям и замены привязок старых версий фиксированными версиями Log4j 2 (Java-пакеты практикуют привязку к определенной версии, а не к открытому диапазону, позволяющему установить последнюю версию).

Устранению уязвимости в Java-приложениях препятствует тот факт, что программы часто включают в себя копии библиотек в поставке, и этого недостаточно для обновления версии Log4j 2 в системных пакетах.

Между тем Агентство США по защите инфраструктуры и кибербезопасности издало чрезвычайную директиву, требующую от федеральных агентств выявлять информационные системы, затронутые уязвимостью Log4j, и устанавливать обновления, которые блокируют эту проблему, до 23 декабря.

С другой стороны, до 28 декабря было дано руководство, согласно которому организации обязаны отчитываться о проделанной работе. Для упрощения выявления проблемных систем составлен список продуктов, в которых подтверждено проявление уязвимости (всего в списке более 23 тысяч приложений).

Наконец, Стоит отметить, что уязвимость была исправлена ​​в Log4j 2.17, который был опубликован несколько дней назад. а пользователям, у которых отключены обновления, рекомендуется выполнить соответствующее обновление, в дополнение к тому, что опасность уязвимости снижается тем, что проблема проявляется только в системах с Java 8.

источник: https://logging.apache.org/


Будьте первым, чтобы комментировать

Оставьте свой комментарий

Ваш электронный адрес не будет опубликован. Обязательные для заполнения поля помечены *

*

*

  1. Ответственный за данные: AB Internet Networks 2008 SL
  2. Назначение данных: контроль спама, управление комментариями.
  3. Легитимация: ваше согласие
  4. Передача данных: данные не будут переданы третьим лицам, кроме как по закону.
  5. Хранение данных: база данных, размещенная в Occentus Networks (ЕС)
  6. Права: в любое время вы можете ограничить, восстановить и удалить свою информацию.