Log4J Sicherheitslücke in OpenHab

Vergesst Java nicht... Da hängt das auch mit drin...

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.

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 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.