как-то непонятно, кому пришло в голову интерполировать параметры шаблона, хотя совсем недавно чет подобное про hibernate-validator читал - там сообщения об ошибках интерполируют.

faustgreen,

вот судя по документации (https://logging.apache.org/log4j/2.x/manual/lookups.html) и FR (https://issues.apache.org/jira/browse/LOG4J2-2109) log4j2 по-умолчанию (уже нет) интерполирует все значения плейсхолдеров в шаблоне, интерполировать оно умеет много чего в том числе из JNDI брать данные (ну типа выглядит полезно: мы хотим в лог писать к примеру имя приложения и при этом саму конфигурацию логгера упаковывать в приложение - вот шаблон настроили, а имя в JNDI прописали, красота), вот в эти лукапы JNDI засунули еще поддержку LDAP, а грабли с LDAP описывали еще в 2015 году: https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE.pdf - жавский клиент когда сущности из каталога выбирает может какие-то атрибуты превращать в объекты (десериалиовывать) - вот он и RCE.

Скриншоты в интернетах демонстрируют, что на определенный пейлоад из сети атакуемого были DNS-запросы, резолвящие LDAP-хост, т.е. это детектирование наличия log4j2

да вот не совсем... com.sun.jndi.ldap.object.trustURLCodebase=false запрещает классы непонятно откуда грузить, однако саму по себе десериализацию данных прилетевших из LDAP никак не запрещает

ну я ссылку на презентацию давал, там вот написано:

авторIf com.sun.jndi.ldap.object.trustURLCodebase is true
- attackers can provide their own classes
- else, attackers will be able to use available gadgets in classpath


насколько я помню после "выпуска" CVE-2015-6420 был некий вой про то, что библиотека якобы не виновата, а просто нефиг десериализовывать данные непонятно откуда, ну вот, прилетела-таки обратка.

мне больше всех вот этот понравился: сам по себе log forging - это уже косяк: https://cwe.mitre.org/data/definitions/117.html, а тут оно прямо из коробки было

там кстати выяснили, что предыдущее исправление было так себе :

CVE-2021-45046It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. This could allows attackers with control over Thread Context Map (MDC) input data when the logging configuration uses a non-default Pattern Layout with either a Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC) to craft malicious input data using a JNDI Lookup pattern resulting in a denial of service (DOS) attack. Log4j 2.15.0 makes a best-effort attempt to restrict JNDI LDAP lookups to localhost by default. Log4j 2.16.0 fixes this issue by removing support for message lookup patterns and disabling JNDI functionality by default.

теперь всем срочно обновлять LogBack - там тоже "RCE": https://jira.qos.ch/browse/LOGBACK-1591

Stanislav Bashkyrtsev,

проблема в том, что подход со стороны людей "занимающихся безопасностью" довольно формальный: есть CVE - значит нужно чтобы было исправлено, причем CVE-2021-42550 - еще не самое что я видел, MITRE заводит и похлеще к примеру:
- у чуваков на парсинге инта стэктрейс вываливался, им влепили DoS (падает же) и Information Disclosure (по стэку же можно версию жавы определить!) из-за чего по калькулятору насчитали аж 9
- каким-то типам влепили, что вот если подключиться дебагером, то можно все сломать

если переписку читать, то там позиция Ceki довольно странная, в том плане что ему прямо на ходу еще пяток таких же "RCE" придумали, но в целом наверное проще "починить" чем объяснять упоротым что они не правы. Однако тенденция настораживает: в спринге же можно сделать include *.xml - теперь это RCE.