Diskussion:Log4j

SocketAppender

Wo ist der Socket Appender?

-mikl (nicht signierter Beitrag von 194.138.18.132 (Diskussion) )

Sei mutig und ergänze selbst. Und unterschreibe deine Diskussionsbeiträge bitte immer mit vier Tilden, die werden dann zu IP/Benutzername und Zeitstempel expandiert. --jpp ?! 11:07, 7. Aug. 2007 (CEST)

Logger

Unter dem Abschnitt "Weitere Features" steht unter anderem der etwas allgemein gehaltene Bezeichnung "Die Namen der Logger ..." - was ist hierunter zu verstehen? Gibt es eine genauere Bezeichnung, die man/wir eventuell in diesen Artikel übernehmen können? Denn ich erkenne seine Bedeutung nicht in diesem Kontext. --Dolphinocean 22:29, 15. Jan. 2009 (CET)

Ich habe den Absatz gerade verbessert - wenn er nach wie vor unklar ist bitte ich um eine kurze Rückmeldung. --Cy23 (Diskussion) 22:40, 9. Mär. 2013 (CET)

Weiß ich leider auch nicht. Beethoven 1771 (Diskussion) 20:36, 15. Dez. 2021 (CET)

"Handler"?

Unter "Alternativen" steht aktuell im Artikel:

Java Logging – seit Java 1.4 Bestandteil der Java-Klassenbibliothek; ähnlich zu log4j, weniger Handler, kein PatternLayout

Was ist mit Handler gemeint? --Abdull (Diskussion) 15:04, 13. Sep. 2012 (CEST)

Ich habe "Handler" mit "Appender" ersetzt. Der Handler-Begriff wird eigentlich nicht benutzt, das was dem am nächsten kommt sind eben die Appender. Ich hoffe, damit ist es nun etwas klarer, da Appender im Text erklärt werden. --Cy23 (Diskussion) 22:21, 9. Mär. 2013 (CET)

Handler=Händler? Beethoven 1771 (Diskussion) 20:35, 15. Dez. 2021 (CET)

Zur heutigen Löschung ohne vorherige Diskussion

Die Webseite mit dem Einzelnachweis zu den Ursachen der Sicherheitslücke auf GitHub ist inzwischen leider nicht mehr erreichbar. Dort waren die Fehlerquellen wie im gelöschten Absatz angegeben beschrieben. Die in den weniger detaillierten Beschreibungen der Sicherheitslücke als Einfallstore erwähnten Java-Klassen "JndiLookup" und "Logger" sind genauso wie die im gelöschten Absatz erwähnte Java-Klasse "ContextMapLookup" im Java-Package "org.apache.logging.log4j.core".

Zur Typenverletzbarkeit in Java siehe übrigens auch: Nada Amin und Ross Tate: Java and Scala’s Type Systems are Unsound, 2016. --Bautsch 20:07, 19. Dez. 2021 (CET)

Weiterer Beleg: Shachar Menashe: Log4j Log4Shell 0-Day Vulnerability: All You Need To Know, 19. Dezember 2021. Also bitte nichts löschen, sondern bestenfalls den Inhalt verbessern... --Bautsch 20:13, 19. Dez. 2021 (CET)

Der betreffende Abschnitt wurde völlig zurecht gelöscht. Sein Inhalt beschrieb weder das Feature, das für die Sicherheitslücke verantwortlich war, noch die Mechanismen, über die Angriffe ausgeführt werden können. Die genannten Methodennamen waren falsch und unvollständig. Der längliche Hinweis auf die vielfache Überladung der Methoden und die Typisierung ihrer Parameter hat nichts mit der Sicherheitslücke zu tun. Ich bezweifle, dass der Autor das Problem verstanden hat. Trilemma2 (Diskussion) 22:13, 19. Dez. 2021 (CET)

Das Notationsmonster Java ist zwar sicherer als das Notationsmonster C, hat aber dennoch eine Reihe von sicherheitskritischen Eigenschaften. Da diese auch im Kontext der Sicherheitslücke von log4j relevant sind, erlaube ich mir, diese hier einmal aufzulisten:

• Alle komplexen Datentypen sind implizit mit der Basisklasse java.lang.Object verbunden. Dies schließt auch Instanzen der Klassen java.lang.String, java.lang.Runtime, java.lang.Process oder halt auch org.apache.logging.log4j.core.lookup.ContextMapLookup ein.
• Da Java-Programme somit nicht inhärent typsicher gestaltet werden können, dürfen alle Objektinstanzen zur Laufzeit explizit in andere Datentypen umgewandelt werden.
• Java erlaubt die mehrfache Vererbung von Schnittstellen und Implementierungen. Das schließt auch das Java-Interface java.io.Serializable ein.
• Abgesehen vom grundsätzlichen Problem der fragilen Basisklassen (FBC) bei der Vererbung von Implementierungen dürfen typengebundene Unterprogramme (in Java sogenannte Konstruktoren und Methoden) auch noch überladen werden, was die Nachvollziehbarkeit und Wartung deutlich erschwert.
• Objektinstanzen können nicht implizit schreibgeschützt als geklonter Wertparameter (call by value) an Unterprogramme übergeben werden.

