Log4j – warum Open-Source kaputt ist (Erklärung und Erkenntnisse des Log4Shell-Exploits) // deutsch

Im Dezember 2021 wurde die Sicherheitslücke Log4Shell (CVE 2021-44228) in dem Logging-Framework Log4j für Java bekannt, die vom BSI als kritisch eingeschätzt und als Warnstufe rot eingestuft wurde. Doch was verbirgt sich hinter dem Log4j-Exploit, wie funktioniert die Sicherheitslücke, wie lässt sie sich schließen, und vor allem – was lässt sich daraus lernen?

0:00:00 – Einführung
0:01:04 – Was ist Log4j?
0:02:10 – JNDI und LDAP
0:03:10 – Wie funktioniert Log4Shell?
0:04:30 – Die Sicherheitslücke schließen
0:05:45 – Über den Umgang mit dem Fehler
0:07:37 – JNDI und das Single-Responsibility-Principle (SRP)
0:09:08 – Java fördert Komplexität
0:10:16 – Separation of Concerns und 12FA
0:12:07 – Einfachheit als Ziel von Architektur
0:13:49 – Open-Source ist Nehmen und Geben
0:14:54 – Eine brotlose Kunst
0:16:08 – Der Fehler im System
0:17:17 – AGPL & Co. – die ehrlicheren Lizenzen
0:18:16 – Ein Geschäftsmodell für Open-Source
0:19:45 – Ausblick

────────────────────

Über the native web 🦄

Wir sind ein Beratungs-, Schulungs- und Entwicklungsunternehmen, das sich auf Web- und Cloud-Technologien spezialisiert hat. Wir streben nach intelligenten und eleganten Lösungen für komplexe Probleme, und wir glauben, dass Softwareentwicklung kein Selbstzweck ist. Stattdessen sollte Software tatsächliche Probleme der realen Welt lösen.

Wir glauben, dass native Web- und Cloud-Technologien das Fundament sind, auf dem die Zukunft aufbaut. Unsere Kernkompetenz ist der Entwurf und die Entwicklung verteilter Web- und Cloud-Anwendungen unter Verwendung dieser Technologien in interdisziplinären Teams. Wir entwickeln auch unser eigenes Open-Source-Framework namens wolkenkit. Und wir lieben es, unser Wissen in Schulungen und Workshops, auf Konferenzen und bei Usergroups zu teilen.

────────────────────

Weiterführende Links 🌍

[qui-gonkenobi]

Absolute Zustimmung. Bei größeren Firmen ist aber das Problem, dass du keine Möglichkeit hast zu spenden oder Quellcode beizusteuern, weil es schlechtweg keine Prozesse gibt bzw. Verboten ist und die es Entscheiden, wollen es schlichtweg nicht verstehen.
Die einzige Möglichkeit ist Privat was beizusteuern…
Daher die Lösung, alles in APGL veröffentlichen!

[coolchop]

Ich persönlich finde es sehr wichtig, sich selbst an Open Source Projekten zu beteiligen. Mit ist es wichtig etwas zurück zu geben. Auch wenn es nicht viel ist.

[wobuntu]

Hab den Channel gerade erst entdeckt und die ersten Videos gesehen, großartig!
Qualitativ enorm hochwertiger Content, da können viele der richtig großen Channels einpacken.
Großes Kompliment!

[fflecker]

Ich habe verstanden, dass ich dieses Paket gar nicht brauche, wenn ich alle Log-Nachrichten auf die Konsole ausgebe. Vor kurzem habe ich noch irgendwo gelesen, "das macht man nicht". Danke für Deinen Vortrag.

[snowtown]

Super Video, vielen Dank! Ich arbeite in einer Entwicklungs-Fachstelle einer Bank. Wir setzen sehr viel Open-Source ein. Das zurückgeben ist aber oft schwierig. Wenn ein Entwickler Code veröffentlichen möchte, muss Er einen relativ aufwändigen und komplizierten Prozess anstossen. Zuerst müssen die Legal & Compliance Themen geklärt werden was meist eine individuelle Beurteilung eines oder mehreren Juristen bedarf. Danach muss der Entwickler den Code nach den Vorgaben prüfen und ggf. anpassen und wir als Fachstelle müssen diesen dann gegenchecken sowie bestätigen. Dieser Aufwand kann von vielen Teams gar nicht getragen werden und so findet das zurückgeben selten statt. Wir arbeiten hart dafür, dass sich dies ändert aber haben naturgemäss einigen Gegenwind. Mit zurückgeben verdient man vordergründig kein Geld und so müssen wir genau diese Argumente, welche Du erwähnt hast, gegenüber dem Business immer wieder aufzeigen. Aber da sind wir nun nach einigen Jahren auf jeden Fall einen grossen Schritt vorwärts gekommen aber sind aus meiner Sicht immer noch weit hinter einer befriedigenden Situation diesbezüglich.

