BSI warnt vor Kritischer Schwachstelle in weit verbreitetem Software-Produkt Log4j

:cool:
 
magfoo schrieb:
Sorry, aber das sind doch Klischees
Für so einen Quatsch haben die meisten angestellten Entwickler überhaupt keine Zeit oder müssen unsinnige Vorgaben erfüllen.
Eher läuft es so:
Barry: Ich will XYZ
SVP: Aber das macht es unsicher
Barry: Ich will aber
SVP: Ich bin dagegene, weil...
Barry(unterbricht SVP): morgen ist Release, mach das so wie ich sage sonst macht's jemand anderes.

Oder eben:
Barry: morgen ist das fertig!
SVP: wir müssen noch drölfzig Bugs fixen
Barry: egal, morgen ist Termin, da ist das fertig: Compiliert es?
SVP: Ja, aber es gibt trotzdem noch Bugs.
Barry: Ist egal, patchen wir später. Der Kunde hat einen Servicevertrag.
Zum Vergrößern anklicken....
Ich bin auch so ein SVP und du gibst zu gut 50% meinen Arbeitsalltag wieder... :sneaky:
(y)
 
  • Gefällt mir
Reaktionen: dg2rbf
Für die Programmierer:

Version 2.16 ist raus. Da ist die kritische Funktion im Default wohl noch weiter abgeschaltet. Die Version ist gegenüber der 2.15 vorzuziehen.

Für die, die klönen wollen:
Cherusker schrieb:
Nein, mit patchen ist die Lücke nicht unbedingt geschlossen. Der Patch ändert nur die Vorsteinstellungen. Wer die alte Konfiguration einspielt, reißt die Lücke wieder auf. Soetwas dürfte häufig passieren, weil die wenigsten Log4j ausreichend kennen dürften.
Zum Vergrößern anklicken....
Der Patch (die neue Version von Log4j) ändert die Voreinstellungen in der Bibliothek, nicht die der Konfigurationsdatei. Wenn in der Konfiguration zu der fragwürdigen Funktion überhaupt kein Eintrag vorliegt, dann kommen die Voreinstellungen der Bibliothek zum tragen.

Und da die allermeisten Leute überhaput keine Einstellungen zu der anfälligen Funktion haben, da sie die weder brauchen noch von ihr wissen, kommen dann die geänderten Voreinstellungen der Bibliothek zum tragen, und damit löst der Patch in den meisten Fällen das Problem, auch nach dem zurückspielen der alten Konfiguration. Und falls der Schalter zum Einschalten der Funktion neu sein sollte, dann wirkt der Schutz sogar zu 100% - zumindest so lange, bis jemand die Funktion absichtlich einschaltet.
Dextera schrieb:
Es funktioniert wie spezifiziert :teeth:
Zum Vergrößern anklicken....
Der Artikel ist weder fair noch hilfreich, sondern nur sarkastisch.

Korrekt ist aber dass Einfachheit manches Mal Vorteile hat. Weniger ist oft mehr.
 
  • Gefällt mir
Reaktionen: dg2rbf, Barry Lyndon und stepi0
Johanna K schrieb:
Der Artikel ist weder fair noch hilfreich, sondern nur sarkastisch.
Zum Vergrößern anklicken....
:noplan:

That's my type :wavey:Der Smiley dahinter war auch nicht zum Spaß da. Naja - obwohl ... eigentlich doch :hehehe:
Wüsste aber auch nicht, wem man da jetzt großartig helfen sollte - mit Artikeln ...
 
Ich wollte, ich könnte soviel Java, dass ich den Artikel beurteilen kann. Das Lesen hat aber Spaß gemacht
 
Johanna K schrieb:
Der Artikel ist weder fair noch hilfreich, sondern nur sarkastisch.

Korrekt ist aber dass Einfachheit manches Mal Vorteile hat. Weniger ist oft mehr.
Zum Vergrößern anklicken....
@Dextera liegt mit seiner Aussage richtig. Der ursprüngliche Gedanke (in den ersten Java-Versionen) war es, Code von einem Server zu laden und zu nutzen. Write once use everywhere. Ist das gleiche wie npm.

Leider ist vielen Software-Entwicklern (nicht nur in Java) die Tragweite ihres Codings nicht bewusst - manchmal schlicht aus Unwissenheit.

Im aktuellen Fall handelt es sich nicht um einen Bug in log4j. Es wurde ein Java-Feature implementiert. Das dies nicht unproblematisch ist, hat man in Java bereits erkennt und das Feature - mwn - in den letzten Versionen bereits ausgebaut. Ein Software-Entwickler, der die log4j-core-lib verwendet, muss Wissen, dass der Befehl Klassen nachladen kann und entsprechende Vorkehrungen treffen, dass dies nicht geschieht. (z.B.: User-Eingaben escapen ...). Also, don#t blame die log4j-Developer. Blame die Entwickler, die das gedankenlos verwendet haben.
 
  • Gefällt mir
Reaktionen: herberthuber
magfoo schrieb:
Sorry, aber das sind doch Klischees
Für so einen Quatsch haben die meisten angestellten Entwickler überhaupt keine Zeit oder müssen unsinnige Vorgaben erfüllen.
Eher läuft es so:
Barry: Ich will XYZ
SVP: Aber das macht es unsicher
Barry: Ich will aber
SVP: Ich bin dagegene, weil...
Barry(unterbricht SVP): morgen ist Release, mach das so wie ich sage sonst macht's jemand anderes.

Oder eben:
Barry: morgen ist das fertig!
SVP: wir müssen noch drölfzig Bugs fixen
Barry: egal, morgen ist Termin, da ist das fertig: Compiliert es?
SVP: Ja, aber es gibt trotzdem noch Bugs.
Barry: Ist egal, patchen wir später. Der Kunde hat einen Servicevertrag.
Zum Vergrößern anklicken....
Ja, diese platten Klischees sterben einfach nicht aus.
Exakt so habe ich es auch erlebt und meine Konsequenzen gezogen.

Beispiel 1: An einer SW-Architektur in Together (Visual Modelling Tool) "gezeichnet". Chef kommt rein: "Malen sie immer noch Bildchen? Wann fangen sie endlich an zu programmieren?" ;-/
Beispiel 2: Der Vertrieb hat dem Kunden die extra Funktion für xxxx Euro versprochen. Chef: Sie haben somit nn Stunden für die Realisierung.
PS: Ich arbeite dort heute nicht mehr. ;)

In letzter Konsequenz führt so etwas dann z.B. zum Dieselgate.

Als SW/HW-Entwickler hat man meines Erachtens auch eine ethische Verantwortung für seine Arbeit. Und je nach Auswirkungen auf Mitmenschen, Gesellschaften und/oder die (Um)Welt manchmal keine Geringe.
 
  • Gefällt mir
Reaktionen: dg2rbf
Für Programmierer und vor allem für Administratoren:

Zwei der drei vom log4j-Team ursprünglich vorgeschlagenen Workarounds sind mittlerweile wegen ungenügender Sicherheit bzw. weiterhin vorhandener Schlupflöcher verworfen worden.
Mehr Info gibt es auf der log4j-Seite.

Neben der korrigierten Version 2.16.0 gibt es jetzt mit 2.12.2 auch eine Korrektur auf Basis einer älteren Version. Die 2.12.2 ist für Systeme, auf denen noch Java 7 verwendet wird.

Für alle:
Lt. Heise beginnen jetzt die Angriffswellen auf verwundbare Systeme.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben Unten