ComputerJunge schrieb:
Das wohl eher nicht (kaum) mehr. Aber für den ein oder anderen selbstgeklöppelten Input-Validator sind diese Patterns wohl auch einfach noch neu.
Na ja, scheint ja leider in dem Fall so zu sein, dass ein Input-Validator, der einen Angriff versucht zu erkennen, hier gnadenlos versagen wird, weil es zu viele Möglichkeiten gibt, um den Angriff zu verschleiern.
Hier kommen so einige Fehler zusammen, angefangen in log4J, dass man dort eine so mächtige Funktion überhaupt eingebaut hat, weitergehend bei log4J, dass potenzielle Gefahren - die da eigentlich bekannt hätten sein müssen - nicht wirklich erwähnt hat und Endet in dem Fall dann bei den Entwicklern, die log4J mit entsprechender Funktion nutzen und scheinbar wirklich auf Anfängerniveau Strings ohne Prüfung an so eine Funktion übergeben.
In fast jedem Buch zu fast jeder Programmiersprache, in der es Funktionen gibt, die solche Möglichkeiten bieten - hier ja Verbindung von "Laden + Serialize/Deserialize" - wird vom Autor auf die Gefahr solcher Funktion hingewiesen und dass man sowas wirklich nur aus einer seriösen Quelle machen sollte.
Ehrlich gesagt, erinnert mich das an die bösen Skript-XSS-Lücken Anfang des Jahrtausends, als man in PHP, Perl und Code oft unnötigerweise
eval nutze und da ähnliche Probleme schuf.
Conqi schrieb:
Das ist halt keine wirklich gute Rechtfertigung aus meiner Sicht. Wenn eine ganze Branche nicht mehr finanzierbar wäre, wenn sie für ihre Fehler haftbar wären, dann ist doch an der Branche grundlegend was falsch.
Es ist aus deiner Sicht keine gute Rechtfertigung? Ich habe hier keine Rechtfertigung gegeben, sondern dir die möglichen Konsequenzen aus deiner Forderung aufgezeigt und in dem Fall auch absichtlich die negativsten Konsequenzen.
Es hat schon einen Grund, warum man heute in der Regel - auch als Mitarbeiter und ebenso als Firma - für Schäden erst dann wirklich haftet, wenn man diese fahrlässig, grob fahrlässig bis hin zu mutwillig in Kauf nimmt und man ansonsten in der Regel eher nichts zu befürchten hat.
Fehler sind menschlich und können jedem passieren. Du forderst in deinem Beitrag die Haftung für Fehler - ohne die nun erfolgte Differenzierung - und damit forderst du die Haftung für etwas, was jedem von uns jeder Zeit passieren kann.
Conqi schrieb:
Abgesehen davon muss das auch nicht bedeuten, dass man für jeden Bug in den Ruin getrieben wird.
Aus meiner Sicht muss ich dir an der Stelle leider eine gewisse Kurzsichtigkeit unterstellen. Ich würde dir mal an der Stelle empfehlen dich mal mit dem US oder allgemein angelsächsischem Rechtssystem zu befassen und was da teilweise für übertriebene Schadensersatzforderungen durchgehen und bei der Klagefreudigkeit im amerikanischen Raum ist man als Entwickler ruckzuck im Ruin, egal ob Firma oder nicht.
Conqi schrieb:
Aber verbindliche Reaktionszeiten wären schon mal ein Anfang.
Und was betrachtest du als Reaktion? Eine Zeit, in der ein Fehler behoben sein soll? Die Meldung der Entwickler, dass sie die Lücke registriert haben? Hier haben die Entwickler - log4j - sogar recht schnell reagiert und die Lücke geschlossen in den gepflegten Zweigen.
Conqi schrieb:
Es ging mir nie um OpenSource.
Es ging dir nie um OpenSource? Du hast schon mitbekommen, dass es hier um eine Lücke in einer OpenSource-Bibliothek geht?
Ich muss ehrlich schreiben: Sammel erst mal deine Gedanken, befasse sich mit der Materie, dann werde mal etwas kreativ und denke weiter als bis zu deinem aktuellen Horizont und validiere deine Gedanken.
Es gibt in der Softwareentwicklung einige Probleme, einige viele Probleme, nur die Forderung nach Haftung werden diese Probleme nicht lösen, sondern bergen ganz andere gefahren.
Was es braucht - und da stimme ich dir zum Teil bei den Reaktionszeiten zu - ist ein deutlich besseres Fehlermanagement in Firmen, aber auch Open-Source-Projekten. Ebenso braucht es auch heute eine deutlich bessere Qualitätssicherung und ebenso auch wieder den Wunsch nicht möglichst schnell ein Produkt auf den Markt zu werfen, sondern ein möglichst perfektes Produkt. Nur die Probleme, die dazu führen, dass Qualitätssicherungen immer weniger Personal haben, sind eher in der Ecke BWL zu suchen als in der Entwicklungsabteilung.
Web-Schecki schrieb:
Das Problem ist vermutlich, dass erstmal niemand ein Problem darin sieht, irgendwelche Java-Strings an log4j zu übergeben, weil die schlicht geloggt werden sollen und das jetzt erstmal nicht problematisch sein sollte. Auch wenn der String von außen kommt. Man checkt vielleicht vorher die Länge, damit man nicht durch bösartige Nutzereingaben die Platte vollschreibt, aber das war es wahrscheinlich auch. Halte ich zumindest nicht für abwegig.
Ehrlich: Das ist absolut nicht abwegig und wird vermutlich auch so gemacht, nur ist das ja schon ein Teil des Problems, dass hier nun knallt.
Viele Entwickler - egal ob OpenSource oder in Firmen - sind oft viel zu blauäugig, was Nutzereingaben angehen. Problematisch wäre das im Fall der Logs - hier - dann eigentlich auch nicht, wenn die Eingaben einfach in eine Datei geschrieben werden würden oder woanders.
Damit zu dem Punkt:
Web-Schecki schrieb:
Auf der anderen Seite macht log4j etwas eher dämliches, wenn es die Strings interpretiert. Und vielen Nutzern ist wohl schlicht nicht klar gewesen, dass das überhaupt passiert.
Richtig, das ist etwas saudämliches, diese Funktion wurde aber eingebaut, weil man ja wohl die Strings "schöner" machen wollte. Wenn ich mir jetzt die API-Dokumentation ansehe, wird da aber auch entsprechend die Möglichkeit beschrieben und zeigt dann ein weiteres Problem: Viele Entwickler nehmen sich heute einfach keine Zeit mehr mal eine Dokumentation zu lesen und bauen einfach den Code ein.
Hier kommen quasi 3 Fehler zusammen: Mächtiger Logger, der Strings interpretiert, Entwickler, die die Dokumentation nicht lesen und Entwickler, die Nutzereingaben ohne Prüfung an einen mächtigen Logger geben. Eine ganz gefährliche Mischung!
Web-Schecki schrieb:
Die Entwickler wurden dafür auch hart angegangen, aber dort liegt meines Erachtens das eigentliche Problem: Eine logging-Bibliothek ist komplexer als (meist) nötig, kann die Komplexität nicht einfach reduzieren, ohne Kompatibilitätsprobleme hervorzurufen (laut Entwickler wäre die Interpretation der Eingaben sonst schon längst entfernt worden), die dadurch zustande kommen, dass die Bibliothek so weit verbreitet ist.
Das ist allgemein heute ein Problem auf vielen Ebenen, dass man heute immer komplexer wird, weil man irgendwie jeden Spezialfall abdecken will.
Aber, das ist eine andere Diskussion.
Nolag schrieb:
Wenn man bedenkt, wie viele Leute da draußen Software unter solchen Bedingungen entwickeln, dann passiert eigentlich relativ wenig.
Ach, wie gesagt, die Fehler pro 1000 Zeilen Code hat in den letzten Jahren nicht zugenommen, sondern nimmt eher ab durch immer bessere Werkzeuge.
Das Problem heute ist eher, dass Softwareentwicklung heute sehr einfach geworden ist und die Hürden quasi nicht mehr vorhanden sind und Entwickler grundlegend "Faul" sind, gleichzeitig aber der Termindruck immer größer wird.
Ich habe mich für meine neue Stelle ganz bewusst entschieden, weil ich diesen Druck in der Form nicht mehr ausgehalten habe, wobei mir das Entwickeln sehr viel Spaß macht. Dumme war nur, dass ständig irgendwelche BWL-Futzis meinten es besser zu wissen, ständig irgendwelche Berater - in der Regel auch BWL-Futzis - angeworben haben, die mit Buzzwords hantierten, wir Entwickler immer mehr zu Befehlsempfängern wurden und wenn die Kacke am Dampfen war auch die Schuld auf uns geschoben wurde, obwohl wir von Anfang an gesagt haben, dass gewisse Dinge nicht gehen oder das so nicht passt.
Und das zieht sich quasi durch die ganze Branche, selbst bei den "Techriesen", dass da teilweise heute auch Teamleiter sind, die ständig mit Buzzwords umsich werfen, wobei die Teamleiter da oft schneller gehen, als man denkt, wenn sie "inkompetent" sind, da kommt dann aber der zeitliche Druck.
Nolag schrieb:
. Schwerwiegende Fehler werden auch in sehr gut untersuchten Bibliotheken immer wieder übersehen. Ein aktuelles Beispiel ist
NSS (CVE-2021-43527). Das ist wahrscheinlich eine der am besten untersuchten Bibliotheken und sie enthielt trotzdem eine RCE Lücke.
Das wird auch immer wieder zukommen, der Code bleibt ja nicht stehen. Und Codevalidierung und Prüfung ist so unendlich komplex.
Zumal man auch bedenken muss, dass es Sicherheitslücken gibt, die "by Design" sind, andere sind durch Unachtsamkeit der Entwickler bei der Entwicklung. Komplexes Thema, zu Komplex um da wirklich auch alle möglichen Fallstricke anzusehen und dann halt wie immer: Zeit.
meymo schrieb:
Weist du was mich als professionellen Java Entwickler am meisten an dieser ganzen Geschichte stört?
Ich bin ehrlich: Bis heute hab ich die meisten Logger für meine Projekte aber auch in den Firmen selbst geschrieben und kam niemals auf den Gedanken dafür eine Bibliothek zu verwenden.
Du hast recht: Log4J ist echt ein fettes Monstrum. Ich glaub, das da hier teilweise auch bei manchen Projekten der Wunsch nach einem möglichst genauem Logfile vorhanden ist.
borizb schrieb:
Die IT Chefin hats weil es unklar war vom Netz genommen, die schaut das die Tage tiefer an.
Ist ja in so einem Fall auch das einzig richtige.
Crowbar schrieb:
Die Chronologie der Ereignisse lässt lediglich zwei Schlussfolgerungen zu: Entweder haben die Entwickler das gravierende Gefährdungsrisiko für Anwender selbst nicht erkannt oder sie haben die Nutzer ihrer Bibliothek bzw. deren Anwender jahrelang sehenden Auges in den Untergang reiten sehen und dies schlicht ignoriert.
Und die dritte Schlussfolgerung: Die Entwickler haben das Problem nicht erkannt und die Entwickler, die diese Bibliothek einsetzten genauso wenig.
In so einem Fall: Geh in so einem Fall immer von kollektiver Doofheit aus.
foo_1337 schrieb:
Hm ja, weil ja C, nodejs usw. nie Probleme hatten und haben. Kannst du dein substanzloses Java Bashing einfach mal sein lassen?
Ach, lass ihn doch.
Wenn er nicht versteht, dass diese Lücke nichts mit der gewählten Programmiersprache zutun hat, sondern beim Design der Bibliothek, wirst du ihn da auch nicht mit erreichen.
In C, C++, C#, D, JavaScript, TypeScript usw. kann man auch solche Sicherheitslücken aufmachen, wenn man will und entsprechende Funktionalitäten schafft. Bestesbeispiel bei C, C++ und Co wäre zum Beispiel LUA-Skript, wenn man das nicht wirklich sauber konfiguriert: Sicherheitslücke. In Skriptsprachen - JavaScript (auf dem Node.JS aufbaut, will bisschen klugscheißen) PHP, Perl und Co wäre es eval, mit der man so nen Schabernack treiben kann.
foo_1337 schrieb:
a, mir ist bekannt, dass Java unter DAUs (sorry dafür) einen schlechten Ruf wegen diversen Applet Geschichten aus den 90ern hatte. Aber das hier hat damit nichts, aber rein gar nichts zu tun.
Richtig und Java ist weit besser als sein Ruf! Ich mag Java!
calluna schrieb:
Das hat doch nichts mit Java zu tun... so ein Einfallstor wie dieses hier, kann in (fast) jeder Sprache geschrieben werden... egal ob mit JavaScript und Node.js, C#, Python, Scala, Clojure, Rust, Elixir, Erlag, Scheme, Pharo, Ruby, Perl, C++ und C, Go, Swift... und etlichen anderen Sprachen, die ich nicht kenne.
Warum zählst du eigentlich Node.JS in den ganzen Programmiersprachen auf? Node.JS IST KEINE PROGRAMMIERSPRACHE!
Node.JS basiert auf JavaScript, deswegen ja auch das JS am Ende! So viel Ordnung muss sein!
Aber zurück zum Thema: Solche Lücken kann man in fast jeder Sprachen schaffen, man muss aber in dem Fall dazu schreiben, dass das in manchen Sprachen unterschiedlich schwer ist. Am einfachsten ist so eine Lücke in Skriptsprachen, da die oft "eval" haben.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/eval
https://www.php.net/manual/de/function.eval.php
https://www.programiz.com/python-programming/methods/built-in/eval
In Sprachen wie C# oder Java ist das dann etwas komplizierter, aber noch einfach genug, dass man es unbewusst durchaus schafft.
In C, C++, Rust muss man dann sagen: Dort muss man schon fast aktiv so eine Lücke wie hier einbauen.
BeBur schrieb:
log4j ist ja aber gerade eine FOSS Alternative für Logging.
Ach, in der Regel schreibt man sich seine Logger selbst, weil das eher das kleine Einmal-Eins ist.
log4j ist so "beliebt" weil es halt scheiß mächtig ist.
highco schrieb:
Die Geschichte zeigt eher die Stärke von Java und Open Source. In einer kleinen, weniger genutzten Library wäre so ein Bug/Exploit möglicherweise nie publik geworden.
Richtig und bei einer Firmenbibliothek wohl vermutlich nie.