[troi]

Ich bin vor kurzem erst auf deinen Kanal gestoßen und bin wirklich sehr angetan. Im deutschsprachigen Raum habe ich bisher nichts vergleichbares gesehen. Danke dafür! Dein Wunsch zu weniger Komplexität und mehr hin zu "einfachen" Code teile ich leider nur bedingt. Prinzipiell wünscht sich das jeder Entwickler aber der Preis dafür ist in der Regel eine weitere Abstraktionsschicht. Das kann entweder eine Programmiersprache sein, ein Framework oder ähnliches. Aber dadurch verliert man auch viel an Kontrolle und wenn ein Problem auftritt, innerhalb dieser Schicht, dann ist man gezwungen sich in diese Komplexität einzuarbeiten. Also meines Erachtens verlagert sich das Problem nur bzw. Komplexität wird einem nur zum Teil abgenommen. Generell bin ich kein Freund mehr davon, für jedes kleine Problem direkt einen Framework, Library einzusetzen bzw. eine Dependency . Denn der Name ist wirklich Programm, eine weitere Abhängigkeit um die man sich kümmern muss.

[qhag]

Wirklich großartiges Video! Hab diesen Kanal soeben entdeckt und bin echt begeistert von der Qualität des hier gebotenen Inhaltes.

[xTheWinchesterx]

Sehr interessantes Video!
Kann sein, dass es das schon gibt. Aber ich fände es ganz cool in einem Video evtl. mal einen Überblick über das Thema "OpenSource" zu geben. Also was es bedeutet und einen generellen Überblick darüber zu geben. Bei den im Video genannten Lizenzen beispielsweise verstehe ich größtenteils nicht genau was es damit auf sich hat. Auch die Fragen, wie gehe ich damit um, wenn ich OpenSource Frameworks oder Software unter bestimmten Lizenzen verwende bzw. in meiner eigenen Software integriere. Ich kann mir gut vorstellen, dass es einige andere da Draußen gibt, die OpenSource Persee auch erst mal nur als "kostenlose" Software kennen.

[mbauerxff]

Danke für das Video,
Ich tu mir aber schwer damit die Komplexität von Log4J einfach mit dem Java-Umfeld abzutun.

Ich glaube nicht dass diese Art von Komplexität ein Java-Problem ist, es ist ein Entwickler-Problem.
Das Log4J Team hat selbst entschieden wie es sein Framework bauen will, keine Ausreden.

Ich gebe Ihnen Recht was die Schuldfrage angeht.
Fehler kann man nicht verhindern, aber man sollte daraus lernen.
Und genau da sehe ich das Log4J-Team in der Verantwortung.

[nothingisreal]

