ОБНОВЛЕНИЕ: 2021-12-18...
Не забывайте всегда проверять последнюю информацию из ресурсов, перечисленных ниже.
CVE-2021-45105... 2.16.0 и 2.12.2 больше не являются действительными исправлениями! Текущие версии исправления: 2.17.0 (Java 8) и 2.12.3 (Java 7). Во всех других версиях Java необходимо использовать временный подход (удаление/удаление файла JndiLookup.class из JAR-файла log4j-core.
Я обновил свое сообщение ниже соответственно.
Прямо отвечая на вопрос:
Перейти к Ветка Reddit: log4j_0day_being_exploited
и Ctrl+ф за .class и .jar рекурсивный охотник. Запустите программу там, и если она что-нибудь найдет, исправьте.
Затем перейдите на тот же сайт и Ctrl+ф за Консультации поставщиков. Выполните поиск в этих списках, чтобы узнать, используете ли вы какое-либо из уязвимых программ. Если да и обновление доступно, обновите.
Исправление:
CVE-2021-45046 ... CVE-2021-44228 ... CVE-2021-45105
Хотя большинство людей, которым нужно знать, вероятно, уже знают достаточно, чтобы делать то, что им нужно, я подумал, что все же на всякий случай поместил бы это...
- Следуйте инструкциям в этих ресурсах... они могут измениться, но
По состоянию на 18 декабря 2021 г.
Это в основном
- Удалите JAR-файлы log4j-core, если это возможно.
- С обеих работающих машин для немедленного исправления И
- в вашем исходном коде / файлах управления исходным кодом, чтобы будущие сборки / выпуски / развертывания не перезаписывали изменения
- Если это невозможно (из-за зависимости), обновите их
- Если вы используете Java 8, вы можете перейти на log4j 2.17.0+.
- Если вы используете Java 7, вы можете перейти на log4j 2.12.3.
- Если вы используете более старую версию Java, вам необходимо выполнить обновление до новейшей версии Java, а затем использовать новейшую версию Log4J.
- Опять же, эти изменения должны происходить как на работающей машине, так и в коде.
- Если ни один из них невозможен по какой-либо причине... тогда существует зазор без исправления, заключающийся в удалении файла JndiLookup.class из JAR-файлов log4j-core.
- В Linux есть однострочный вариант остановки разрыва с использованием
молния Команда, которая по умолчанию входит в состав большинства дистрибутивов Linux.
zip -q -d "$LOG4J_JAR_PATH" org/apache/logging/log4j/core/lookup/JndiLookup.class
- На момент написания в большинстве онлайн-руководств по опции Stop Gap в Windows говорится, что нужно сделать следующее (опять же... при условии, что вы не можете выполнить один из указанных выше вариантов удаления JAR или обновления):
- Установите что-то вроде 7-zip
- Найдите все ваши JAR-файлы log4j-core и для каждого из них выполните следующие действия...
- Переименуйте JAR, чтобы изменить расширение на
.zip
- Используйте 7-zip, чтобы разархивировать JAR (который теперь имеет
.zip расширение)
- Найдите и удалите файл JndiLookup.class из разархивированной папки.
- Путь
\path\to\unzippedFolder\org\apache\logging\log4j\core\lookup\JndiLookup.class
- Удалите старый файл JAR (который теперь имеет расширение .zip)
- Используйте 7-zip, чтобы повторно заархивировать папку
- Переименуйте новую папку .zip, чтобы изменить расширение на
.банка
- Есть также несколько вариантов использования Power Shell.
Это нормально, если у вас есть только 1 или 2 JAR-файла, и вы не возражаете против установки 7-zip или у вас есть PowerShell для этого. Однако, если у вас много JAR-файлов или вы не хотите устанавливать 7-zip и не имеете доступа к Power Shell, я создал сценарий VBS с открытым исходным кодом, который сделает это за вас без необходимости установки любое дополнительное программное обеспечение. https://github.com/CrazyKidJack/Windowslog4jClassRemover
Прочтите README и примечания к выпуску https://github.com/CrazyKidJack/Windowslog4jClassRemover/релизы/последние
