Názory k článku
Zranitelnosti Log4j nekončí, aktualizujte na 2.17.0

Kdo ještě v posledních letech nepřešel, tak v lednu bude přecházet na http://www.slf4j.org/ ;-)

slf4jFTW

Naopak log4j 2 bude celkem bezpečnostně zanalyzovaný. Takový velký security audit.

Dokud se log4j 2 nezbaví toho nesmyslu s interpretováním logovaných zpráv tak to bude pořád nebezpečná věc. Na co proboha myslel ten kdo to tam naimplementoval? Vždyť to je úplně k ničemu, jen to působí problémy! Neznám ve svém okolí nikoho kdo by chtěl aby logovací framework logované zprávy jakkoliv pozměňoval.

Java nema globalni promenne. Pozadavek na to aby logovana zprava obsahovala nejakou kontextovou hodnotu je pomerne casty.
Napr, kdyz se dozvim, ze SQL dotaz selhal ale nevim s jakymi parametry byl spusten.

Taky se stava, ze je potreba logovani kvuli nejakemu problemu totalne prekopat, a zobrazit dalsi detail. Flexibilita je u logovacich frameworku dulezita, jen se to nesmi prehanet.

Pro logování kontextových zpráv se ale používá MDC (Mapped Diagnostic Context). Pro dodatečnou interpretaci logovací zprávy nebo dalších parametrů není žádný důvod.

Java má statické proměnné což by se dalo považovat za globální proměnné. Ve spoustě případů je vhodnější použít ThreadLocal. To ale nic nemění na tom že co se do logovacího frameworku pošle to se má zalogovat a ne nějak podivně interpretovat - taková logika už do logovacího frameworku nepatří, zbytečně ho komplikuje a zanáší chyby.

Už konečně zakázali rekurzivní lookups? Pokud ne, tak pořád budou nové a nové chyby.

Ahoj, asi se ptám hloupě, ale nějak se v tom ztrácím.

Obecně mám: Tomcat 9 + Spring + sadu dalších jar. Reálně je mezi maven dependencies:

- slf4j-log4j12-1.7.31.jar ... žádná známá zranitelnost
- log4j-1.2.17.jar ... 2 zranitelnosti
- CVE-2019-17571 ... nepoužívám v logování sít - myslím, že jsem ok.
- CVE-2021-44228 ... nepoužívám zmiňovaný apender.

Je to podle vás ok, nebo co prosím doporučíte?

Máte tam slf4j jako logovací API, takže můžete použít jakoukoli implementaci podporovanou slf4j. Vyhoďte log4j (a slf4j-log4j12) ze závislostí a místo něj použijte pro logování logback--classic. A pokud byste v té aplikaci náhodou používal přímo API log4j (vy nebo nějaká knihovna), použijte můstek log4j-over-slf4j – ten implementuje API log4j (1.x) a přesměrovává jeho volání na slf4j.

vymazat z log4j-1.2.17.jar classy
org/apache/log4j/­net/JMSAppender­.class
org/apache/log4j/­net/SocketSer­ver.class
a restartnut aplikaciu alebo cely tomcat.

V podstatě je to overkill, obě tyto nejdou normálně nijak zneužít. Přesněji řečeno: pokud má útočník možnost zneužít JMSAppender nebo SocketServer, tak má rovnou i možnost zneužít několik tisíc jiných tříd ve Springu. A minimálně pár desítek (ne-li stovek) tříd v Tomcatu.

Takže tohle mazání má smysl jen pokud se automaticky smaže celý Spring. A jeho závislosti. A Tomcat.

A víte, že to vůbec není špatný nápad? :D

Ale až to vychytaj, bude log4j2 nelépe prověřený logovací subsystém. Takže já zůstávám

A možno je to taký clusterfuck, že sa teraz ukázala len špička ľadovca.

Nebo jinak: Proč by ta „část ledovce pod vodou“ měla být lepší? :P

to je dost naivní přístup, naopak současná aktivita ukazuje, že vývojáři (jsou to dobrovolníci a dělají jak umí) vůbec nebrali zřetel na bezpečnost při návrhu celé aplikace, kód neprošel detailním auditem, chybí dodržování základních pravidel napříč code base.

Jen teď patche pro 2.17.0 obsahují 2500 přidaných řádků, 1300 odstraněných a to v 165 souborech. Snaží se tam dál udržet podporuje pro lookups a kdoví kolik chyb v tomhle vzniklo.

Tohle je už trochu bouře ve sklenici vody. Tenhle DoS útok je dost nepravděpodobný. Jsou potřeba dva předpoklady 1. škodlivý string musí být uložen do ThreadContext (MDC) 2. musí se používat v layoutu lookup tj. ${ctx:loginId} nevím jestli to někdo někde používá, protože lze místo toho použít %X{loginId} nebo ještě lépe PatternConverter

Už chápu, proč jsme v mavenu léta používali <version>RELE­ASE</version> a byl klid :) Ale ten už nám taky zakázali, hold lidi z npm vědí, co je nebezpečné.