Die Aussage über den Einfluss der "Community" und von "Glaubensätzen" ist absolut richtig. Das hat mich an Java immer abgeschreckt. Das hat z.T. religiösen Charakter. Ds wird besonders schwierig, wenn man das auf Programmierer loslässt die aus komplett anderen Kulturkreisen kommen und auch wegen ihrer mangelhaften Ausbildung mit dem hohen Komplexitätsgrad überfordert sind und dann nicht mit der Sprache / Bibliothek programmieren sonder gegen sie. Allzu oft werden irgendwelche Dinge stumpf übernommen, weil man das halt so macht. Ich sehe das Problem mit der mangelnden Qualität und Sicherheit aber etwas anders. Das ist nicht auf Open Source beschränkt (da wird es aber transparent). Bei Closed Source sind die Mängel noch viel gravierender. Der Hauptgrund ist das a) blanke Gier herrscht und die wenigsten überhaupt bereit sind für Qualität und Sicherheit ausreichende Mittel aufzubringen b) auch eine schlechte unsichere Software allemal besser ist als es gar nicht oder von Hand zu machen und daher den SW EntwicklerInnen mehr oder minder alles aus der Hand gerissen wird. Features = GEIL, Warten = TEUER, QM = Pseudo Veranstaltung (konsistent Lügen ist billig). Und das prägt die Einstellung von vielen SW EntwicklerInnen. Wer schnell viele Features raushaut ist beim Auftraggeber beliebt. Und es macht allemal mehr Spaß komplizierte Konstrukte umzusetzen als sich mit schnödem QM zu beschäftigen. Zumal kreative Menschen auch ständig nach neuen Herausforderungen suchen. Interessant wäre ja mal die Idee das bestimmte Algorithmen und deren Umsetzung eigentlich Eigentum der Menschheit sein sollten, d.h. diese professionell und ordentliche bezahlt durch Institutionen definiert, entwickelt und publiziert werden, anstatt von Firm, Konsortien und Enthusiasten. Sowas gibt es z.T. schon (z.B. der AES Code) und es ist jedes Mal extrem erfolgreich.

[AlexanderRedmann]

Ich finde das Thema mit der LOG4J Lücke wurde, im Vergleich zu anderen Schwachstellen, Medial sehr stark aufgebauscht. Zumindest hat es das Thema Security stärker in den Fokus des Managements geschoben, sodass wir als DevOps es leichter haben, da Maßnahmen durchzudrücken. Wir haben mal die Dependencies von einem größeren Projekt durch unseren Dependency Track Server durchgejagt und siehe da, selbst ohne Log4j hat man immer noch eine Risk-Score von 9, 8 von 10. Vor Log4Shell wäre dies vielleicht mit einem Achselzucken abgetan, Hauptsache man bekommt seine Features durch den nächsten Sprint durch, aber nun hat man da eher einen Fuß in der Tür.
Solche Dependency Analysen sollten öfter durchgeführt werden, zumal eine Abhängigkeit mit der Zeit auch schlechter wird und auch nur während, wenn überhaupt, der Compile-Zeit überprüft wird aber nicht im laufenden Betrieb, denn aus dem Auge, ist aus dem Sinne

[jokerjoe]

Danke, gerade, dass die Lizenzen mal angesprochen wurden. Euer Channel sollte wirklich mehr Reichweite habe, aber das kann ja noch werden👍👍

[feuersh]

Gehe ich eigentlich irgendwelche Risiken ein, wenn ich eine andere Lizenz als MIT verwendet. Bin ich dann als Open Source Entwickler zu irgendwas verpflichtet? Bei der MIT bin ich davon ausgegangen das ich keinerlei Verpflichtungen habe. Sollte ich, aus welchen Gründen auch immer, kein Interesse mehr an dem Projekt haben, dann kann ich bei einer MIT Lizenz garantiert jederzeit aus dem Projekt aussteigen. Ist das bei anderen Lizenzen auch gegeben?

[glueckssilben]

Ich finde, dass es ganz selbstverständlich sein sollte, an Open Source etwas zurückzugeben. Möglichkeiten dafür gibt es genügend. Das fängt mit vernünftig geschriebenen Bugreports an. Unternehmen, die sich an Open-Source-Projekten beteiligen, können davon unglaublich profitieren. Das ist die beste Werbung, um fähige Entwickler anzulocken, und eine Möglichkeit internes Know-How durch den Austausch mit ganz unterschiedlichen Projekten aufzubauen.

[alvonzczentruy]

Bei uns im DAX-Konzern wird extrem viel Open Source genutzt, aber nichts dafür gemacht. Wir haben sogar als strategisches Ziel primär auf Open Source zu setzen.

Privat veröffentliche ich keine Software mehr als Open Source, früher schon. Wenn eine Firma meine IT-Leistung nutzen möchte, dann nur gegen entsprechende Bezahlung. Open Source ist so ein IT-Ding. Andere Branchen würden nie auf die Idee kommen ihre Arbeitsleistung kostenlos zu verschenken.

Bezüglich Komplexität gebe ich dir bei Java recht. Dazu kommen noch die ganzen Notationen zur Codegenerierung etc. Aber Bibliotheken gibt es in allen Sprachen und wirklich nach Schwachstellen überprüfen tut die keiner.

