Комментарии 18
тау далее
Тот факт, что библиотеку загрузили с GitHub более чем 400 000 раз.
Что? Это полное предложение?
кретическая
Появление самой уязвимости обусловлено архитектурой языка Java, который является полностью объектно-ориентированным. Благодаря некоторым приемам злоумышленники нашли способ передать исполняемый файл на исполнение…а Java при этом просто автоматически запускает его
Что? Вы точно в курсе как там всё работает?
киберазищты
обеспечиюват
Знаю, что для ошибок есть ctrl+enter, но тут совсем жесть какая то местами
Автора правильно критикуют за ОчЕпЯтки. )) Но советы дельные. Благодарю.
Вы уж извините, но это мой первый текст и хабр неделю его в песочнице держал. Это с одной стороны. А с другой стороны - я же указал в тексте, что эти методы снижают вероятность. Разве нет? Что делать тем, кто не может сделать апдейт до 2.17 прямо сейчас?
Неделю в песочнице — ну это вполне понять можно. Но качество текста это не оправдывает ни разу.
Появление самой уязвимости обусловлено архитектурой языка Java, который является полностью объектно-ориентированным. Благодаря некоторым приемам злоумышленники нашли способ передать исполняемый файл на исполнение…а Java при этом просто автоматически запускает его
Повторю предыдущего комментатора — у меня тоже полное впечатление, что вы просто вообще не в курсе, как там все работает. И объектно ориентированность тут никаким боком не стояла, и файл не передается (передается java-класс, а это не обязательно файл), и никто его не запускает (выполняется метод класса). Во всяком случае если в таких терминах это все описывать — это описание скорее дезориентирует, чем помогает. И не DNS там может быть, а изначально был LDAP.
У вас устаревшие данные и вы вводите людей в заблуждение.
LOG4J_FORMAT_MSG_NO_LOOKUPS недостаточно (https://logging.apache.org/log4j/2.x/security.html)
Other insufficient mitigation measures are: setting system property log4j2.formatMsgNoLookups or environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true for releases >= 2.10, or modifying the logging configuration to disable message lookups with %m{nolookups}, %msg{nolookups} or %message{nolookups} for releases >= 2.7 and <= 2.14.1.
The reason these measures are insufficient is that, in addition to the Thread Context attack vector mentioned above, there are still code paths in Log4j where message lookups could occur: known examples are applications that use Logger.printf("%s", userInput), or applications that use a custom message factory, where the resulting messages do not implement StringBuilderFormattable. There may be other attack vectors.
Версия 2.15, которую вы называете "новейшей", на данный момент (28.12.2021) а) уязвима к CVE-2021-45046 б) уж точно не новейшая.
Единственный правильный вариант по исправлению уязвимости в своих приложениях на данный момент - обновление на 2.17.
Спасибо про информацию о 2.15. Не знал. Поправил на 2.17. Но все остальное хотя бы улучшает ситуацию, если обновление пока невозможно.
Никак не улучшает. Или у вас есть RCE на серверах или нет. Промежуточного варианта тут нет. Именно этим эта уязвимость и ужастна. От нее фиг защитишься любыми внешними методами.
Можно было бы посоветовать проверить все места где вы логируете пользовательский ввод и не делать этого. Это тоже поможет. Но толку? Это по сути невозможно и точно сложнее обновления версии.
"Непоколебимый" энтерпрайз, уже который раз на моей памяти. Хе-хе-хе.
Новая RCE-уязвимость в библиотеке Apache Log4j
В открытых источниках опубликована информация об уязвимости в Apache Log4j версии 2.17.0. Уязвимость связана с отсутствием дополнительных элементов управления доступом JDNI в log4j.
CVE-2021-44832 (CVSSv3:6.6, SberCVSS: 5.4; Уровень риска: B) Злоумышленник имеет возможность создать вредоносную конфигурацию с помощью функции JDBC Appenders с источником данных, ссылающимся на URI JNDI, который позволяет выполнять удаленный код. Необходимо, чтобы злоумышленник имел разрешение на изменение файла конфигурации журналирования.
Уязвимые версии: Версии Apache log4j 2.17.0, 2.12.3, 2.3.1
Данной уязвимости подвержен только файл JAR log4j-core. Приложения, использующие только файл JAR log4j-api без файла JAR log4j-core, не подвержены уязвимости CVE-2021-44832.
На момент публикации обновления сообщается об отсутствии эксплойта в открытом или коммерческом доступе.
Для устранения уязвимости CVE-2021-44832 необходимо выполнить обновление log4j до версии 2.17.1(для Java 8 и новее), 2.12.4 (для Java 7), 2.3.2 (для Java 6).
Рекомендации Apache:
https://logging.apache.org/log4j/2.x/security.html
ну, чего - к 2.20 запатчимся наконец-то?
>>SberCVSS: 5.4
а что такое СберCVSS? Можете рассказать подробнее, как считается?
https://nvd.nist.gov/vuln/detail/CVE-2021-44832
CVSSv2 score 6.0 Medium
CVSSv3 score 6.6 Medium
остальное - просто привиделось
Уязвимость Log4j: методы устранения