News Log4Shell: Sicherheitslücke in log4j für Java hält die IT-Welt in Atem

[Cool Master]

Genau deswegen sollte man auf native Anwendungen setzen statt Java zu nutzen. Ich sage schon seit Jahren, dass man im Serverbereich von Java weg kommen muss. Das war früher mal wichtig mittlerweile gibt es bessere Anwendungen vor allem sicherer und schneller.

 

[ComputerJunge]

und ob die echt ungefiltert da einige Sachen einfach weiter geben

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.

 

[Nolag]

Es scheint sich bei dem Problem aber ausschliesslich um Server Software zu handeln.

Die Lücke kann auch in lokalen Java Anwendungen ausgenutzt werden, wenn diese auf Inhalte aus dem Internet zugreifen, die z.B. von anderen Nutzern erstellt wurden. Das wären z.B. Messenger, Downloadmanager etc.

 

[foo_1337]

Habe in diversen Beiträgen gelesen das Apple auch betroffen sein soll, ich habe mich nur gefragt wieso die irgend eine Art von Java Software betreiben sollten... .

Die iCloud war betroffen. Gab auch Screenshots vom PoC dazu.

Ergänzung (13. Dezember 2021)

Downloadmanager

Welchen du da wohl meinen könntest...
Das Ding nutzt aber immerhin kein log4j

Das war früher mal wichtig mittlerweile gibt es bessere Anwendungen vor allem sicherer und schneller.

Naja, ich bin selbst kein Java Freund, aber die Aussage würde ich so nicht stehen lassen. Hip ist ja aktuell node.js. Und da kann man eben auch viel scheisse fabrizieren, weil viele mit promises, async etc. nicht klar kommen, wie wild irgendwelches teils fragwürdiges npm Zeug nutzen und Schnipsel aus stackoverflow copy/pasten
Wenn die Tomcat App gut gemacht ist, steht sie was Sicherheit und Performance betrifft einer express.js App in nichts nach. Von PHP ganz zu schweigen

 

[ComputerJunge]

Welchen du da wohl meinen könntest...

Dieses grauenhafte Tool, welches ich immer händisch vor dem Login starte.

Edit - nach dem Download der aktuellen Version von eben

Geringes Risiko zwar, aber ich erwarte diese Woche ein Update.

 

[Launebub]

Open-Source ist Fluch und Segen zugleich.
Gratis aber doch nicht ohne Kosten verbunden.
Findet man eine Sicherheitslücke, trifft es gleich Millionen Unternehmen, weil keiner in Sicherheit investieren will.

 

[Conqi]

Wenn man hier nun wirklich "Strafen" einführen würde, wenn Entwickler ein Fehler in der Software einbauen oder eine Sicherheitslücke, dann würde über kurz oder lang sich jede Firma aus dieser Branche zurückziehen und es würde auch keiner mehr heute Entwickler werden, weil man quasi jeder Zeit mit massiven Schadensersatzforderungen - gerade in den USA - als auch Strafen zurechnen hätte und keine Firma geht so ein Risiko ein.

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.

Abgesehen davon muss das auch nicht bedeuten, dass man für jeden Bug in den Ruin getrieben wird. Aber verbindliche Reaktionszeiten wären schon mal ein Anfang. Währenddessen braucht Microsoft drei Versuche, um eine Lücke in der Druckerwarteschlange zu fixen, weil jeder Patch in wenigen Stunden von der Community zerlegt wird. Auch kein wirklich gangbarer Weg für die Zukunft.

Ebenso würde OpenSource vollständig aussterben, denn keiner wirklich keiner würde noch etwas in dem Bereich machen, weil man ohne finanzielle Absicherung sich über kurz oder lang das Leben versaut.

Es ging mir nie um OpenSource. Wer seine Software kostenlos anbietet, der soll da von mir aus den größten Rotz produzieren. Worum es mir ging ist, dass kommerzielle Anbieter, die teilweise tausende Euro im Monat für Lizenzen nehmen, dafür praktisch keinerlei Qualität ihrer Software garantieren (können). Dazu gehört auch, dass sie sich um die Sicherheit der eingesetzten Open Source Komponenten zu kümmern haben.

 

[Nolag]

Genau deswegen sollte man auf native Anwendungen setzen statt Java zu nutzen. Ich sage schon seit Jahren, dass man im Serverbereich von Java weg kommen muss.

Nicht Java ist das Problem, sondern die dynamische Codeausführung moderner Sprachen. Die gleichen Probleme gibt es auch mit Javascript, C# oder Python, um nur einige zu nennen.

Das war früher mal wichtig mittlerweile gibt es bessere Anwendungen vor allem sicherer und schneller.

Ich sehe allerdings einen eindeutigen Trend zu noch mehr Dynamisierung.

 

