Leider werden bei diesem Thema immer wieder gern diverse Randbedingungen vergessen:
1. Zunächst mal ist nur "Log4j 2" betroffen - nicht das klassische "Log4j 1.x"
2. "Log4j 2" ist (zum Glück) nicht so sehr verbreitet wie viele denken. Es konnte Log4j 1.x nie richtig beerben - aus meiner Sicht verständlicherweise da unnötig dick, fett, gross, schwer komplex. Man sieht heute eher Slf4j zusammen mit z.B. Logback als Backend
3. Nicht das Logging-Framework "Log4j 2" lädt Code nach un führt in aus sondern das JNDI-Framework, welcher wiederum Teil der JVM ist (aka JRE oder JDK oder schlicht "Java"). Hier ist dieses Risiko "Code (Java-Bytecode) via JNDI nachladen und auch gleich ausführen" aber seit ~Dez 2018 mit der Version 8u191 (bzw. 11.0.1 bei der Java11-Serie) geschlossen - also seit 3 Jahren (https://bugzilla.redhat.com/show_bug.cgi?id=1639834#c2)
4. Jeder einigermassen nicht-hirnlose Betreiber von Applikationen (egal ob Java oder andere Technologie) tut dies in einem isolierten Netz. Applikation, App-Server, Server, DB-Server, Whatever-Server/DockerContainer/VM/ESX/Kube-Pod/... muss i.d.R. keinen allgemeinen Zugang zum Internet haben. Das Öffnen einzelner URLs mag zwar oft nötig sein - aber sicher nich "ungeprüft jede mögliche Kommunikation mit irgendwo-auf-der-Wlt via jeglichen Protokollen"
Nicht falsch verstehen: Es IST ein Problem - aber ein seit 3 Jahren gelöstes (via JVM) und neu auch via Log4j-Library selber. Also alle mal auf dem Teppich bleiben und durchatmen
Das Posting wurde vom Benutzer editiert (13.12.2021 11:23).