ob der Dienst im Internet erreichbar ist, spielt keine Rolle. Es reicht, wenn eine vulnerable Version von Log4j eine Textzeile verarbeitet, die JNDI-Verbindungszeichenketten enthält. Das Problem ist ja gerade, dass man die „Lücke“ auf kein Feld eines Protokolls einschränken kann. Es könnte auch der HTTP-Header für HTTP-Accept-Encoding sein, den das JavaScript als Ajax-Request generiert oder das Feld Username, den ein nur intern erreichbarer LDAP-Server in sein Fehlerprotokoll schreibt.
Niemand kann verhindern, dass irgendein Nutzer im LAN eine Webseite aufruft, wo ein JavaScript eine Socketverbindung zu jeder IP im LAN aufbaut und die passende Zeichenkette als Username, Header, URL-Parameter o.ä. übermittelt. Die Lücke sorgt dann dafür, dass von der vulnerablen Software von intern der Zugriff nach außen erfolgt, um Schadsoftware nachzuladen.
Aha, Solr ist auch betroffen.
Ich habe diese Suchmaschine in meine Moodle-Installation eingebaut - die macht auch richtig Spaß ! Hat aber das log4j-Problem…
Hier findet sich eine Beschreibung eines security-fixes:
man kann entweder warten, bis die log4j-Bibliothek 2.15 (glaubich) als Download zur Verfügung steht oder versuchen, über Optionen eine erste Filterung der Aufrufe zu erreichen - bei Solr ist das die Zeile: SOLR_OPTS="$SOLR_OPTS -Dlog4j2.formatMsgNoLookups=true"
in der solr.in.sh.
Wenn man firewallmäßig den outgoing traffic filtert, kann man Aufrufe nach außen (z.B. ldap(s)) unterbinden.
… vorhin ist mir noch so eine Anwendung eingefallen, die Java benutzt: ASV … ob die wohl betroffen sind?
Und das NEO Portal: das ist im Netz erreichbar …
Das hilft nur sehr eingeschränkt und ist ein Kampf gegen Windmühlen. Niemand hindert den Angreifer seinen LDAP-Server auf Port 80 oder 443 zu betreiben. Und diese Ports sind immer direkt oder indirekt (über Webproxy, ggf. als TLS-Verbindung getunnelt) erreichbar.
ich hab auf meinem Dokuwiki server kein log4j finden können: ich hab aber nur mit locate danach gesucht (mein DokuWiki ist nicht in einem Docker Container).
Außerdem hab ich im Web nach Hinweisen gesucht (also nach log4j und dokuwiki) und da auch nichts brauchbares gefunden.
Zu OpenSchulportfolio kann ich nichts sagen: das setze ich nicht mehr ein.
habt Ihr schon mal bei Eurer Bank nachgefragt inwieweit Online-Banking noch sicher ist? Ich hab’s gemacht. Mündlich meinte man es ist sicher. Auf die Frage wo ich das nachlesen kann gab es keine Antwort. Auf jeden Fall will man meine Anfrage an den zuständigen Mitarbeiter weiter geben und mir dann schreiben was Sache ist.
ich dachte mir: komm, such mal genauer … und wollte mir das hier holen:
um das dazu (nicht zwingend) benötigte maven zu installieren würde ich um die 50 java Pakete auf meinem nextcloud server installieren müssen … nein Danke…
… das hätte ich mir denken können: ASV ist ganz stolz drauf, dass sie von der log4j Problematik nicht betroffen sind.
Warum?
Weil die eingesetzt log4j Version zu alt ist
wisst Ihr, wie das mit den Belwue-Moodles aussieht? Kann man die einer bestimmten IP oder einem IP-Range zuordnen oder wie sieht das dort aus mit deren Clustern, Loadbalancern etc.?
Da reihen sie sich ein in die lange Liste großer Softwareprojekte/Anbieter, die auch erklären man könne beruhigt sein, schließlich seien nur die Remote-Code-Execution-Lücken aus Version 1.x noch online.