[ModellbahnerTT]

Bei log4j war es immerhin nur fahrlässige Programmierung.

Da dies extrem viele Nutzer trifft sollte man die Software nicht mit derart fahrlässigen Dinge veröffentlichen.

Ich sage schon seit Jahren, dass man im Serverbereich von Java weg kommen muss.

Nicht nur im Serverbereich und von Seiten der Clients sollte man von Java dringend wegkommen.

 

[Tanzmusikus]

Das finde ich etwas übertrieben. Lokale Anwendungen können natürlich auch zum Problem werden, wenn sie Inhalte, die von anderen Nutzern erstellt werden, herunterladen. Bei MediathekView müsste schon jemand eine der Online Datenbanken manipulieren, damit das zum Problem wird.

Ich muss mich korrigieren: Der log4j-vuln-scanner hatte den Fund auf meiner Win7-Partition angezeigt.
Dort ist eine nicht-aktuelle Version mit zwei Dateien von 2018 enthalten: "log4j-api-2.8.1.jar" und "log4j-core-2.8.1.jar".

Diese beiden Dateien habe ich auf meiner Win10-Partition gar nicht, vermutlich weil die entsprechende Option hier nicht aktiviert ist. Also alles halb so wild.

Und solange die Kommunikation per HTTPS läuft, sollte das auch bei der Win7-Version nicht gefährlich sein.

Grüße

 

[Nolag]

Nicht nur im Serverbereich und von Seiten der Clients sollte man von Java dringend wegkommen.

Die beliebtesten Sprachen sind aktuell Javascript und Python. Dann doch lieber Java. Wenn mehr Server mit Node.js laufen und solche Lücken aufweisen, dann wird das zum Hassobjekt. Ich verstehe solche Aussagen gegen Java nicht wirklich.

 

[Tanzmusikus]

Nicht nur im Serverbereich und von Seiten der Clients sollte man von Java dringend wegkommen.

Und als Smartphone-User sollte man dann "von Android wegkommen".

 

[ComputerJunge]

Open-Source ist Fluch und Segen zugleich.

In diesem Falle eher Standards - der Impact resultiert aus der Tatsache der umfassenden Verbreitung in der Welt der "Online-Services".

 

[Launebub]

Und als Smartphone-User sollte man dann "von Android wegkommen".

und was ist mit Apfel ?

 

[Tanzmusikus]

Kommen "Apfels Äppfel" denn aus Java so wie bei Android?

 

[Web-Schecki]

Wobei ich mir hier bei der Sicherheitslücke schon wieder die Hände über den Kopf zusammen schlage und mir denke: Habt ihr Trottel eigentlich die einfachste Grundlage der Sicherheit vergessen? SOBALD ETWAS VON AUSSEN KOMMT HAT MAN DEM ZEUG NICHT ZU VERTRAUEN!

Und da frag ich mich, was die Entwickler der Software gemacht haben und ob die echt ungefiltert da einige Sachen einfach weiter geben.

Bei so einer Funktion würde ich persönlich die Parameter nur selbst zusammen gebaut übergeben und NIEMALS von außen und das scheinbar auch noch ungefiltert.

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.

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. 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. Gleichzeitig gibt es genau zwei unbezahlte Entwickler, die eine so weit verbreitete und eben nicht ganz triviale Bibliothek, die scheinbar in fast allen kommerziellen Java-Projekten verwendet wird, in ihrer Freizeit maintainen. Erinnert ein bisschen an OpenSSL. Und die Nutzer setzen die Bibliothek ein, ohne die Komplexität dahinter auch nur zu erahnen. In diesem Fall ist das natürlich fatal.

 

[ComputerJunge]

Ich verstehe solche Aussagen gegen Java nicht wirklich.

Die entspringen ja auch dem Internet, ähm der puren Ahnungslosigkeit.

 

[foo_1337]

Eine logging-Bibliothek ist komplexer als (meist) nötig,

Sind doch nur ca 177k LoC Grob soviel wie der nginx

 

[Nolag]

Nun, da die wenigsten Entwickler wirklich "Sicherheitsexperten" sind und man ohnehin heute unter ständigem Zeitdruck steht - dank immer kürzere Produktzyklen, BWL-Absolventen, die Nullplan haben, aber mit Buzzwords wie KI , Machine Learning usw. um sich werfen und geizigen Kunden - und man sich bei solchen Sachen wie Penetrationstests der Software auch Gedanken machen muss um mögliche Angriffsvektoren, fehlt gelinde gesagt oft einfach die Zeit aber auch die "Kreativität" und das Wissen.

Wenn man bedenkt, wie viele Leute da draußen Software unter solchen Bedingungen entwickeln, dann passiert eigentlich relativ wenig. 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.

 

[neuhier08]

war heute recht lustig - nicht.