Přesnější by bylo napsat, že zranitelnost se týká knihovny log4j 2. Původní knihovny log4j se netýká – a log4j 2 je tak výrazný upgrade, že je to považováno za novou knihovnu a je zvykem ji explicitně označovat tou dvojkou.
Apache Struts 2 nebo Apache Solr opravdu používají tu knihovnu log4j 2, ale spousta staršího softwaru bude používat původní log4j (1.x), která zranitelná není.
tady se už vynořují první ukázkové útoky https://github.com/YfryTchsGD/Log4jAttackSurface, verze javy v tom očividně nehraje velký význam
Tohle se podle mne týká jenom útoku přes LDAP, což je podle mne nějaký velmi okrajový případ a je docela nešťastné, že to v tom oznámení vůbec zmiňují. Pravděpodobně je to proto, že přes LDAP na tu chybu přišli – vypadá to, že autoři nepochází ze světa Javy, protože také celou dobu píšou o knihovně log4j a ne log4j 2, což je pro lidi, kteří se okolo Javy pohybují, dost matoucí.
10. 12. 2021, 17:44 editováno autorem komentáře
log4j 1.x je už EOL, už trochu vousaté a také obsahuje řadu RCE, např. CVE-2019-17571, takže to výhra není, ale také používáme.
Podle mě to označují správně, artefactId je log4j a před 2.15 neexistuje udržovaná verze, která by nebyla zranitelná.
Ten ldap tam je nejspíš kvůli tomu, že zranitelnost se objevila ve spojení s com.sun.jndi.rmi.object.trustURLCodebase a to je věc, kterou ldap používá. Věřím ale, že těch možností postupně se objeví více. Zatím jsem nezkoumal, primárně jsme testovali produkce a záplatovali.
10. 12. 2021, 19:14 editováno autorem komentáře
Sami autoři to označují jako Log4j 2 – ta dvojka ale označuje verzi, proto není součástí artifactId ale až čísla verze. A když to chcete brát podle Maven repo, verze 1.x měla jiné groupId. Z log4j 1.x se přecházelo hlavně na Logback, a pokud to někdo neřešil, zůstal u log4j 1.x. Vlastně mne teď překvapilo, kolik projektů Log4j 2 používá
už vidím co tam dělá ldap. Třída JNDI umožňuje použít rmi nebo ldap, takže zranitelnost je hlavně právě s využitím těhle protokolů. Rmi je pandořina skříňka, to je děsivá funkce.
Vstup do log tříd může být odkudkoliv, nelze tedy snadno filtrovat na FW. Stejně tak cíl útoku může být jakýkoliv, takže izolace na FW je jen částečné řešení. My jsme zatím provedli násilné nahrazení artefaktu log4j-core v aplikacích a překompilování chvilku bude trvat.
Nechme dohady o verzi stranou, nezáleží na tom tolik, log4j2 je popisnější, ale nevynucoval bych ho.