Log4J Sicherheitslücke in OpenHab

Alternativ die Klasse Rauspatchen

Diese Funktion ist eh Blödsinn und wird nicht gebraucht . Ich Frage mich seit Freitag früh, wofür der Usecase da sein soll aus Logdaten ein Parsing machen zu wollen.

zip -q -d log4j-core-*.jar org/apache/[definition=12,9]logging[/definition]/log4j/core/lookup/JndiLookup.class

ein security patch (openhab 3.1.1) für das o.g. problem steht ab sofort bereit
https://github.com/openhab/openha…-j99j-qp89-pcfq

Zitat von tavoc

Ich Frage mich seit Freitag früh, wofür der Usecase da sein soll aus Logdaten ein Parsing machen zu wollen.

Bei Openhab vielleicht nicht. Andere Applikationen vielleicht schon. Ich darf nicht zu viel über das Preisgeben, was das Projekt macht in dem ich arbeite, aber wir bekommen aktuell um die 30 Millionen "Events" am Tag über unsere Applikation rein. Zu jedem Event wird ein Log geschrieben. Da kann ein Parsing schon hilfreich sein. Glücklicherweise haben wir Log4j nicht benutzt sondern nutzen Logback.

Ich habe hier hunderte Anwendungen, von genausoviel Anforderungen.
Arbeite im Kritis Bereich. Es ist der Horror rauszufinden was wo funktioniert und warum. In der Branche sind die Hersteller nicht die schnellsten.

Aber ein Parsing für JNdi ist mir immer noch unklar. Ich kann verstehen dass man alles in Richtung Backend schreibt und je nach Konfiguration dann Ereignisse Highlighted oder löscht. Aber warum sollte man einen request ausgehend machen wollen?

Zitat von tavoc

Aber ein Parsing für JNdi ist mir immer noch unklar. Ich kann verstehen dass man alles in Richtung Backend schreibt und je nach Konfiguration dann Ereignisse Highlighted oder löscht. Aber warum sollte man einen request ausgehend machen wollen?

Anderer Thread:

Zitat von darkside40

Eine schöne Erklärung gibt es auch hier:
http://golem.de/news/log4j-luecke-war…ht-hilft-2112-161757.html

dort heißt es:

Zitat

Der eigentliche Sinn des Lookups ist es, Daten abzufragen, um im Logfile für eine bessere Lesbarkeit zu sorgen. Zum Beispiel kann so bei einem LDAP-Server angefragt werden, wie der Klarname zu dem Usernamen lautet, der gerade einen Login versucht hat.

Danke, so gesehen macht es Sinn.

https://www.heise.de/meinung/Kommen….html?seite=all

Das liest sich zu den Thema gut.
Wir verschwenden auch bei uns unglaublich viel Potential Code zu scannen etc
Aber Leichen wie log4j Version 1 in den Abhängigkeiten werden nicht angemeckert. Obwohl das seit 2015 EOL ist.
Man fragt sich dann schon wie gut der Rest dann noch ist.

Zitat von tavoc

Aber Leichen wie log4j Version 1 in den Abhängigkeiten werden nicht angemeckert. Obwohl das seit 2015 EOL ist.

Naja. Jeder gescannte Code ist nur so gut wie die Pipeline, die ihn scannt, oder?

Log4j1 hat auf jeden Fall die genannte Schwachstelle nicht. Denn auhc das ist bei uns der Fall in dem ein oder anderen Projekt. Ich bin auch kein Freund davon EOL Software einzusetzen um von einer Lücke nicht betroffen zu sein. Man muss aber dazu sagen, dass sowas teilweise nicht "bewusst" eingesetzt wird. Es wird hin und wieder vom Kunden auch keine Weiterentwicklung bezahlt. Da muss man sich dann ggf. aus der Haftung nehmen lassen oder oder oder.

Das ist alles ein ziemliches "Für" und "Wider". Du hast genauso Recht wie derjenige der sagt "Log4j1 ist wenigstens nicht betroffen" und ich habe genauso Recht, wenn ich sage "Man setzt in produktiv-Systemen keine EOL Software ein".

Im Endeffekt ist es auch ein wenig ein Politikum. Man sollte jetzt halt nur nicht mit dem Finger auf den ein oder anderen Zeigen.

Zitat von tavoc

Man fragt sich dann schon wie gut der Rest dann noch ist

Welcher Rest? Was meinst du? Wie gut Log4j2 ist? Das ist so gut wie die Community, die es maintaint. Schließlich ist Log4j Community-driven soweit ich weiß. Auch wenn da die Apache-Foundation dahinter steckt. Das ist genauso gut wie Kodi

Ich meine automatisch geprüfter Code. Ich halte manuelle Prüfungen für sinnvoll.

Zum Hintergrund in den Verträgen fordere ich z.b. keinerlei eol, ud wir zahlen auch Migrationsprojekte. Bei wichtigen Projekten.

Leider werden Verträge unterschrieben, und alles zugesichert. Bzw wir haben SLA wo wir beispielsweise vorab informiert oder Software zurückportiert werden soll. Z.b. von Jboss zu wildfly.
Passiert aber nur sehr selten, wenn man mit dem Finger draufzeigt.

Wir nutzen halt auch opensource, bezahlen aber Firmen dafür, insbesondere für Support.

Ich finde man muss irgendwie beides machen. Einige Dingen sollten und müssen automatisiert werden. Allein schon aus Kosten- und Effizienzgründen. Andere Dinge sollten manuell geprüft werden.

Wir haben uns dafür vor der Pipeline für Codereviews von Teammitgliedern entschieden. Also zuerst in einen Dev-Branch, dort reviewed bevor es daraus in den Master geht, der dann an der Pipeline hängt.

Aber ich denke wir sind uns beide einig, dass sich auch bei solchen Prüfungen (egal ob rein automatisiert, rein manuell oder eine Mischung aus beiden) der Fehlerteufel immer noch einschleichen kann. Vielleicht etwas weniger je mehr Augen drüber schauen. Die Frage ist dann halt wie viele Augen man bezahlen möchte.

Btw....nettes Gespräch . Ich mag solchen Austausch.