Они выявили еще одну уязвимость 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. Права: в любое время вы можете ограничить, восстановить и удалить свою информацию.