Ich bin mir bei Open Source nicht sicher, ob da nicht auch der ein oder andere Dienst gewisse Features einbringt, die er dann hinterher als Zeroday missbrauchen kann.

[DPabst-ewbu]

Ich komme aus einem Umfeld wo mehrere Hundert Systeme betreut werden. Jedes ist dabei anders und nicht wirklich transparent installiert und dokumentiert. Zudem gibt es kein Verständnis dass Systeme gepflegt werden müssen. Teilweise konnten uns die externen Produktentwickler keine Auskunft geben. Einige extern erreichbare Systeme mussten daher zunächst abgeschaltet werden. Gut bei allem ist die offene Kommunikation. Teilweise gibt es jetzt Anwender die verstehen dass ein gewisser Teamfokus auf Sicherheit und Pflege notwendig ist. Auch meine Forderung besser zu dokumentieren wird jetzt stärker akzeptiert. Dokumentieren ist schließlich besser als vermuten.

Danke für deine gute Erläuterungen zu den technischen Aspekten und zu Open Source. Werde mir selber ein paar Gedanken machen!

sehr interessant. meiner erfahrung: was man bei open source einsparrt gibt man für komerzielle software aus (zb: oracle database). es gäbe vielleicht die möglichkeit über npm und maven statistiken geld zu verteilen, aber das müsste erst eingezahlt werden.

[glueckssilben]

Separation of Concerns ist für mich die Grundlage im Umgang mit Komplexität. Gerade in großen Projekten sollte man darüber immer wieder reden. Die Frage ist, wen man da mitnehmen kann. Das betrifft jetzt nicht nur die eigene Anwendung.

Sind denn Frameworks, die nach einem Baukastenprinzip aus wohldefinierten Bestandteilen funktionieren, am Markt erfolgreicher? Oder werden möglichst integrierte Frameworks von Entwicklern als einfacher wahrgenommen?

Ich habe den Eindruck, dass das Wort "einfach" gefährlich ist, weil viele Menschen darunter sehr unterschiedliches verstehen. Retrospektiv wird Dir in dem Beispiel jeder zustimmen. Nur wir müssen das irgendwie vorher vermitteln.

Ich persönlich mag den Ausdruck "You only pay what you eat". Nur habe ich den Eindruck, dass ich damit nur bei denen auf Gegenliebe stoße, die das Problem schon verstanden haben.

[LLehnhard]

Es gibt viele Aspekte deiner Argumentation, denen ich voll zustimme. Es gibt schon ein großes Missverhältnis der Zahlungsbereitschaft bei Hard und Software, die ich immer wieder überraschend finde - aber leider auch zwischen kommerzieller Software und Opensource Software. Und ja jeder der was auch immer nutzt sollte sich überlegen, was das wen kostet und wie man solidarisch sein kann - gerade dann wenn Open Source Software im Enterprisesegment verwendet wird.
Ich halte es allerdings für einen Trugschluss bei 18:07 aus unsolidarischem Verhalten oder einer Nehmermentalität Fehler wie bei Log4j als immer wieder gegeben zu sehen. Das Quellcode jedem offen steht ist doch genau ein gegenteiliges Argument, dass ein solcher fehler viel früher hätte auffallen müssen. Vielleicht wären die Tests ja umfangreicher gewesen, wenn mehr Geld zurückfließen würde, aber hier wurde schlichtweg die Komplexität unterschätzt. Das hätte unter jeder beliebigen Lizenz und jedem Vergütungssystem genauso passieren können. Und passiert mit sicherheit auch immer wieder.
in der Schlussfolgerung Öizenzen zu fordern, die dann auch in einer Form mit vergütet wrden finde ich vollkommen richtig. Hier korreleiern aber Ursache und Wirkung nicht.

[tribikecargo]

Danke für das gute informative Video, ich finde ebenso das man für eine getane Arbeit auch entlohnt werden sollte. Nur als einzelner (bsp.: großes Unternehmen) gegen mehrere steht man ziemlich verloren da. Prinzip geben nehmen, leider hat sich in der Gesellschaft eine andere Mentalität entwickelt ( die den Glauben hat das kostenloses bzw. Freies nicht gewürdigt werden braucht)