Warnstufe Rot: Schwachstelle Log4Shell führt zu extrem kritischer Bedrohungslage

Zitat von tomduly

Die Log4Shell-Funktion ist Open Source. D.h. lizenzfrei nutzbar. Mehr oder weniger gewartet wurde dieses Java-Konstrukt von zwei ehrenamtlich tätigen ITlern als Hobby. Denen kann man auch keinen Vorwurf machen, das Problem sind die kommerziellen Softwareanbieter, die frei verfügbare Funktionen ohne ein umfassendes Sicherheitsaudit einfach übernehmen und in ihren Produkten einsetzen.

Das möchte ich mal meinen. Das ist kein Problem von Open/FLOSS Software, das ist ein Geizproblem bei den propietären Anbietern.

lizenzfrei nutzbar, ist nicht 100% korrekt. Jeder kann Log4J unter der Apache Lizenz und dessen Bedingungen Nutzen.

Des weiteren bin ich ein Befürworter von GPL(AGPL)/Copyleft Lizenzen. Das unterbindet dann so tendenzen irgendwas von irgendwo einzupflegen (BSD, Apache, WTFPL, Public Domain, Beerware, ... ) ohne es offenlegen zu müssen, und zwingt den verkäufer des Endprodukts auch zur GPL Lizenz und man kann zumindest nachschauen welche Bausteine/Libraries eingebunden wurden.

Zitat von tomduly

SmartMeter in den Verteilerschränken sämtlicher Haushalte drin und sie haben alle diese Log4Shell-Schwachstelle

hmm, ich hoffe mal, dass Java in Embedded Produkten doch noch nicht so weit verbreitet ist.

Zitat von KidCrazy

Was genau zu tun ist kann letzten Endes nur der Hersteller der Software (Log4j) sagen. Die haben die entsprechende Expertise. Alle anderen raten nur.

Das würd ich mal in Frage stellen.

Der Hersteller der Software log4j hat das Feature eingebaut, dass während des Loggens z.B. aktuelle Variableninhalte ausgelesen und mit ins Logfile geschrieben werden können. Das ist so variabel gestaltet, dass eben nicht nur ausgelesen, sondern auch geschrieben und ausgeführt werden kann. Das ist soweit sinnvoll und keine Sicherheitslücke. Wenn man das Feature komplett aus log4j entfernt, dann funktioniert log4j in vielen Anwendungsfällen nicht mehr.

Eine Sicherheitslücke entsteht erst, wenn ein anderer Softwarehersteller einfach nur beliebige Strings, die z.B. von einer Texteingabe stammen, in ein Logfile schreiben will, aber eine falsche Bibliothek einsetzt, die viel mehr tut als wegschreiben. Dass sie viel mehr tut als wegschreiben ist dokumentiert und bekannt. An dieser Stelle der Auswahl der ungeeigneten Bibliothek liegt der Fehler, und er entsteht durch fehlende Expertise. Von solchen Klitschen ist alles zu erwarten, aber keine Expertise.

Nick

Das Dumme ist nur, dass diese Klitschen, die den kritischen Javacode einsetzen Cisco, Dell, Ubiquiti usw. heißen und in ihren Segmenten (Netzwerktechnik, PCs, WiFi) Marktführer sind. D.h. wir haben weltweit zig Millionen Geräte im Feld, die diese Schwachstelle aufweisen. Und die Erfahrung zeigt, dass auch in ein paar Jahren noch sehr sehr viele dieser Geräte ungepatcht im Einsatz sein werden. Und dann wundert man sich wieder, wenn der Datenbestand einer Krankenhaus-IT oder eines produzierenden Unternehmens per Ransomware-Angriff komplett verschlüsselt und kopiert worden ist. Weil halt irgendwo ein 16port-Switch von Cisco im System vergessen worden ist, der von außen erreichbar ist.

Ich hab mal (aus Versehen!!! nicht absichtlich) wegen einer falsch konfigurierten Cisco-Infrastruktur das komplette Netzwerk eines Standortes lahm gelegt, und zwar über Stunden.

Cisco ist sehr unkomfortabel, es richtig einzusetzen erfordert schon fast ein Studium, *und* im Monatstakt werden dort Anfänger-Sicherheitslücken wie Wartungszugänge etc. bekannt. Und trotzdem ist es überall verbreitet.

Ganz allgemein könnte man sich vielleicht mal überlegen, was man als Prepper, als einzelner vorbereiten könnte, wenn man damit rechnen, dass, schätzen wir mal... , über Tage kritische Dienste ausfallen.

Alle persönlich wichtigen Daten auf einer eigenen Festplatte zu haben, ist da wohl das mindeste.

Nick