All diese Features sind nicht nur ohne wesentliche Einschränkungen vermeidbar, sondern erschweren die Verifikation von mit Java erstellten Programmen, selbst wenn es sich um quelloffene Programme handelt. Unentdeckt erlauben und erleichtern sie gleichzeitig die Ausnutzung von Sicherheitslücken, und log4j wird hierbei nicht die letzte Java-Katastrophe gewesen sein.

Es wäre sehr wünschenswert und nützlich, wenn alle Informatiker, Juristen, Politiker und Führungskräfte verstehen würden, dass mit Java erstellte komplexe Programmpakete stets das Potential von hohen Sicherheitsrisiken haben, die mit zeitgemäßen Werkzeugen (Programmiersprachen) und Produktionsmitteln (Programmbibliotheken) leicht zu vermeiden wären. --Bautsch 08:15, 21. Dez. 2021 (CET)

Hmm - all das was du schreibst hat 1) auf dieser Diskussionsseite nichts verloren, ist 2) eine Aufzählung von Eigenschaften, die in keinster Weise sicherheitskritisch sind, 3) wäre eine (nicht weiter beschriebene) Erklärung, warum denn diese Eigenschaften sicherheitskritisch wären Privatmeinung und durch keinerlei diesbezügliche Forschung oder Literatur gedeckt, 4) sind diese Eigenschaften teils generelle Eigenschaften aller OO Sprachen, und 5) sind die genannten Eigenschaften sogar noch teilweise nicht der Wahrheit entsprechend wiedergegeben. --Sebastian.Dietrich  ✉  16:24, 21. Dez. 2021 (CET)

Ad 1-3) Siehe zum Beispiel: Deserialization of Untrusted Data, Log4Shell in a nutshell, Deserialization Vulnerabilities in Java, Serialization and deserialization in Java: explaining the Java deserialize vulnerability

Ad 4) Unsicherer Code, der wegen zu hoher und vermeidbarer Komplexität nicht vollumfänglich verifiziert wurde, kann für Cyberangriffe verwendet werden. Das betrifft im Übrigen auch die mehrfache Schnittstellen- und Implementierungsvererbung.

Ad 5) Wie kann ein Java-Programmierer Objektinstanzen als implizit schreibgeschützte Wertparameter an Unterprogramme übergeben (call by value, ohne den expliziten Aufruf der Methode clone (), sofern diese überhaupt implementiert ist), damit die originalen Instanzen vom Unterprogramm sicher nicht verändert werden können ?

--Bautsch 17:13, 21. Dez. 2021 (CET)

1-3 haben nichts mit Deserialisierung zu tun. Deserialisierung von (schadhaftem) Programmcode (java-deserialisierung dient der Deserialisierung von Objekten und somit Daten UND Code) ist immer ein Sicherheitsproblem - unabhängig von der Programmiersprache. Reine Daten kann man in Java wie in allen anderen Sprachen auch ohne diese Sicherheitsprobleme deserialisieren (z.B. aus XML oder whatever).

4 Vererbung und Methoden Überladen sind Grundkonzepte der OO und in allen objektorientierten Sprachen möglich. FBC ist bei Libraries nur dann ein potentielles Problem, wenn man 1) Subklassen von Libraryklassen schreibt (was nur bei Frameworks üblich ist, bei einer Library wie log4j macht das sowieso niemand) und 2) der Contract der Superklasse nicht klar ist (oder eine neue Version den Contract verletzt). Vererbung und Überladen dienen beide der Reduktion der Komplexität (des Codes) - führen also zu sichererem Code. Verifizierung erfolgt in der OO nicht primär durch Code-Lesen (das geht auf Grund des Polymorphismus nicht), sondern durch automatisierte Tests. "Vollumfänglicher Verifizierung" (= formale Verifikation) ist in keiner Programmiersprache aus Kostengründen möglich/sinnvoll. Aber wie gesagt - alles keine Java Themen, sondern Themen der OO und führen per se nicht zu unsichererem Code

5 Call by Reference ist der Performance geschuldet - OO Programmierer unterscheiden zwischen 1) Value-Types, Records und Value-Objects, die immutable sind (z.B. String) --> call by ref ist ok und 2) anderen --> call by ref wird vermieden, indem entweder keine Setter zur Verfügung gestellt werden oder ein immutable-wrapper verwendet wird oder ein copyConstructor oder (extrem selten) ein clone(). Es ist also ein leichtes den State gegen Änderung zu schützen. Auch das ist ein Thema für alle OO-Sprachen und auch sonst für die meisten anderen nicht-OO Sprachen.

