Ja. Jeder 404 Error, der geloggt wird, hat Benutzereingaben - die URL. (Was das Hautp-Angriffszenario vermutlich ist)
Das ist die spannende Frage, da scheint einiges zusammen zu kommen. Grundsätzlich bieten Logging Frameworks oft String Formatierungen an, um String sauber zusammen zu bauen. Hier scheint es so zu sein, was ich aus dem Artikel entnehme, das einfach zu mächtige Tools/Frameworks dahinter stehen und die Kombination niemand gesehen hat. Oftmals (was im Server-Umfeld auch sinnvoll ist) sind solche Ersetzungsmechanismen mächtiger als reine String Lookups, so können je nach Typ der zu ersetzenden Variable Logik ausführen, um "Remote-Lookups" zu machen. Und genau das scheint hier zu passieren - es wird ein LDAP-Server kontaktiert und das Ergebnis wiederum ausgeführt.
Ja, normalerweise
Da ist dann aber wichtig: Das BSi hat die Schwachstelle hochgestuft, denn zum Ausnutzen ist dieser Kontakt nicht notwendig.
Der Fehler wurde bereits behoben. Du musst nur auf die Version 2.15 updaten ... was auch mit recht viel Arbeit verbunden sein kann.
Immerhin ist es bei uns im Projekt nur eine Dependency austauschen und wir sind (vermutlich) eh nicht betroffen, weil wir log4j nur an einer einzigen Stelle verwenden, wo keine User-Eingaben reinkommen. (+Die Server Admins haben die Workarounds bereits am Freitag aktiviert)Die Richtung Web -> Server ist wichtig, umgekehrt aber nicht. Also alles, was Benutzer-Request entgegennimmt und mit log4j loggt. Heise dramatisiert da etwas...Da ist dann aber wichtig: Das BSi hat die Schwachstelle hochgestuft, denn zum Ausnutzen ist dieser Kontakt nicht notwendig.
Warnstufe Rot: Log4j-Zero-Day-Lücke bedroht Heimanwender und Firmen
Systeme abschalten, Verbindungen blockieren: Das BSI rät wegen der Zero-Day-Lücke in Log4j zu extremen Maßnahmen, Schadcode soll direkt ausführbar sein.www.heise.de
Naja, aber eine Anwendung ohne Kommunikation ist in den seltensten Fällen sinnvoll.
Also ohne irgend jemandem zu nahe treten zu wollen:
Das ist ja das Geschiss. Irgendeine Lib reicht ggf. schon. Eine outbound Firewall sehe ich auch eher als last line of defense. Da ist es mir schon lieber, wenn ich das Problem an der Wurzel packen kann. Das ist zwar jetzt etwas Aufwand, danach habe ich aber meine Ruhe
Ja von subversiven Elementen innerhalb des Firmennetzwerks bin ich jetzt mal nicht ausgegangen... Aber falls doch würde schon ein USB-Stick reichen.
nein, übersiehst nichts, aber manchmal beinhaltet eine andere Lib (die zum Beispiel via Maven eingebunden wird) log4j, dann ist es glaube ich nicht ganz so einfach.
Das müssen nicht mal subversive Elemente sein. Der Punkt ist - die meisten Anwendungen verarbeiten Daten die die von außen (außen = Außerhalb der eigenen Anwendung) kommen. Ob die jetzt aus dem Internet, Intranet, User-Eingaben, maschinelle Verarbeitung von irgendwas etc. kommen - egal. Es sind Daten die von außerhalb der Anwendung kommen.Ja von subversiven Elementen innerhalb des Firmennetzwerks bin ich jetzt mal nicht ausgegangen... Aber falls doch würde schon ein USB-Stick reichen.
Deswegen ja im eigenen Dependency Management die Version festlegen - damit überschreib ich die Version, die Libs mitbringen
Genau das meinte ich...
Das ist gut, denn dann braucht man nicht auf die neuere "3rd party" Lib warten, sondern kann sich selber darum kümmern.
Wenn Sie keine Daten von außen verarbeitet. Ob Daten geloggt werden kann man selten abschließend beantworten. Dazu kennt man den Code der Bibliotheken zu wenig
Ui kannst du mir verraten wie? Dachte mir schon, dass die IDE das doch kann
nur wie?
Dependency Hierachy - kann Maven von Haus aus und sollte jede IDE darstellen können. Wie es in Intellij geht - keine Ahnung, ich bin Eclipse Nutzer
mvn dependency:tree siehe hier: https://stackoverflow.com/questions/3342908/how-to-get-a-dependency-tree-for-an-artifact
ich denke schon, @mihe7 hatte das angedeutet...
Da ist keine Abhängigkeit dabei, die kritisch ist. log4j-core ist das problem, die nicht slf4j log4j Fassade
Das frag ich mich auch...ist doch nur ne Log Ausgabe.
Du kommst runter bis zur Maschinenebene...
Kombination von - im Einzelnen gut klingenden - aber im Gesamtkontext katastrophalen Entscheidungen.
Nachtrag:Du kommst runter bis zur Maschinenebene...
Und du siehst nur die Spitze des Eisbergs
Nein, es reicht schon, wenn ein Anfrage-Header manipuliert wird (also wenn in diesem etwas "maliziöses" steht) und dieser geloggt wird.
Debugging... Das kann überdies unbewusst geschehen.
Mir fällt kein Grund ein, warum Benutzerreingaben nicht in Logs auftauchen - eher im Gegenteil, die gehören in Logs.
Also es gibt genug Daten, wo das problematisch ist. Passwörter z.B. Aber auch sensible personenbezogene Daten möchte man nicht im Log haben.
Es geht weniger ums Speichern der Logs, sondern um das Auslesen. Wenn der Text beim Auslesen interpretiert wird, dann kann ein Fehler auftauchen. Da Interpretieren beim Auslesen aber eine gewünschte Funktion ist, muss man Text, der nicht interpretiert werden soll, als "pure text" kennzeichnen, bzw. verpacken.
Was log4j ab 2.16.0 auch genau standardmäßig macht, da wird der ganze Ersetzungsmechanismus nur auf das Pattern angewendet und nicht auf Text, der von "außen" kommt, also aus der Anwendung.
Klar, ich will natürlich nicht alles logen - aber an vielen Stellen hat man entweder explizit "Externe Daten" in der Log-Meldung (Beispiel 404 Error) oder Implizit - weil man im Falle eines Exception Logs wenig Kontrolle darüber hat, was genau in der Exception Message steckt, weil die ja oft aus einer tiefen Schicht kommt und nicht selbst erzeugt wird. Klassiker z.B. beim Versucht Werte die zu groß sind speichern, da kommt teilweise auch eine Meldung, dass der Wert zu groß ist und der Wert ist in der Meldung enthalten. Ich will nur drauf hinweisen, das externe Daten in Log-Meldungen enthalten sind, kommt sehr oft vor und ist oft auch erwünscht.
Der Fehler wurde in log4j 2.15 ja auch schon behoben.
Ganz klar. Ich habe auch nur Beispiele für Eingaben genannt, die ich nicht logge. Dazu gehören die meisten Angaben aber nicht und da war ich auch voll und ganz Deiner Meinung - die landen im Logfile alleine schon um da Abläufe nachvollziehen zu können (Natürlich in Abhängigkeit zum Loglevel!)
Jein. In 2.15 wird das Pattern Replacement auch noch auf Messages gemacht - nur das man über JNDI beliebige Java-Klassen von beliebigen IPs laden lann, wurde gefixed.
Ehm - dem muss ich mal widersprechen. Ich muss schon aktiv einen JNDI Lookup anstoßen, automatisch passiert da mal gar nichts.
Diese Hinweis entstammt sinngemäß aus einem Hinweis unserer Sicherheitsfirma, die mit unserem CERT zusammenarbeitet.
