Vlákno názorů k článku
Zranitelnosti Log4j nekončí, aktualizujte na 2.17.0 od anonym - Ahoj, asi se ptám hloupě, ale nějak se...

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