Also alles keine Java Themen und so gut wie keines ist ein Sicherheitsthema. --Sebastian.Dietrich  ✉  19:08, 21. Dez. 2021 (CET)

Mir sind solche Diskussionsverläufe sehr gut bekannt, und das kommt mir immer so vor wie die Diskussion zwischen Niklaus Wirth und Linus Torvalds über die Goto-Anweisung. Es stimmt, dass eine vollständige Verifikation in keiner Programmiersprache möglich ist, unstrukturierte Programmiersprachen wie Java machen es den Programmierern und Verifizierern allerdings unnötig schwer, und das führt zu einem höheren Sicherheitsrisiko. Das Prinzip der Vererbung beruht auf dem Überschreiben von Methoden und funktioniert auch komplett ohne das Überladen von Methoden, wie durch mehrere wesentlich übersichtlichere und vollständig strukturierte, objektorientierte Programmiersprachen belegt ist, die kein Überladen zulassen. "Überladen ist das Goto der Vererbung" (leider nicht von mir). Diese Programmiersprachen sehen auch nicht vor, das Code ein Objekt sein darf – mag sein, dass viele Programmierer dies als unbequem empfinden, es ist aber sicher. Setter-Methoden müssen stets programmiert und verifiziert werden, was einen überflüssigen Zusatzaufwand bedeuten kann. --Bautsch 00:02, 23. Dez. 2021 (CET)

Ja genau - es ist eine Diskussion - aber anscheinend mehr über deine persönliche Vorlieben/Vorstellungen und weniger über Tatsachen - d.h. wir werden auf keinen grünen Zweig kommen. Wennst keine Setter schreiben möchtest, dann verwende doch lombok. Damit bekommst aber keine "sicheren" Setter - dafür brauchst dann schon OVal oder eben die 10min. Mehraufwand im Projekt für all die Setter.

Ich möchte nochmals festhalten, dass keiner der genannten Punkte ein Sicherheitsthema ist - wenn dem so wäre, gäbe es dafür Belege und wäre auch für die WP relevant. Die Punkte sind auch allesamt nicht Java spezifisch, verstehe also deinen Rant gegen das "Notationsmonster" (was auch immer du damit meinst) Java nicht. --Sebastian.Dietrich  ✉  10:21, 25. Dez. 2021 (CET)

Bloß weil Java nicht die einzige Programmiersprache mit Sicherheitsproblemen ist, heißt ja nicht, dass sie keine grundsätzlich vermeidbaren Sicherheitsprobleme hat und dass die log4j-Sicherheitslücke sowohl darauf als auch auf der Unstrukturiertheit der Programmiersprache beruht. Dies hat überhaupt nichts mit meinen Vorlieben zu tun, und Belege dafür sind in der Diskussion genügend gegeben worden. Ich weiß selber, mit welchen objektorientierten Programmiersprachen ich solche Probleme verhindern kann. Eine weitere Diskussion ist auch hier offenbar müßig, und ich werde mich hier daher nicht weiter dazu äußern. --Bautsch 00:31, 28. Dez. 2021 (CET)

Du wolltest explizit vor Java warnen nicht ich. Hättest auch C# oder Kotlin oder wasauchimmer schreiben können - hätte genausowenig gestimmt. Es stimmt auch nicht, dass die log4j Sicherheitslücke auf den genannten Punkten oder der (angeblichen) Unstrukturiertheit von Java beruht. Die objektorientierte Programmiersprache, die all die genannten Punkte nicht hat (und dennoch OO ist), kenne ich nicht - du hast sie bislang auch nicht genannt. Vermutlich existiert sie nicht oder ist rein akademisch interessant --> nicht in der Praxis erprobt --> nicht Stand der Technik. --Sebastian.Dietrich  ✉  19:08, 29. Dez. 2021 (CET)

Als Anregung empfehle ich das Studium der Veröffentlichungen von Niklaus Wirth und dessen Software-Produkten einschließlich der Weiterentwicklung Component Pascal. --Bautsch 09:00, 29. Jun. 2022 (CEST)

Neue Version 2.17.0

Es gibt ne neue Version. 2.17.0. https://lists.apache.org/thread/z7cyq4qn29d9d8v8xclyy55hml4522hb . Hab leider nicht gefunden, wie man die Info Box updatet. (nicht signierter Beitrag von Keinstein2 (Diskussion | Beiträge) 21:39, 19. Dez. 2021 (CET))

Die Versionsangaben werden auf WikiData gepflegt und wurden dort inzwischen aktualisiert. -- Discostu (Disk) 10:17, 20. Dez. 2021 (CET)