Die XZ/OpenSSH Backdoor

Christoph Iserlohn Hallo und herzlich willkommen zu einer neuen Folge des INNOQ Security Podcast. Heute ist der 12. April 2024. Sonst sagen wir das Datum meistens eher nicht. Diesmal ist es aber besser, wenn wir das sagen. Wir haben zwei Wochen nach Karfreitag und vielleicht habt ihr das mitbekommen, als Hörer des Security Podcast seid ihr ja auch an Security interessiert. Ihr habt das bestimmt mitbekommen, dass am Karfreitag herausgekommen ist, dass eine Backdoor in die XZ Library eingeschleust wurde. Und es hat sogar Schlagzeilen bis in die Bildzeitung gemacht „Ein Deutscher rettet das Internet“. Und das ist ein bestimmt ganz interessantes Thema, das wir heute besprechen. Und dazu habe ich mir den Stefan eingeladen. Hallo Stefan.

Stefan Bodewig. Hallo Christoph.

Christoph Iserlohn Denn der Stefan kann da bestimmt viele gute Dinge zu sagen, weil er in gewisser Weise das mitbekommen hat. Zwar eher so in einer Form, dass er es gar nicht bemerkt hat, aber er war dabei. Stefan, magst du mal erzählen, warum du dabei warst?

Stefan Bodewig Na ja, dabei ist, glaube ich, ein bisschen viel gesagt. Aber zumindest haben mir die Namen des ein oder anderen möglicherweise beteiligten Menschen was gesagt. Ich bin auf der Mailing-Liste von XZutils, also dem Projekt, in dem diese Sicherheitslücke aufgetaucht ist. Ich bin für eine ganze Reihe von Jahren lang Maintainer von Apache Commons Compressed gewesen, eine Kompressionsbibliothek in Java und die nutzt die Java-Implementierung dieses XZ-Projektes um XZ-Kompressionen durchzuführen und deshalb kannte ich den Maintainer Lasse Collin schon so ein bisschen vorher, wie man sich so kennt, wenn man Open-Source-Entwickler ist und ein paar Mails ausgetauscht hat. Und habe durchaus gesehen, ah, hier passiert jetzt mal wieder was auf der Liste und es gibt jemand neuen und der wird dann nach ein paar Jahren zum Co-Maintainer. Also insofern habe ich ein bisschen was mitbekommen. Die Liste ist völlig still seit zwei Wochen. Da ist nicht eine Mail aufgetaucht. Insofern zu der Backdoor selber merkt man auf der Liste nichts. Ich denke, das passiert woanders.

Christoph Iserlohn Genau, aber ich finde schon, dass du dabei warst, auch wenn du es vielleicht nicht bemerkt hast. Also dir sagen die Namen der beteiligten Personen was, für viele andere, wie auch für mich, die sagen, vor zwei Wochen kann ich keinen dieser Namen, heute sind die sehr bekannt.

Aber es gibt noch einen zweiten Aspekt, warum du ein sehr guter Gesprächspartner dafür bist. Und zwar bist du ja auch im Open-Source-Umfeld aktiv und genauso wie ich. Und kennst das auch so ein bisschen mit der Situation von so einem Maintainer, der vielleicht der einzige Maintainer von einem Projekt ist und vielleicht auch Projekte, die gar nicht mehr so groß weiterentwickelt werden. Magst du da darüber nochmal kurz sagen, was du da im Open-Source-Bereich machst?

Stefan Bodewig Genau, also zum einen bin ich in der Apache Software Foundation aktiv. Das sind jetzt eher nicht unbedingt Projekte, wo ein Maintainer da ist, sondern ganz im Gegenteil, wo viel Wert darauf gelegt wird, dass es eine Community gibt, dass es auch mehr als einen Menschen gibt, die an einem Projekt mitentwickeln.

Aber jenseits davon bin ich auch in einer ganzen Reihe von anderen Open Source Projekten unterwegs. Im Fall von XML Unit, das der eine, die andere vielleicht schon mal irgendwo beim Testen gesehen hat. Abhängigkeit zum Beispiel von Spring Boot Testing, nicht ganz klein. Von daher bin ich im Prinzip alleine unterwegs, sowohl in der Java als auch in der .NET Version. Und es gibt noch andere Dinge, bei denen ich zumindest mitcontribute und wo wir auf dem Papier zu zweit sind oder sowas in der Art. Kommen wir vielleicht später nochmal genauer zu.

Christoph Iserlohn Genau, also perfekter Gesprächspartner über das ganze Open Source Zeug, was das so für Konsequenzen hat, wenn man vielleicht alleine maintaint. Und wenn wir vielleicht auch mal bewerten, was da passiert ist oder welche Möglichkeiten gibt dagegen zu steuern oder ob es auch welche gibt.

Das machen wir vielleicht so im hinteren Teil. Aber zuerst wollen wir darüber sprechen, was denn überhaupt passiert ist. Also, wenn ihr euch das vielleicht auch alle irgendwo mitbekommen habt, seid ihr bestimmt nicht unbedingt in allen Details drin. Deshalb wollen wir mal so zeitlich nachzeichnen, was ist überhaupt passiert. Weil das ist schon eine etwas längere Geschichte, die schon vor zwei, drei Jahren wahrscheinlich angefangen hat. Ich glaube, 2021 oder so waren, glaube ich, so die ersten Sachen, wo der Jia Tan, das ist die Person, die die Backdoor eingeführt hat, beziehungsweise der Name mit dem diese Person aufgetreten ist. Das ist wahrscheinlich nicht der richtige Name, nehme ich an, aber wir wissen es nicht. Also das ist schon ein bisschen länger. Das wir das Mal, versuchen so zu rekonstruieren, was so alles passiert ist. Und dann uns anschauen, welche Art von Backdoor ist das? Was ist überhaupt technisch passiert? Das ist auch ganz interessant. Das ist jetzt ziemlich ausgefuchst. Und dann im hinteren Teil des Podcasts dann darüber reden, welche Konsequenzen das hat und aus den eigenen Erfahrungen mal darüber sprechen, wie wir das so empfinden. Genau, dann lass uns doch mal anfangen mit dem Verlauf, was ist so passiert. Magst du dazu kurz was sagen, so zusammengefasst?

Stefan Bodewig Genau. Kann ich zumindest versuchen. Also das eine, was als jemand, der auf dieser Mailing-Liste drauf ist, relativ klar war, ist, es wird nicht mehr wahnsinnig viel entwickelt an der Bibliothek, eigentlich schon seit Jahren. Was nicht ungewöhnlich ist, der Kompressionsalgorithmus ist der Kompressionsalgorithmus, der ist einmal wohl definiert, der ist einmal implementiert. Und ich glaube, die Implementierung gibt es seit 15 Jahren in etwa. Da kann man jetzt nochmal ein paar Bugs fixen, da kann man für bestimmte CPUs Dinge optimieren, aber so wahnsinnig viel passiert eigentlich in dem C-Kontext. Und in dem Java-Kontext war es eigentlich genauso, der mich mehr interessiert hat. Was ich dann durchaus wahrgenommen habe, ist, dass vor zwei, drei Jahren, Leute haben wirklich Änderungen vorgeschlagen. Es gibt neben dem eigentlichen Kompressionsalgorithmus LZMA in dem XZ-Format noch die Möglichkeit Filter hinzuzufügen, die die Daten vorbereiten, damit sie besser komprimiert werden können. Und dann gab es jemanden, der einen neuen Filter eingeführt hat für Binaries für ARM-Prozessoren, um die schon mal vorzuverarbeiten, damit sie nachher besser komprimiert werden können. Und relativ kurz danach kam die Frage auf, warum wird denn das jetzt nicht sofort eingebaut? Und dann hat der Maintainer, Lasse, der einzige Maintainer auf dieser Mailing-Liste, nein, nicht auf der Mailing-Liste, eigentlich für das Projekt war, gesagt, okay, mir geht es gerade auch nicht so gut und eigentlich ist mir das alles zu viel und ich habe gerade gar keine Zeit und kein großes Interesse daran hier mitzuarbeiten und hat dann aber auf vielfachen Wunsch hin zumindest mal das gemergt und habe dann eben wahrnehmen können, dass Jia, wir wissen nicht so genau, ob es überhaupt ein Mensch ist oder nicht vielleicht eine Gruppe von Leuten, die dahinter stecken. Über die Zeit ein paar weitere Patches beigesteuert, von denen ich inhaltlich gar nicht genau sagen kann, worum es ging. Es sah irgendwie so aus wie normale Contributions und ist dann irgendwann zum Co-Maintainer geworden, wahrscheinlich, weil Lasse auch froh war, dass sich jemand anderer noch außer ihm mit drum kümmert, was ich super nachvollziehen kann. Und tatsächlich hat mir Lasse ihn den Jia irgendwann als Co-Maintainer vorgestellt für die Java-Ecke, weil er Fragen zur Java-Implementierung und den Auswirkungen auf Commons Compressed gehabt hat. Das ist das, was ich wahrnehmen konnte auf der Mailing-Liste, wenn wir vom technischen Teil weggehen. Beim Technischen ist es ganz viel in der C-Ecke, von der ich auch nicht 100% weiß, wie es funktioniert. Es ist sehr, sehr lange her, dass ich das letzte Mal C-Code geschrieben habe, den auch jemand anderen auch benutzen wollte. Da bin ich nicht ganz so tief drin. Ich habe mitbekommen in etwa, wie die Lücke funktioniert und dazu gehört offensichtlich, dass Schadcode auch committed worden ist vor kurzer Zeit, der größere Teil des Angriffsvektors steckt nicht im Git Repository, sondern erst in dem tar-Archiv. Auf dem eigenen Rechner wird der Schadcode eingebaut.

Christoph Iserlohn Ja, also das ist, habe ich auch so mitbekommen in der Form, was ich noch zusätzlich mitbekommen habe, bevor jetzt nochmal über die Technik sprechen ist, das wohl, es gibt ja jede Menge Leute, die das so rekonstruiert haben und auch auf die Nachrichten verweisen auf den Mailing-Listen oder auf die Git-Commits, die dann passiert sind, das wohl auch von außen Druck ausgeübt würde, auf den Lasse, dass die Pull-Requests und sowas schon so lange rumliegen und so, und dass man den Jia auch mit zum Maintainer macht, wo man jetzt, wenn man im Nachhinein so ein bisschen hinterherforscht, wo klar ist, dass das wohl Accounts sind, die für diesen Zweck extra angelegt wurden. Weil manche wurden kurz vorher angelegt, danach hört man die wieder was, man hört die sonst nie und so, man findet die nicht. Und dieselben Accounts haben dann später zum Beispiel auch noch wohl so ein PR mit gesendet an irgendeiner Stelle, die auch mit der Backdoor zu tun haben. Von daher, wenn wir später darüber sprechen, sollten wir darauf eingehen, dass da so ein bisschen Druck aufgebaut wurde, dass der auch wirklich Maintainer wird oder mindestens Commit-Rechte kriegt.

Oder sagen wir so, dass der Lasse sich noch mehr dazu genötigt fühlt, irgendwie etwas zu tun. Und dann ist es natürlich eine einfache Lösung zu sagen, da ist jemand, der sich engagiert, den kann ich jetzt mit einholen vielleicht. Ob man sich jetzt darauf freuen würde oder sagen wir so, dass der Lasse sich noch mehr dazu genötigt gefühlt hat.

Stefan Bodewig Genau. Die Nachrichten, auf die du dich beziehst, die habe ich dann auch noch mal nachträglich gelesen, weil ich mich gar nicht so genau an den Vorfall, der inzwischen auch schon eine ganze Weile zurückliegt, erinnern konnte. Es gab halt einen Mailing-Listen-Thread mit, was ich nicht sehe, Nachrichten. Das ist für die eine oder andere Apache-Mailing-Liste, ist das ein kurzer kleiner Sturm im Wasserglas, der da passiert ist. Insofern hätte ich dem nicht die große Bedeutung beigemessen? Die Bedeutung entsteht tatsächlich erst im Rückblick, dass das Leute sind, die vorher nie was mit dem Projekt zu tun hatten und auch danach nie wieder aufgetaucht sind, ist mir zumindest nicht aufgefallen, hat sich da schon länger irgendwo mit beschäftigt und sich dafür interessiert. Aber klar, weiß ich nicht, die Frage, warum liegt so ein Pull-Request lange rum, warum kümmert sich niemand darum, ist eine, die alle Open-Source-Maintainer wahrscheinlich oft genug gestellt bekommen, wenn sie nicht Vollzeit an dem Projekt arbeiten und damit auch nicht auffällig gewesen zu dem Zeitpunkt. Jetzt rückblickend ist es definitiv auffällig und schärft vielleicht auch ein bisschen die Sinne, wenn so was wieder passiert. Damals wirkte das völlig normal für mich

Christoph Iserlohn Ich bin jetzt nicht auf den Apache-Mailing-Listen unterwegs, aber man muss sich ja nur ansehen, was auf GitHub los ist, wenn random people kommen und einfach irgendwelche Forderungen stellen, was jetzt in den Projekten alles zu geschehen hätte, welche Pull Requests gemergt werden sollten, oder was noch Features sind, die implementiert werden, welcher Ton da herrscht. Also für mich wäre sowas, hab auch in ein, zwei Nachrichten reingeschaut, sag ich ja, so ist heute leider der Umgangston zum Teil, also völlig unauffällig. Wie gesagt, aus dem GitHub öffentlichen Kontext, wie auf dem Apache Mailing-Listen umgegangen wird, weiß ich nicht. Ich sehe das bei mir, also ich bin im MacPorts-Projekt schon lange unterwegs, Backend Management, auch schon immer, wenn eine neue Version rauskommt und jemand will ein Update dafür, wie dann schnell auch der Ton und der Druck, also der Tonfall sich ändert und der Druck aufgebaut wird, dass jetzt nun endlich wir den Downstream auch das Update machen. Deshalb, also für mich war das auch vollkommen, also im Nachhinein jetzt. Ja, so ist das leider halt. Das ist halt auch so ein Internet, wo wir uns anonym bewegen, und vielleicht so, dass man da schneller mal mit einem anderen Tonfall angeht. Genau, also dann, also Jia Tan wurde dann Maintainer, und hat dann angefangen, seine Backdoor dort zu installieren in den Code.

Das ist vielleicht eine gute Gelegenheit, mal zu schauen, wie ist denn die Technik, also nicht nur wie funktioniert die Backdoor, sondern wie wird die überhaupt gemacht. Du hast das gerade angedeutet, das kommt erst nur, wenn man das lokal baut, in die Maschine, auf die Maschine und zum Teil ist es nur in dem Release drin und nicht in dem Source Code.

Und da sollten wir uns vielleicht mal noch genauer anschauen. Zum Beispiel sollten wir uns mal unterhalten, was ist denn überhaupt ein Release und warum ist ein Release nicht der gesamte Source Code. Das ist ja an manchen Stellen auch normal. Das ist auch gar nicht so unauffällig, dass manchmal in so einem sogenannten Release mehr drin ist.

Stefan Bodewig Ja, aber du würdest eine Hintertür im Zweifel eher in dem Binary, das als Release rausgegeben wird, vermuten als im Quelltext-Baum, der als Quelltext-Release rausgegeben wird. Aber ja, genau, schauen wir uns das an. Irgendwann entscheidet man, jetzt ist das, was in meinem Git Repository drin ist, das möchte ich gerne releasen und dann bündeln wir das alles zusammen und in vielen Projekten, die ich kenne, ist es dann einfach ein TarGZ Archiv oder ein ZIP oder sonst irgendwas, in dem der ganze Quelltextbau mit allen Bildskripten und anderen Dingen drin liegt. In C-Projekten ist es, denke ich, ganz üblich, dass man auch schon Dinge, die anders sind, als sie im eigentlichen Quelltextbaum drin waren, weil man so eine Toolchain braucht von AutoTools, die dann einfach schon mal laufen gelassen hat, damit das einfacher für die Menschen ist, die es nachher bauen sollen. Das ist da eben Unterschiede zwischen, du hast hier einen Snapshot von meinem Quelltextbaum und dem, was dann als Quelltextbaum für das Release rausgegeben wird. Und in vielen Projekten gibt es eben fertig gebaute Binaries. Das wäre eher das, wo ich erwartet hätte, dass was passiert, aber in dem Fall nicht.

Christoph Iserlohn Ja, dem würde ich nur halb zustimmen, weil das kommt darauf an, in welchem Programm ich meine Backdoor mache. In dem Fall war es ja jetzt Open SSH, was attackiert wurde. Wir sprechen die ganze Zeit von XZ, das ist eine Library, die durch Umwege, da können wir uns gleich auch nochmal drüber unterhalten, auch manchmal in Open SSH drin ist, aber auch nur manchmal. Und das war ja das angegriffene Programm. Und Open SSH laden sich die Leute wahrscheinlich nicht unbedingt als Binary runter von der Open SSH Seite oder sonst wo, sondern die bekommen das im Zweifelsfall durch ihre Betriebssystem-Distribution oder durch einen Package-Manager. In MacPorts gibt es auch einen oben, SSH. Und da wird es ja dann auch, und die, also die Distributionen machen ja normalerweise ihre Release selber bauen aus den Tar Balls, die dann released werden oder in welchem Format auch immer das released wird, weil sie ja vielleicht auch Patches an den Dingern vornehmen. In dem Fall ja auch, weil oben SSH kommt nur durch gewisse Patches, reden wir gleich drüber, überhaupt in den Genuss eine Abhängigkeit zu, also eine indirekte Abhängigkeit zu den liblzma zu haben, wo das drinsteckt. Deshalb würde ich sagen, wenn ich das angreifen wollte, dann hätte ich, wenn ich so schlau wäre, wahrscheinlich auch das Tarball gewählt, weil mit dem Binary hätte ich wahrscheinlich keine große Verbreitung erreicht. Aber prinzipiell gebe ich dir recht, es ist einfacher, das im Binary zu verstecken, als im Source Code, weil da sollte man meinen, ja offensichtlich, oder wäre es offensichtlich, dass man so eine Vektor dann ja auch sehen kann. Das schöne Open Source Prinzip der vielen Augen, die drauf gucken, könnte man ja meinen, dass das funktionieren würde.

Stefan Bodewig Vielleicht ist es auch meine Java.net Brille der letzten Jahre, in denen ich hauptsächlich Open Source mache gewesen, wo eben das Binary ist halt irgendwas, was man so über einen Maven Central oder Nugget verteilt und die Distribution, die native Dinge verteilt, ist halt anders. Es funktioniert eben anders.

Christoph Iserlohn Stimmt, vielleicht ist es auch meine Brille als MacPorts-Entwickler, weil wir ja eine Art Distributionsmechanismus sind und wir genau von solchen Upstream-Projekten immer die Sourcen nehmen. Und da nehmen wir auch öfter natürlich die Tarballs. Manchmal ist es auch aus dem Git direkt. Je nachdem, das kommt darauf an, wie das Projekt so aufgesetzt ist. Ja, das will ich auch gar nicht sagen, aber ich sage, in dem Fall, was im Nachhinein betrachtet auch logisch, dass man das nicht in eine Binary-Distribution gebracht hat, sondern in den Source Code, damit man die Verteilung viel größer hinkriegt. Aber gut, wo du gerade sagst Java und .NET, vielleicht kannst du noch mal kurz erklären, du hast es so kurz erwähnt, da sind so Autoconf und Autotools drin. Ich glaube, eine ganze Menge Hörer und Hörerinnen, die nicht so in dem C-Umfeld unterwegs sind oder die das Glück haben, noch sehr jung zu sein und das alles nicht so mitmachen mussten. Kannst du noch mal erklären, was sich dahinter verbirgt und warum man das dann vielleicht nicht drin hat? Ich glaube, das wäre ganz interessant.

Stefan Bodewig Also in vielen Fällen weißt du das im Zweifel besser als ich als MacPorts-Maintainer. Daran woran ich mich erinnern kann ist, dass du halt nicht die Standard-C-Quelltexte schreibst, sondern immer wieder Abhängigkeiten davon hast, dass unter bestimmten Betriebssystemen die header files für irgendeinen C-Compiler woanders zu finden sind oder anders heißen, dass bestimmte Typen verschieden groß sind, also wie muss ich das Ding nennen, wenn ich einen 64-Bit Integer brauche? Bevor wir da zu tief in Technik reingehen, du hast halt C-Quelltexte, die du anpassen musst, passend für das System, auf dem du eigentlich das Binary bauen möchtest. Und um das einfacher zu machen, gibt es eine Toolchain, die erkennt ganz viele Dinge zur Bildzeit und kann den C-Quelltext und die Makefiles oder was man immer braucht, CMake, keine Ahnung, was da genau benutzt wird heute, anpasst auf bestimmte Systeme und da wird das bei den meisten Entwicklern nicht notwendig sein, dass sie diese Auto-Tools vollständig konfiguriert auf ihrem Rechner drauf haben und da wird vieles schon mal vorab erledigt. Damit das eigentliche Ausführen und Bauen für jemand, der das individuell selber bauen möchte, einfacher gemacht wird. Das ist so meine Brille darauf.

Christoph Iserlohn Ja, also würde ich ähnlich beschreiben. Also C ist halt so sehr low-levelig, dass man dem, dass es sehr abhängig ist von dem System, wo es drauf ist. Also es ist halt nicht wie Java, wo man so sagt, okay, wenn ich Bytecode habe, kann ich ihn auf jeder JVM ausführen, sondern da muss ich halt gucken, genau, auf welchem System bin ich, sowohl Hardware als auch Software. Und dann gibt es halt meistens irgendwie so einen Schritt, bevor man kompiliert, gibt es einen Configure-Schritt, der dann so diese ganzen Metadaten einsammelt, wie groß ist meine Registerbreite, wo sind Header-Files und sonstiges. Der das dann dem Programm bereitstellt, wenn das dann im Bildprozess ist, der dann sozusagen sagt, okay, wenn das so ist, dann mache ich das und das.

Und damit ich das überall habe, ich kann so ein Configure Script zum Beispiel für meinen Rechner haben, aber dann funktioniert der vielleicht auf deinem nicht. Wird er wahrscheinlich sowieso nicht, weil ich habe jetzt hier einen Mac mit einem ARM Prozessor da stehen und du hast einen Linux noch auf Intel Basis da stehen. Das wird wahrscheinlich nicht so einfach sein, dass wir den C-Code nehmen könnten und den einfach kompilieren können als Configure Script, sammelt halt diese ganzen Daten ein. Und dann macht das zum Beispiel auch solche Tests. Okay, auf welchem Prozessor-Architektur bin ich denn hier? Machen einen Test, welche Distribution habe ich und so weiter und so fort. Und um das zu machen, diese ganzen Tests und alles, da gibt es halt sozusagen den Schritt, das ist automatisiert mit diesen Auto-Tools. Also ich vereinfache jetzt so ein bisschen, es gibt noch viel mehr Schritte, die die machen.

Die haben sowas auch automatisch erstellt und dann kriegt man aber halt auch solche Skripte raus, die von Autotools erstellt wurden, die leider sehr schlecht lesbar sind, weil die sind Maschinen erstellt und die sind dann auch noch in einer ziemlich strengen Makro-Sprache, M4 geschrieben und die sind nicht dafür gemacht, dass Menschen die lesen können. Und so sehen sie auch aus. Und die hat man dann normalerweise unbedingt auch nicht im Git eingecheckt, sondern dann auch wirklich in den Releases. Es ist also kein besonderes Vorgehen gewesen, dass man sagt, das Release war abweichend zu dem, was im Git ist.

Und zwar abweichend nur in dem Sinne, es war zusätzlich was drin. Also war ja nicht, dass der C-Code da schon verändert war oder so, sondern nur dieses ganze Skriptzeug wurde da verändert. Nein, wurde hinzugefügt ein Skript und das, war bis dahin, ob das jetzt in Zukunft noch so sein wird, weiß ich nicht. Das müssen wir mal sehen. War es auch normal im C-Umfeld, dass da noch Zusatzkripte drin sind, die dann nur in den Release für das jeweilige System drin sind. Genau.

Ja, und dann hast du gerade gesagt, der Binary Code wurde gar nicht eingecheckt. Das stimmt ja nur so halb, also der wurde schon eingecheckt, aber in einer Form, wo man es jetzt nicht so sieht. Vielleicht kannst du das nochmal erzählen, was da passiert ist. Ja. Ja.

Stefan Bodewig Ich habe gesagt, der Schadcode war gar nicht in Git. Er war gut versteckt. Er war versteckt in einem Testcase. Es liegen für automatisierte Tests, für Regressionstests liegen da einfach mal Testarchive in dem Git Repository drin. Völlig normal die Vorgehensweise.

Zumindest war das die in diesem Repository auch vorher gelebte Vorgehensweise, um Tests zu schreiben, um zu überprüfen, dass man geschriebene XZ-Dateien auch wieder dekomprimieren kann, dass da einfach fertige XZ-Dateien liegen und es Test-Cases gibt, die das dann eben dekomprimieren und genauso, dass man mit bestimmten korrupten Archiven korrekt umgeht, dass man nicht unglaublich viel Speicher oder CPU verbraucht, bloß weil man mal auf eine kaputte Datei trifft.

Da ist es nicht ungewöhnlich, dass man das macht. In Commons Compressed haben wir das auch ewig gemacht. Es ist also auch in dem Fall nicht völlig absonderlich und abstrus, dass man Binaries eincheckt. Und in diesem Fall steckten da einfach Binaries drin, die als Test-Cases committed worden sind. Und da steckte dann der Schadcode drin. Ich könnte mir vorstellen, man guckt nicht unbedingt rein, was so ein konkretes Binary dann enthält. Wenn beim commit steht, das ist halt ein korruptes XZ-File und wir müssen mal testen, ob wir da nicht auf die Nase fallen, wenn wir das versuchen zu dekomprimieren. Klingt erstmal völlig plausibel.

Christoph Iserlohn Ist ja auch bei vielen Projekten so, die irgendwie mit einer Art von Binärdateien umgehen. Also wenn ich jetzt einen JPEG-Encoder oder Decoder habe oder MP3s, dann habe ich da auch jede Menge Dateien. Drinnen liegen fertige MP3s oder JPEGs oder sagen wir mal eine Bibliothek für Bilder, dass ich mit denen korrekt umgehen kann. Und genauso wie du gesagt hast, auch für welche, die korrupt sind und gucken, wie reagiere ich da. Es muss ja noch gar nicht so handlos sein wie, ich verbrauche zu viel CPU, ich kann ja auch abstürzen dabei. Gerade in den C-Bibliotheken habe ich da nachher noch einen Buffer-Overflow oder so. Schon ganz gut, wenn das da drin ist. Also auch noch nicht besonders auffällig, dass Binärdateien da drin sind.

Und du sagtest gerade, da guckt ja auch keiner unbedingt rein. Da konnte ja auch gar keiner reingucken. Also welches File war das? Das war nämlich ein korruptes file. Also ein Testcase für ein angeblich korruptes File. Aber das war ja gar nicht so korrupt.

Stefan Bodewig Genau. Einfach ein Haufen Bytes.

Christoph Iserlohn Ja, also es war erst mal korrupt, aber wenn man dann, das war ja der Trick mit dem Skripten, die dann in dem Glee Star Ball drin war, das hat das File dann verändert, hat dann ein paar Bytes getauscht, genauer gesagt, da ist da glaube ich so ein TR drin, in dem ersten File, das Spaces und Tops vertauscht, also war einfach so ein Caesar Cipher sozusagen. Und nachdem das angeblich korrupte Fall damit behandelt wurde, kommt man es nämlich entpacken. Und da befand sich dann ja der Schadcode eigentlich drin. Das ist es ein bisschen verkürzt dargestellt, sondern da befand sich dann ein Shell-Script drin, der dann noch den Source-Code gepatcht hat und noch zusätzlich ein Object-File, das dann schon vorgefertigten Schadcode enthielt. Aber da sieht man alles erst, wenn man sozusagen das Configure-Script oder das Make-File an der richtigen Stelle unterbricht.

Sonst wird das einfach auch noch durch weitere Sachen gepiped und dann ist das Makefile verändert. Da müsste man sich das Makefile von mehreren tausend Zahlen durchlesen, um dann irgendwelche Veränderungen zu sehen. Diese Veränderungen muss man dann erstmal entdecken und die sind dann auch nicht unbedingt offensichtlich, sondern dieses Makefile ist ja auch zum Teil auch autogeneriert, da sind eben nicht immer lesbare Sachen drin und das sieht alles noch komplett legitim aus erstmal, dass da noch was verlinkt wird. Dieses Objectfile ist nämlicha uch schon in ähnlicher Form wird das erzeugt. Da ist nur der Unterschied einmal mit dem Unterstrich, einmal mit dem Minus, so die Worte getrennt. Also rein wenn man einen optischen Scan macht, fällt das gar nicht auf, der Name sofort. Da muss man sehen, okay, da ist ein underscore benutzt und da wird ein Minus benutzt. Das muss man dann auch erstmal wissen. Und in dem Fall wird das Original und so auch erstmal abgeräumt. Und wenn das nicht funktioniert beim Kompilieren, dann werden auch die Files, die die Backdoor enthalten, auch gelöscht. Also siehst du nach einem normalen Make-Lauf, wenn da was schief gelaufen ist oder das dann analysieren wird, siehst du es erst gar nicht. Also du musst das schon an den richtigen Stellen stoppen. Sieht alles ganz harmlos aus. Aber diese Object files haben es dann in sich. Was machen die denn? Die biegen ja da irgendwie was um von der Funktionalität.

Stefan Bodewig Genau, also technisch bist du offensichtlich tiefer drin als ich, um das ganz klar zu sagen. Das, was ich auf jeden Fall mal mitnehme, ist, da ist eine ganze Menge Hirnschmalz reingeflossen, das möglichst versteckt unterzubringen und auch hinter sich alle Spuren wieder zu verwischen. Da ist nicht jemand nur unterwegs gewesen, um mal eine Hintertür in irgendwas einzubauen, sondern hat auch alles dafür getan, dass diese Hintertür möglichst schlecht erkennbar ist und dass möglichst niemand Verdacht schließen kann. Das was ich verstanden habe ist, dass bei bestimmten Linux-Distributionen SSH so gepatcht wird, dass es mit systemd zusammenarbeitet, also einem Prozess, der auf diesen Linux-Distributionen genutzt wird, damit SSH mit systemd korrekt zusammenspielen kann und systemd selber eine Abhängigkeit von der liblzma hat, sodass auf diese Art und Weise dann durch den Patch erst OpenSSH eine Abhängigkeit zu liblzma bekommt. Und dass in der gepatchten liblzma eine Funktion drinsteckt, die genauso heißt wie eine valide Funktion innerhalb von OpenSSH und sagt, ich bin jetzt hier die zuständige, nutze einen indirekten Funktionsmechanismus, den die G-LIPC anbietet. Der für sich genommen, dass es den gibt und dass man den benutzen würde innerhalb von liblzma erstmal völlig plausibel klingt, der also dafür sorgen kann, dass ich zur Laufzeit die Implementierung einer Funktion auswählen kann und dass ich bei der Kompression vielleicht abhängig davon, auf welcher CPU ich laufe, unterschiedliche Implementierungen ausführen möchte, klingt erstmal logisch. Insofern passt das. Dass liblzma prinzipiell dieses Feature nutzt. Und hier wird es aber offenbar genutzt, um zu sagen, ich ersetze jetzt mal eine Funktion in OpenSSH. So habe ich das verstanden. Eine Funktion, die aufgerufen wird, um während des Schlüsselverifizierens, RSA-Schlüsselverifizierens aufgerufen wird und wenn auf der anderen Seite der richtige Schlüssel ist, dann kann ich da Payload mit schicken und die wird möglicherweise auf dem angegriffenen System auf dem OpenSSH läuft ausgeführt. Das ist mein Verständnis dessen, wie das Ganze funktioniert.

Christoph Iserlohn Genau, also es ist eine Funktion, die eine Schlüsselverifizierung macht, die lustigerweise aber decrypt heißt in dem Fall. Also der Name ist da ein bisschen irreführend. Und an der Stelle, genau, gibt es einen hardkodierten Key, ein Public Key. Und da kann man, da werden noch ein paar weitere Daten mitgeschickt, wenn man so ein SSH-Zertifikat entschickt, wo so ein Schlüssel drin ist. Dann steht immer noch der Key des Signer drin, also der dieses Zertifikat signiert hat, der Public Key von dem. Und da kann man dann ein Payload drin verstecken, weil der wird erstmal ja nicht unbedingt gebraucht. Aber der eigentliche Schlüssel wird schon verifiziert, deshalb kann ich mich auch weiterhin einloggen. Das ist nämlich so, dass da ist ein hardkodierter Key drin. Und wenn der kommt, dann wird so eine Payload ausgeführt. Das kann man auch nachvollziehen. Dafür gibt es so einen Demonstrator. Also der führt einfach mit der Systemfunktion auf der einfach irgendeinen Prozesskommando aus. Also kann man beliebigen Code halt ausführen. Es scheint noch mehr Funktionen zu haben, die noch nicht klar sind in der Analyse. Deshalb haben wir für nochmal das Datum genannt. Also wenn ihr den Podcast in zwei Jahren hört, dann hat man vielleicht noch ein bisschen mehr darüber herausgefunden, was das so kann. Aber gut, eine Remote Code Execution ohne Authentifizierung ist ja schon für einen Eingreifer der Lottogewinn. Also der 6er im Lotto. Weil dann kann ich ja eigentlich so gut wie alles machen. Genau, das macht das Programm. Aber es wird noch ein bisschen mehr versteckt. Darauf gehen wir jetzt vielleicht nicht im Detail ein. Aber wenn dieser Listener, also diese indirekte Funktion iFunk installiert wird, dass es auch noch versteckt in einer sogenannten CPU-ID-Funktion, die am Anfang aufgerufen wird, wo der sozusagen eigentlich Metainformationen holt, um zu entscheiden, welche Funktionen zum Dekomprimieren nehme ich denn dafür. Je nachdem, wenn ich jetzt auf einen Prozessor, der vielleicht bestimmte Erweiterungen hat, hier SSE3, SSE4, wie diese ganzen Vektorerweiterungen heißen, dass man darüber Informationen hat. Und da fängt er schon an, das zu überschreiben, die Funktion, die überhaupt nichts mit dem Komprimieren so zu tun hat. Wie du sagst, das ist dann auch so oben SSH. Genau. Und danach hat man dann halt eine Lücke, die ausnutzbar ist, aber auch nur für denjenigen, der den Private Key zu dem hardkodierten Public Key besitzt. Was so ein bisschen darauf hinweist, dass das vielleicht auch staatlich ist. Da gibt es ja diese No-Bus-Lücken. Nobody but us. Also wir bauen Lücken ein, aber keiner darf sie benutzen außer uns und kann sie benutzen. Und in dem Fall ist das auch so, weil keiner diesen Schlüssel hat. Jetzt fragt man sich vielleicht, warum kann man denn, ich habe gerade gesagt, da gibt es einen Test, wie man das machen kann. Ja, der Source Code ist ja da, auch von der kompromittierten Version. Das heißt, da hat man dann den hardkodierten Schlüssel ausgetauscht mit einem, den man dann selber erzeugt hat. Und dann kann man die Funktionalität halt nachstellen. Aber man kann jetzt nicht testen auf öffentlichen Systemen, ob diese Lücke da ist. Jedenfalls nicht über, ich scanne das von außen, weil ich den richtigen Schlüssel mitsende. Das funktioniert halt nicht. Das bräuchte man den privaten Schlüssel.

Stefan Bodewig Genau, vor allen Dingen deshalb, weil der Fallback weiterhin ist. Wenn es nicht der Schlüssel ist, mit dem ich Kommandos entgegennehme, dann verhalte ich mich genauso, wie die Originalfunktion das getan hätte, sodass ich wie ein ganz normaler Open-SSH Server nur ein bisschen langsamer offenbar bin, sodass diese Lücke dann durch glücklichen Zufall überhaupt erst entdeckt werden konnte, weil sich jemand gefragt hat, warum plötzlich Dinge langsamer geworden sind. Was die staatlichen Dinge angeht, insgesamt diese ganze Vorbereitung von zwei Jahren Vertrauen aufbauen, bis ich überhaupt anfange, eine Lücke einzubauen, klingt für mich nicht nach der üblichen Ransomware Gang, die versucht jemanden zu erpressen. Das deutet einfach darauf hin, dass viel, viel Aufwand betrieben worden ist und eigentlich mehr als man den üblichen kleinen Kriminellen zutrauen würde.

Christoph Iserlohn Auf jeden Fall. Das muss man schon länger geplant haben. Und Ransomware-Gangs verstecken sich vielleicht auch nicht so, sondern die sagen, jetzt sind alle deine Daten, verschlüsseln, zahlen mal bitte. Ich weiß nicht, wie weit man dann kommt, wenn man weltweit Systeme mit Open SSH kompromittiert. Aber, ja, sagen wir so, auf was man so liest, aus der Fachwelt im Security-Bereich gehen alle davon aus, dass das eine staatliche Aktion war.

Aber man kann nicht sagen wer. Natürlich wird hier wieder sofort auf China oder Russland gezeigt. Aber man hat eigentlich keine Anhaltspunkte zu sagen. Also man hat vielleicht Indizien für hier oder da, aber das können auch alles falsche Fährten sein. Man weiß das nicht. Ja.

Stefan Bodewig Ja, ich habe so Dinge gesehen, dass Leute geguckt haben, in welcher Zeitzone oder zu welchen Uhrzeiten Gitcommits gemacht worden sind und die schließen dann auf Zeitzonen, an die jemand normalerweise arbeiten würde. Ich denke, das ist alles Unsinn, auf sowas aufzusetzen, weil das, wenn ich das Partu verschleiern will, dann sorge ich eben auch dafür, dass das plausibel aussieht.

Christoph Iserlohn Ja, also das mit den Zeitzonen hat man ja schon oft gehört. Die arbeiten zu den chinesischen oder russischen Office-Stunden. Das weiß ja jeder und das wissen auch die, die so was machen. Also wenn sie dann die Schuld auf jemand anders schieben wollen und ihre Spuren verwischen, dann kann man natürlich das auch so entsprechend steuern. Ich glaube, Leute, die in dem Bereich arbeiten, da gibt es auch keine Gewerkschaft oder Betriebsrat, die auf Arbeitszeiten von 9 bis 17 Uhr bestehen würden, sondern da ist das ja auch anders. Was ich auch gehört habe als Indiz war, dass einer die Sprache analysiert hat. Es waren Linguisten, die wohl gesagt haben, das sieht so aus, als wäre das ein Russe. Man ist ja wahrscheinlich nie so gut wie ein Native Speaker, was er so geschrieben hat auf Mailinglisten und zu den Kommentaren und Patches würde das wohl sich so anhören, als wäre das ein Russe, der Englisch gelernt hat und kein Chinese. Das kann man wohl unterscheiden. Ich weiß nicht, ob das Humbug ist. Das habe ich nur gelesen. Ich habe auch keine Ahnung. Ich bin kein Linguist, aber auch eine Möglichkeit, Indizien zu finden, ob man vielleicht daraus kriegt, woher jemand kommt, je nachdem, welche Muttersprache er spricht. Aber das ist, wie gesagt, Spekulation. Es gibt ja auch Informationen über gewisse Geheimdienste aus der westlichen Hemisphäre seit dem Herrn Snowden, die ja auch darauf hinweisen, dass die ja auch nicht anders arbeiten und genau so was machen würden, im Zweifelsfall. Von daher, wer weiß. Das werden wir nicht aufklären, wahrscheinlich wird das auch eher nicht aufgeklärt werden. Genau. So, du hast gerade angesprochen, ja, dann wurde das entdeckt. Wie gesagt, die Bildzeitung titelte Ein Deutscher rettet das Internet.

Vielleicht können wir darüber noch mal kurz sprechen. Dann sind wir immer noch so bei dem zeitlichen Ablauf, was dann so passiert ist, wie er das gefunden hat und was dann passiert ist. Und warum vielleicht das auch nicht so ausgereift war an der Stelle, so mit dem, dass man es noch entdecken konnte. Weil da ist ja auch ein bisschen Druck draufgekommen. Ich weiß nicht, ob du das mitbekommen hast. Aber erstmal vielleicht, wie ist es denn rausgekommen?

Stefan Bodewig Ich erinnere mich nur, dass ich vor zwei Wochen in meinem RSS-Feed einen Verweis auf eine Mail auf der Open-Wall-Mailing-Liste tauchte.

Christoph Iserlohn Ja, es ist was Open-Wall. Die verlinken wir auch, die Nachricht.

Stefan Bodewig Darin hat einer der PostgreSQL Entwickler festgestellt, auf seinem System liefen irgendwelche Dinge langsamer. Er hat versucht herauszufinden, warum die Dinge langsamer waren beim SSH Login getraced und irgendwie profiling betrieben und sich dann sehr darüber gewundert, dass die Funktionsaufrufe nicht in den Bibliotheken waren, die er erwartet hatte, sondern dass sie irgendwie in liblzma gewesen sind und hat dann weiter gesucht und hat erstmal seine vorläufigen Ergebnisse, hier sieht irgendwas sehr seltsam aus, veröffentlicht und damit angestoßen, dass sich viele Menschen darum gekümmert haben und damit beschäftigt haben. Aber es waren Performance-Probleme in erster Linie, die ihnen die in ihm einen Verdacht haben aufkommen lassen, dass irgendwas nicht stimmt. Wobei meine Vermutung ist, er hatte erst mal eigentlich nur gedacht, da ist irgendwas kaputt gegangen und dann kann ich einen Bug-Report abgeben, hier bei euch ist etwas langsam geworden und ich versuche mal den Bug zu verstehen, der da ist und nicht sofort mit, oh hier hat jemand eine Sicherheitslücke eingebaut, sondern mehr mit dem Bild eingestiegen ist, hier gibt es einen Bug und da kann man was dran tun.

Christoph Iserlohn Genau, also der Mensch hat, ich weiß gar nicht ob er jetzt bei Postgrease auch maintainers, er wartet jedenfalls für Microsoft, die bezahlen ihn, ich weiß aber nicht genau was er da so macht, hat halt so eine Bildfarm, aber auch für Postgrease, also das ist im Postgrease Kontext aufgetaucht, wo er dann halt auch Dinge im Vorfeld testet. Weil diese Lücke ist ja aufgetreten in dem Testing von Debian oder Unstable. Also nicht in der Release Version. Ich glaube Testing war es. Wo dann E-Sets mit der Vektor drin waren. Wo dann halt XZ mit der Backdoor dann drin war. Und dann hat er halt so eine kleine Regression in der Performance gefunden. Wohl auch beim Startup von oben SSH, das wohl länger dauert, weil dieser Händler installiert wird, für diese Funktion. Und dann auch beim Login. Und das ist gar nicht so viel, wo ich denke, ja, der Login dauert 0,2 Sekunden mehr. Ob mir das auffallen würde, weiß ich nicht. Das muss man schon, also wahrscheinlich auch beim Messen, ob das nicht so ein bisschen flattern da drin. Das ist ja nicht wirklich viel. Und der Start-up ist auch nur so 0,3 Sekunden Unterschied.

Stefan Bodewig Das ist ein Remote Login, wo du eigentlich auch noch immer das Netzwerk und alle anderen irgendwie mit berücksichtigst.

Christoph Iserlohn Ja, genau, das ist schon interessant und er hat dann nachgegraben und hat ja nicht nur entdeckt, dass die Funktion gepatcht wurde oder nicht die Funktion war, die er erwartet hat, sondern dass die auf einmal in der XZ-Library drin war, sondern hat ja auch noch herausgefunden, dass es in dem Tarball drin ist. Und nicht nur in Demian, sondern in dem Tarball von XZ, dass da eine Änderung ist. Und auch schon ein bisschen rausgekriegt, dass wohl dieses Archive, was da eingecheckt wurde als Testfall, wo die eigentliche Hintertür sich befindet, wenn man das Archive dann bearbeitet, dass es wieder entpackbar ist und dann auch noch eine Verschlüsselung hat und so, dass da was AKF dann bearbeitet, dass es wieder packbar ist und dann auch noch, aber eine Verschlüsselung hat und so, dass da was drin ist. Das hat er ja auch schon auch schon noch rausgefunden. Genau, das steht schon drin. Ja, genau.

Stefan Bodewig Das steht alles in dieser ersten Nachricht schon drin. Er hat den Mechanismus, wie der Schadcode hineinkommt, eigentlich erkannt gehabt. Es war nur zu dem Zeitpunkt völlig unklar, was macht der eigentlich. Es war nur klar, irgendwas passiert da und irgendwas ist sehr komisch und es liegt an den XZ-Utils, die installiert worden sind.

Christoph Iserlohn Ja, also das muss ich sagen, nötig mir viel Respekt ab. Da muss man schon eine ganz schöne Ausdauer haben, dass man so tief gräbt für so eine Sache und nicht, wie du gerade gesagt hast, einfach mal ein Buck Report machen. Ihr habt eine Performance Regression, besonders weil es ja ein Testing System ist. Da kann das ja passieren und das ist einfach dafür da, dass man sagt, ich könnte Feedback geben. Da macht man das vielleicht auch und gräbt nicht so tief. Wie habe ich das schön gelesen? Also freie Software ist ja auch mal free as a beer. Also das ganze Internet schuldet ihm jetzt ein Bier dafür, dass er das entdeckt hat und auch so viel verhindert hat. An der Stelle, dass diese Backdoor ja durch Zufall gerade entdeckt wurde. Also wirklich ein glücklicher Zufall, muss man ja sagen. Genau. Aber Da sind ja noch andere Zufälle davor gekommen. Ich weiß nicht, ob du es mitbekommen hast, dass ja ein gewisser Zeitdruck war, dass man diese Backdoor auch ausrollt.

Stefan Bodewig Ich habe das im Nachhinein mitbekommen, dass also Zeitdruck deshalb, weil was ich nicht gewohnt, 24 04 steht jetzt irgendwie an und entsprechend gibt es auch andere Release Planner, die da sind und es ist Druck auf die Maintainer dieser Distribution ausgeübt worden, weil die neue XZ Utils Version angeblich vorgeblich besonders tolle neue Feature hat, dass man das noch unbedingt mit in diesen Release Train reinbringen wollte. Das ist der Zeitdruck, der sicherlich da war. Und ich habe gelesen natürlich, dass in den entsprechenden Bugtrackern der Distributionen Druck ausgeübt worden ist, dass Sie doch bitte die neueste Version von XZutils einsetzen sollten in den nächsten größeren Release.

Christoph Iserlohn Und da tauchen auch wieder diese Accounts auf, die vorher Druck gemacht haben, zum Teil auf der Mailing-Liste für das Projekt. Genau das ist es. Und es gab noch eine weitere Art von Druck in die andere Richtung. Und zwar ein Zeitdruck für die Leute, die diese Backdoor erzeugt haben. Weil in der Zeit ist nämlich ein Patch aufgetaucht bei systemd, der die XZ-Library entfernt. Da gibt es nämlich so ein Patch und ein Projekt, um die 100.000 Abhängigkeiten von Systemen ein bisschen zu verschlanken, auch in Hinsicht, dass es ja viel sicherer ist, wenn man nicht so viele Abhängigkeiten haben. Also, ich weiß nicht, ob er schon gemergt war, aber dass alle das gut fanden und dass der in Zukunft oder vielleicht ein bisschen noch aufpoliert auch gemergt werden wurde, dass man solche Sachen entfernt und LibXZ oder liblzma war halt dabei, auch auf der Entfernung zu sein. Das heißt, es gab einen gewissen Zeitpunkt nach diesen zwei Jahren oder drei Jahren, die man dafür gemacht hat, dass man das noch aus der Tür kriegt mit dem Release und Debian Releases sind ja auch sehr lange, also verweilen sehr lange in so einer stabilen Dauer, bis wieder was kommt. Das heißt, da wäre das Zeitfenster dann wahrscheinlich sehr groß gewesen, wie lange diese Lücke da ist, bis dann Debian vielleicht auch auf System-D umsteigt, ohne diese Abhängigkeit, wo dann die Lücke geschlossen, automatisch geschlossen wäre. Also da gab es auch nochmal Zeitdruck in beide Richtungen. Genau, es gab den Druck, Da gab es auch nochmal Zeitdruck in beide Richtungen.

Nehmt das doch mal auf. Die nächste Version steht für der Tür. Ist alles viel besser. Und gleichzeitig hatten wohl die ein bisschen Druck, die die Lücke gemacht haben. Und es wird, und es ist natürlich auch reine Spekulation, an der Stelle auch gesagt, dass werden sie ein bisschen mehr Zeit gehabt hätten, dass das auch besser gewesen wäre, dass das nicht so aufgefallen ist mit dem Performance-Verlust, weil sie haben die Lücke auch vorher nochmal verbessert, also die Backdoor. Es gibt ja dieses Programm Wellgrind, mit dem man so ein Programm instrumentieren kann und dann, der so bestimmte Dinge rausfindet, das ist eigentlich auch so gegen Buffer-Overflows und Performance-Bessung und also alles womögliche, was im C++-Feld an Fehlern auftreten kann, was man dann zur Laufzeit mitkriegt. Und da gab es auch Probleme mit der XZ-Version, die die Backdoor hatte. Das war die 5.6.0 und dann kam eine 5.6.1, wo dieser Jia Tan auch ein paar Sachen gefixt haben, dass Wellgrind nicht mehr aufschreit. Also man hat da auch noch dran gefeilt. Sie hat zwar prinzipiell funktioniert, das Ding hat aber Warnungen ausgegeben und dann hat er das nochmal so gemacht, dass es weniger Warnungen gab. Von daher, genau, wer weiß was passiert wäre, wenn da noch ein bisschen mehr Zeit gewesen wäre, um das noch zu polieren. Man weiß es nicht.

Stefan Bodewig Hinter Log4Shell haben wir beide mit Lisa schon mal einen Podcast aufgenommen, bei dem ich auch auf OSS-Fuzz verwiesen habe, also so eine Fuzzing-Service, den Google Open Source-Projekten zur Verfügung stellt, die Bibliotheken, in dem Fall, bei dem ich da beteiligt gewesen bin, Commons Compress, mit irgendwelchen Byte Arrays zu bewerfen, um herauszufinden, was passiert denn, wenn ich denen sowas als Archiv mitgebe. Und die XZ-Utils nutzen ebenfalls eigentlich OSS-Fuzz. Und das hat wohl auch angeschlagen, so dass bestimmte Tests erst mal abgeschaltet worden sind durch Pull Request von Jia, um dafür zu sorgen, dass nicht als Fehler tatsächlich so offensichtlich auffällt, dass hier irgendwas komisch läuft. Genau, damit sein Patch plausibler aussah.

Christoph Iserlohn Und er hat auch irgendwo mal noch Patches eingereicht, damit diese iPhone Funktionalität noch besser funktioniert, was ja gar nichts damit zu tun hat, sondern nur damit seine Lücke, also seine Backdoor nicht so leicht entdeckt werden kann.

Stefan Bodewig Genau, also das ist alles schon ganz gut.

Christoph Iserlohn Genau, und dann ist es rausgekommen und die Panik war groß. Besonders weil das war natürlich das Osterwochenende. Wahrscheinlich haben sich auch viele Leute auch darauf gefreut, da vielleicht mal frei zu haben oder mit ihrer Familie unterwegs zu sein und dann großes Rückrollen war angesagt für viele Distributionen, die dann das alles rückwärts machen, wieder auf eine alte Version gehen mussten. Ich hatte das bei MacPorts mitgekriegt, das kam natürlich noch oft darauf. Da haben man sich entschieden, was ich sehr riskant fand oder finde, auch erst mal darauf zu bleiben, weil ja dieses Shell-Script nur zieht, wenn du auf einem Linux-System bist und ich glaube dann speziell wird auch auf Fedora und Debian, also überall wo man das nutzen kann.

Stefan Bodewig Ich glaube, es hat geschaut, ob du ein Debian oder Paket oder ein RPM baust. Also nur in solchen Fällen, genau.

Christoph Iserlohn Genau, und aber auch x86 und so, dass das für den Mac jetzt keine Relevanz hat. Diese iFunk-Funktionalität gibt es auch nicht, weil Mac nutzt nicht die G-Libc, sondern eigene Libc. Also von daher ist das sehr plausibel, dass das nicht funktioniert und nicht eingebaut wird, aber irgendwie bleibt so ein ungutes Gefühl, weil ja auch noch nicht alles analysiert ist, aber gut, hat man sich dazu entschieden. Ich war nicht dabei bei der Entscheidung oder hatte da nicht viel mitzureden, aber schon interessant. Andere sind trotzdem zurückgerollt, auch wenn man sagen könnte, ja, das betrifft euch nicht. Also Abenddistribution für Linux oder was weiß ich was. Debian hat seine ganze Bildstruktur für das Testsystem abgerissen und neu aufgebaut.

Stefan Bodewig Sicher ist sicher.

Christoph Iserlohn Genau, man weiß es halt nicht, aber das ist auch viel Arbeit. Das ist dann schön an Ostern. Wer weiß, wie viele Leute auch von Debian so abhängig sind, auch von Debian Testing. Man weiß es nicht. Genau. Hatten wir ganz viel Glück gehabt. Wer weiß, wo noch so solche Sachen alles lauern, weil diese Situation, und damit kommen wir jetzt vielleicht mal zu dem zweiten Teil, für Open Source Maintainer, das ist ja wahrscheinlich nicht der einzige, das hatten wir schon am Anfang kurz erwähnt, der vielleicht in so einer Situation ist, wo man sagt, er ist der einzige, der wird nicht bezahlt, er hätte selber wohl auch geschrieben, dass er psychische Probleme hat, wir wissen jetzt nicht, ob die von seiner Maintainer-Arbeit herrühren oder nicht. Das kann natürlich ganz andere Gründe haben. Wir kennen den ja nicht irgendwie privat oder so. Aber das hört man ja öfter und man hat auf jeden Fall auch schon Leute mitgekriegt, die ein Burnout durch ihre Maintainer-Situationen haben. Das hört man ja öfter. Man hat auf jeden Fall auch schon Leute mitgekriegt, die ein Burn-Out durch ihre Maintainersituation haben, weil da so viel Arbeit ist. Genau. Es spielt jetzt auch keine Rolle, ob es da herkommt oder von woanders. In der Situation ist ja trotzdem noch ein Maintainer gewesen. Dann können wir jetzt mal vielleicht darüber sprechen. Vielleicht hast du da ja Erlebnisberichte, wie das so ist, wenn man Maintainer ist in der Situation, wo man vielleicht der einzige Maintainer ist.

Stefan Bodewig In verschiedenen Richtungen. Also das eine ist natürlich, viele von den Leuten, die Open Source machen, machen das ja heute vielleicht aus anderen Gründen als früher. Ich mache Open Source seit fast 30 Jahren inzwischen und das ist ganz viel Hobby und ich will mal Dinge ausprobieren gewesen und vielleicht kann jemand das brauchen, was ich hier gemacht habe. Und irgendwann freut man sich, wenn andere Leute mitmachen, dass man nicht eben nur in so einem stillen Kämmerlein für sich irgendwas hin entwickelt, sondern eigentlich macht es mehr Spaß, wenn man mit mehr Leuten zusammen entwickelt und Feedback für das bekommt, was man gemacht hat und einfach als Team zusammenarbeitet. Das ist das, was ich eben schätze bei den Projekten, die ich bei Apache habe. Aber es gibt eben Dinge, für die interessiert sich außer dir niemand. Und dann bist du eben zwangsläufig der Einzige, der daran arbeitet.

Stefan Bodewig Oder irgendwann haben sich vielleicht außer dir auch noch andere Leute dafür interessiert, aber jetzt tut es das, was sie wollten und jetzt geht man einfach wieder, weil es gibt keinen Grund mehr, warum man sich daran weiter beteiligen sollte. Und im Fall von XZutils, ich glaube, Lasse ist, wenn ich das richtig in Erinnerung habe, eigentlich der Originalautor von praktisch allem Quelltext, der da ist. Er hat also diesen Algorithmus rausgeholt, im Endeffekt aus dem 7-Zip-Umfeld und verfügbar gemacht auch für andere Dinge. Kommandozeilen-Tooling und das XZ-Format als solches hat er definiert, wenn ich das richtig verstehe. Er hat eine Menge Arbeit reingesteckt, aber das ist jetzt im Prinzip auch mal fertig. Und da braucht man jetzt auch nicht mehr, so war es nicht viel zu maintainen. Hin und wieder kommt mal jemand vorbei, aber eigentlich habe ich für das gar keine Zeit mehr vorgesehen, weil es ist ja eigentlich fertig und dann ist es eher so lästig, da nochmal was tun zu müssen, möglicherweise, also selbst wenn ich nicht noch zusätzlich unter anderen Belastungen leiden sollte. Also ich kenne das aus der eigenen Richtung. Für XML-Unit habe ich eben schon mal angesprochen. Da habe ich auch jemanden, der die assert.j, das ist ein Test-Framework oder ein Assertions-Framework für Java, die XML-Unit-Integrationen damit beigetragen hat. Dem habe ich nach dem dritten Pull-Request-Schreibrecht auf dem Repository gegeben, weil ich das sah okay aus, was er gemacht hat und es war vernünftig und ich bin davon ausgegangen, dass ich das schon mitkriegen werde, wenn er da irgendwelche komischen Dinge tut. Also mir selber vertraut, dass ich das wohl irgendwie auf die Reihe bekommen werde. Aber ich hielt es für völlig normal, dass ich das tue, weil das auch die normale Vorgehensweise in vielen Open Source Projekten ist grundsätzlich mal das Beste zu erwarten von Menschen, die vorbeikommen und zu vertrauen darin, dass da niemand irgendwas Böses möchte und wenn es technisch okay aussieht und wenn die Kommunikation soweit in Ordnung ist, dann tut es das. Genauso kenne ich das eben auch aus der anderen Richtung, dass ich zu Open-Source-Projekten beigetragen habe und anschließend selber in eine Co-Maintainer oder Maintainer-Rolle geschlüpft bin, geraten bin. Bei XML-Unit war das beispielsweise so, als diesem einen Beispiel, ich habe irgendwann 2006 oder sowas meine ersten Patches abgeliefert und war dann plötzlich Eigentümer des Projekts bei SourceForge. Kennt heute niemand mehr.

Christoph Iserlohn So was wie GitHub, aber in Alt.

Stefan Bodewig Genau, alt passt zu mir. Aber auch in anderen Ecken, wo ich dann auch weiß, eigentlich hätte der Maintainer nicht genug über mich gewusst und trotzdem ist mir das Vertrauen geschenkt worden, jetzt Co-Maintainer zu werden. Ich habe das in anderen Projekten auch erlebt. Es ist eigentlich ein normaler Vorgang. Da taucht jemand auf, der kümmert sich, sieht technisch vernünftig aus, was die Person da macht. Und dann vertraue ich darauf, dass die auch weiterhin keinen Unsinn treiben wird. Und vertraue mir selber ein Stück weit, dass ich das schon alles im Blick behalten werde, was da passiert. Und gerade in so einem Fall, wie wir den hier haben, wo der Angriff ja nur so halb im Quelltextbaum auftaucht, nämlich in Form irgendwelcher Test-Archive und der zweite Teil des Angriffs überhaupt erst außerhalb vom Quelltextbaum passiert, wird es nochmal extra schwierig mitzubekommen, dass da vielleicht gerade was komisch gelaufen ist.

Christoph Iserlohn Ja, vielleicht könntest du ja gleich nochmal über so einen Release Prozess erzählen, weil da ist das. Vielleicht noch als kleiner Einwurf, vielleicht mal meine Perspektive aus meinem Open Source Aktivität. Ich hab angefangen, aus reinen Egoismus Patches zu liefern, weil ich brauchte Software in höheren Versionen oder Software, die noch nicht da gebundelt waren, Backboards. Und ich hätte das halt gern über den Package Manager dann gepflegt gehabt, anstatt immer irgendwie Quellen runterladen, hier, konfigurieren, sonst wie. Also weniger Aufwand. Hab das dann gemacht. Hab dann die erste Sachen sozusagen gepflegt, aber nur über Pull Requests. Also nicht ohne Schreibrechte. Und dann kommt man irgendwann ja, ach komm, ne. Ist ja sowieso dein Paket. Dann kriegst du auch Schreibrechte da drauf. Was beim Package Manager jetzt besonders ist, diese ganzen Rezepte, um die Sachen zu bauen, die liegen halt in einem Repo. Theoretisch könnte ich jetzt jedes der 30.000 Pakete ungefähr, die wir dann pflegen im McPorts auch verändern. Das ist auch interessant. Aber genau, wenn man jetzt sieht 30.000 Pakete und vielleicht 20 aktive Leute und wahrscheinlich nochmal 50, die zwar Schreibrechte haben, aber sich seit Ewigkeit nichts mehr getan hat, weil man sich auch gar nicht persönlich kennt, weiß man auch gar nicht, sind die noch aktiv, machen die noch was, aber hinten trotzdem noch Schreibrechte. Das überrollt einen dann auch. Ich kann zum Beispiel natürlich nicht. Einfaches Beispiel. Ich pakettiere Go. Das ist jetzt kein kleines Projekt. Wenn ein neues Release kommt, dann kann ich nicht selber den Review dafür machen, was jetzt alles neu reinkommt. Das geht bei kleinen Sachen. Oder wenn man nur eine einzige Sache macht, kann man das vielleicht leisten. Aber das ist eigentlich eine Vollzeitarbeit. Vertraue ich da drauf. Okay, Go Upstream ist jetzt gepflegt hauptsächlich von Google und so. Es ist eine große Organisation dahinter, die jetzt wahrscheinlich nichts Schlechtes will im Sinne von, wir bauen da eine Backdoor ein. Also von Google kann man ja halten, was man will, was die sonst noch machen. Aber dass sie da sowas einbauen, ist eher unwahrscheinlich. Und dann sagt man ja, der testet das erstmal, Bildprozess, sonst wie funktioniert danach alles noch mit unseren Sachen. Also das wäre auch wieder ein bisschen gepatcht. Also wir installieren dann halt zum Beispiel nach oblocal und nicht nach userbin und sowas. Aber das sind ja Kleinigkeiten, wie wir das verändern. Funktioniert alles noch und dann wird das übernommen, ohne dass ich da mir den Quellcode immer angucken kann.

Dann gibt es eine ganze nette Geschichte, ein Paket. Ich glaube, das war Parallel. Hat das mal der Maintainer reingeschrieben, also irgendein Kommentar sozusagen noch so. Wer das hier liest, der guckt auch wirklich rein beim Upgrade. Da ist natürlich niemand aufgefallen. Das hat er so mal als Test gemacht, ob er irgendwie eine Rückmeldung bekommen hat. Also die genaue Botschaft, weiß ich nicht, man sollte sie jetzt halt zurückmelden. Also die ganz wenige Downstream-Distribution haben das auch überhaupt bemerkt. Weil das ist halt, da ist halt ein Vertrauensverhältnis da. Und wie du sagtest, man geht dann von dem Guten aus, dass die Leute mit guten Willen da reingehen. Und ist auch ganz froh, dass sich Leute beteiligen. Als ich da zugekommen bin, waren auch Leute froh. Da kümmert sich jetzt einer mehr da drüben. Natürlich ist man froh, wenn da Arbeit abgenommen wird. Und ja, das kenne ich so auch. Ich bin auch froh, dass noch Leute dazugekommen sind. Bei MacPorts gibt es ein Hotel, das ein Single-Maintainer ist oder mehrere. Und dann kann man noch sagen, man ist bereit für das Open-Maintainer-Modell. Da können andere Leute selbstständig Sachen machen, wenn es um Kleinigkeiten geht. Wobei, was Kleinigkeit ist, gar nicht so 100% definiert ist. Aber da können dann Leute auch was comitten dazu. Weil, was weiß ich, ist irgendein Patch-Release rausgekommen. Patch-Level. Dann machen die selbstständig das Update. Und da arbeite ich mit Leuten dann zusammen in einer Form, die ich keine Ahnung habe. Ich habe einen GitHub-Panel von denen, wo dann sonst nichts steht. Ich weiß nicht, ist das ein Mann, ist das eine Frau? Wo kommen die her? Welche Nationalität? Wo wohnen die? Wie alt sind die? Ich weiß gar nichts. Ich sehe nur das, was die halt an Patches so reinbringen oder mal auf einer Mail-Liste schreiben, aber mehr weiß man davon nicht. Das ist schon, wenn man sich das mal überlegt, schon ein sehr zerbrechliches Gebilde, was wir da aufgebaut haben.

Stefan Bodewig Offensichtlich. Also wir hätten es wahrscheinlich vorher nicht unbedingt erwartet, dass das so ist, weil wir vertrauen erst mal darauf, dass die Leute das Beste tun wollen und das, wie du sagst, in dem Fall im Open-Maintainer-Modell gar nicht klar geregelt ist, was die Kleinigkeit ist. Wir vertrauen darauf, dass die Leute gesunden Menschenverstand walten lassen. Führt offensichtlich dazu, dass man verwundbar wird, dass man angreifbar wird für Leute, die eben nicht mit gutem Willen sind.

Stefan Bodewig Ja, das tut auch ein Stück weit weh für die Open-Source-Entwicklung grundsätzlich. Jetzt muss ich mir dreimal Gedanken machen, ob ich jemandem Schreibrechte gebe. In einem Fall, wo ich zum Co-Maintainer geworden bin, ist es ein Plugin für den Engine X, das OpenID Connect implementiert, also wo offensichtlich Security-Relevanz mit dran steckt. Ich kann dem Maintainer, dem ursprünglichen oder auch weiterhin mit Maintainer Hans da nur dankbar sein für das Vertrauen, das er mir entgegengebracht hat. Es ist fragwürdig, dass er das heute noch mal so ohne weiteres tun würde nach den Ereignissen.

Christoph Iserlohn Genau, also ein schwieriges Gebilde. Aber es gibt ja Strukturen da. Also bei mir im Projekt sind die Strukturen sehr lose dabei. Du bist aber auch bei Apache unterwegs. Apache Software Foundation. Und wir haben ja vorhin gesagt, das war nur in dem Release drin. Also die Backdoor ist ja eigentlich nur in dem Release ein Tabel drin. Und werden ja werden gesagt, das war nur ein Release drin. Also die Vektor ist ja eigentlich nur ein Release in der Tat worden. So ein ganz kleiner Teil im Source repository war so, dass man sie nicht entdecken kann, sondern in einem kaputten Archivlinus, dass ihr es irgendwie speziell gepatcht werden muss. Und das passiert ja alles außerhalb. Also wenn ich ein Release mache für ein neues Paket, dann mache ich das einfach. Das ist ja minimal zu Strukturen. Wir alle müssen einander vertrauen,

Christoph Iserlohn Nur zum ganz kleinen Teil im Source-Repository, aber so, dass man sie nicht entdecken kann, weil sie in einem kaputten Archiv drin ist, das erst irgendwie speziell gepatcht werden muss. Und das ist passiert ja alles außerhalb. Also wenn ich einen Release mache für ein neues Paket, dann mache ich das einfach. So. Keine, desjahre minimalste Strukturen. Alle müssen dann darauf vertrauen, dass ich keine bösen Absichten habe und da noch einen Patch reingebracht habe. Aber bei Patch ist das ein bisschen anders, oder? Genau. Vielleicht würde mich interessieren, hättet ihr das bemerkt, dass sich das unterscheidet von dem, was da drin ist, als ob er in den Greenies drin ist, aber bei Apache ist das ein bisschen anders. Also da kannst du vielleicht mal erzählen, wie so da so ein Release abläuft. Und vielleicht mal, würde mich interessieren, hättet ihr das bemerkt, dass, also dass sich das unterscheidet von dem, was da drin ist und also in dem Release drin ist und in dem Source Code und dann vielleicht nochmal nachgeguckt. Wie läuft das bei euch?

Stefan Bodewig Der Releaseprozess für Open-Source-Projekte ist fast der Default-Release-Prozess. Baue ich einmal lokal und veröffentliche den Krempel und da guckt nie irgendjemand anderer mit drauf, weil ich bin ja der Maintainer und das ist auch das was offensichtlich für XZutils das Default Verfahren gewesen ist. Einer von den Maintainern baut und veröffentlicht in dem Fall bei GitHub die Releases und das ist es. Bei der Apache Software Foundation ist es so, dass offizielle Releases eines Apache-Projektes erst dann entstehen, wenn nach einer Abstimmung mindestens drei Mitglieder des Project Management Committees gesagt haben, ja, das ist ein gutes Release, das wollen wir tatsächlich veröffentlichen. Es gibt auch hier keine festen Regeln, wie prüfe ich, dass ein Release tatsächlich okay ist. Es gibt ein paar Dinge, von denen ist zumindest festgelegt, dass sie passieren sollen. Also ein Release muss mit PGP signiert werden und wenn ich da abstimme, dann wird von mir schon erwartet, dass ich mindestens mal geguckt habe, ob die PGP-Signatur passt. Also ob wirklich derjenige, der das Release machen wollte, auch die entsprechenden Release-Archive, die erzeugt worden sind, erzeugt hat. Aber in den meisten Projekten ist es so, dass mindestens einer von den Leuten, die da drauf gucken, im Zweifel eher alle, das wäre so meine Hoffnung, auch reingucken in die Pakete und zumindest in die Quelltextpakete. Bei Apache gibt es eigentlich keine Binary Releases, da gibt es nur Quelltext Releases, der Rest sind Convenience Binaries und keine offiziellen Releases, da kann man jetzt Haare spalten. Bei den Binär Releases in einem Kontext, wo das wirklich eins zu eins den Quelltexten entsprechen sollte, was für die Java-Projekte beispielsweise gilt, dann lädst du das Archiv runter, packst es lokal aus und diffst es gegen dein Git Repository für das entsprechende Tag. Das tue ich auch, wenn ich für einen Release abstimme. In einem solchen Fall hätte ich gesehen, das Skript ist nicht das gleiche wie das, was wir eingecheckt haben. Das funktioniert nicht so gut bei Projekten oder in Sprachen, wie du das, glaube ich, sehr gut beschrieben hast, warum das in C-Projekten häufig nicht exakt mit dem übereinstimmt, was im Repository liegt. Da muss man anders herangehen. Eine Möglichkeit, wie man herangehen kann, ist, ich baue selber einen Release und vergleiche, ob die Skripte, die dabei rauskommen, die gleichen sind, wie die, die in diesem anderen Tarball oder ZIP-Archiv drin gewesen sind, oder man hat tatsächlich extrem viel Mühe hineingesteckt, repeatable builds hinzubekommen. Repeatable builds heißt im Endeffekt, wenn ich das Release baue und jemand anderer baut auch ein Release auf seiner eigenen Maschine, dann müsste das Ergebnis byte für byte identisch sein in beiden Fällen. Und in dem Fall brauche ich nicht mal DIVs über Quelltextbäume zu machen, sondern nur noch die Archive miteinander vergleichen. Das ist aber bei den ganz vielen Projekten nicht der Fall. Keinem der Projekte, in den ich selber bei Apache drin stecke, ist es der Fall, dass es wirklich repeatable Builds gibt, weil man dafür eine Menge tun muss, damit Builds eben aufs Byte identisch sind. Man muss dafür sorgen, dass in Archiven die richtigen Zeitstempel drin stecken und zwar So, dass sie unabhängig davon sind, auf welcher Festplatte in welcher Zeitzone ein Repository ausgecheckt worden ist, als das Ganze gebaut worden ist. Da gibt es ganz viele komplizierte Dinge, über die man nachdenken muss. Aber repeatable builds ist sicherlich was, was Ich weiß, dass die Tomcat Community Repeatable Builds baut und dort wird es dann auch einfacher zu sehen. Ist das wirklich das, was lokal auf meiner Maschine auch passieren würde? Wir haben hier also zum einen ein zwingendes mehr Augensystem, wenn man so will. Also mindestens mal drei Leute, die gesagt haben, ja das ist okay. Und nur einer davon kann derjenige gewesen sein, der versucht hat, ein Release mit irgendeiner Hintertür zu veröffentlichen. Und hoffentlich Prozesse, dass Leute nicht einfach nur Blanko plus 1 Mails schicken, sondern auch reingucken, ob das Ganze passt. Und insofern hätte ich die Hoffnung, dass in den Apache-Projekten, die ich kenne, bei denen ich beobachtet habe, wie Release-Prozesse stattfinden, das aufgefallen wäre und bemerkt worden wäre.

Christoph Iserlohn Okay, das hört sich schon mal ganz gut an. Da habe ich direkt eine Anschlussfrage, aber was passiert denn jetzt in so einem Fall, wenn sowas entdeckt wird? Also es hört sich nach total viel Arbeit an und jetzt müsst ihr so eine Art Emergency Release rausbringen, weil sowas aufgefallen ist, weil ihr das vielleicht in Abhängigkeit auf so ein Projekt habt und das bei euch irgendwie mit drin ist. Kann man sich ja vorstellen, dass sowas wäre.

Stefan Bodewig Dann kann das ja nicht Tage, wochendauernd ist alle Leute in ihr OK gegeben. Dann kann das ja nicht Tage oder Wochen dauern, bis alle Leute ihr Okay gegeben haben. Also vielleicht kann es, ich weiß es nicht. Aber das wäre ja ungünstig, wenn dann alle Leute ihr Okay geben müssten und dafür eine Woche brauchen und das dann nicht gefixt wird. Gibt es da irgendein Verfahren, was dann offiziell angewendet wird? Oder macht man mal dann die Ausnahme von dem, was ihr tut?

Stefan Bodewig Es gibt ein Standard-Zeitfenster für die Abstimmung, die eigentlich für die komplette ESF geltenden Regeln sind. So eine Abstimmung dauert 72 Stunden und du brauchst drei Menschen, die plus eins gesagt haben, also römische Abstimmung plus und minus eins. Daumen hoch oder Daumen runter. Und mehr Leute, die plus eins als minus eins gesagt haben, das kommt noch dazu, also drei plus eins reichen nicht. Und tatsächlich wird dieser Prozess in dieser Form zumindest in gewissem Umfang eingehalten, auch in irgendwelchen Emergency Releases. Tatsächlich, ich habe bei dem einen oder anderen CVE, bin ich beteiligt gewesen, auch als Release Manager in Apache Ant und bei Commons Compress. Es gibt private Mailing-Listen, unter denen man sich schon mal austauscht und sagt, hier gibt es das. Also ohnehin, die Sicherheitslücke wird in der Regel nicht öffentlich bekannt gemacht. Bei so einem Fall, wo ich Abhängigkeiten habe und die Sicherheitslücke schon bekannt war, ist es natürlich schwieriger. Aber nehmen wir erstmal den einfacheren Fall, vielleicht jemand hat eine Sicherheitslücke in meinem Code gefunden. Und die Welt weiß noch nicht, dass die Sicherheitslücke da ist, dann können wir das Release schon mal vorbereiten und im privaten Kreise schon mal darüber abgestimmt haben, sodass im Endeffekt auch die drei Tage viel früher loslaufen, als dass der öffentliche Release-Voting-Prozess startet, weil in dem Moment, wo ein Release-Vote startet, gucken vielleicht noch mehr Leute drauf und irgendjemand sieht, dass du irgendwas geändert hast, was nicht in den Release Notes offensichtlich drin steht, also den vorläufigen Release Notes. Und damit könnten Informationen zu der Sicherheitslücke unabsichtlich herauskommen. Was man dann macht, ist man kürzt auch die Abstimmung ab. Sobald die dritte plus eins angekommen ist, sagt man okay fertig und dann geht das Release raus und dann veröffentlichen wir auch warum das ganze schneller passiert ist. In so einem Fall, wo man Abhängigkeiten aktualisieren muss, dann dauert es halt, solange bis 3 plus 1 da sind. Also da wird man dann auch eher abkürzen, nur ist es hier eben so, dass man weniger Zeit hat, weil das Wissen um die Sicherheitslücke schon öffentlich ist.

Christoph Iserlohn Ja, also das stelle ich mir auch einfach vor, in Anführungszeichen einfach, wenn man so sagt, es ist vorher bekannt und dann sind die drei plus eins wahrscheinlich, weil schon so viel auf der privaten Mailing-Liste passiert ist oder welche Kommunikationskanäle, nicht öffentliche Kommunikationskanäle ihr auch nutzt. Ja, schon alles abgestimmt ist und dann kommt ja nur der Formal und dann können wahrscheinlich innerhalb, wenn die Abstimmung losgeht, wahrscheinlich innerhalb einer Minute alle plus eins sagen, weil alle das schon vorher Bescheid wissen.

Stefan Bodewig Wenn alle genug sind und nah genug bei Zeit so zusammenleben.

Christoph Iserlohn Ja ja, ich sag’s nur im Idealfall. Aber dann geht das ja ganz einfach. Aber ich stelle mir jetzt sowas vor. Auch gar nicht so Abhängigkeit, aber dann tritt was auf. Also das ist ja auch üblich in anderen Open-Source-Projekten. Dieses Open bezieht sich ja oft nicht auf den Security-Prozess. Wenn man Sicherheitslücken gemeldet kriegt, dann macht man ja meistens auch aus, wie geht man damit um. Die meisten wollen ja sagen, okay, die jeweiligen Sicherheitsforscherinnen, die das gemeldet haben, die wollen ja auch immer gerne sagen, ich möchte das veröffentlichen, ein bisschen Fame, damit ihr Marktwerk steigert. Meistens ist ja auch okay. Das sogenannte Prinzip Responsible Disclosure, die melden das. Man hat ein bisschen Zeit das zu fixen und zu releasen und danach kann der oder die Sicherheitsforscherin das dann auch veröffentlichen. Das erkennt man ja. Aber ich stelle mir jetzt so etwas vor, das kommt dann raus, weil irgend einer das ausgenutzt hat. Also es wurde schon beobachtet. Ich glaube bei Log4Shell war das ja so, dass man gesehen hat, dass diese Lücke ausgenutzt wurde auf irgendwelchen Minecraft-Servern oder so.

Dann ist die Lücke bekannt. Und was vielleicht auch schon, wie sie auszunutzen ist. Und es gibt keinen Melder in der Form, wo man dann noch ausmacht, wir brauchen jetzt eine Responsible Disclosure. Was passiert dann? Könnte man dann so noch schneller das irgendwie beschleunigen? Weil dann gibt’s ja diese private Kommunikation vorher gar nicht. Wo man sagen kann, wir haben uns schon abgestimmt.

Stefan Bodewig Also im Kontext der Apache Software Foundation gibt es auch einen wohl definierten Prozess, wie mit Security-Inzidenz umgegangen wird, wie man das eigentlich tun würde, wenn sowas wie Responsible Disclosure genutzt wird, wo eben auch ganz klar viele Handreichungen durch Leute, die im Security-Team der Apache Software Foundation sitzen, gegebenenfalls sind Leute, deren Job das ist, sich auch um Security zu kümmern, also ihr Job außerhalb der Apache Software Foundation, die einfach ihre Expertise hier einbringen und den nutzt du und der ist wirklich gut definiert und man weiß, was man tun soll. Im Kontext von Log4Shell war das glaube ich so, dass wir ja nicht nur von einer Sicherheitslücke reden, sondern ja mehreren, die hintereinander weg in kurzer Zeit gefunden worden sind, weil Sicherheitsforscher nach der ersten Lücke mal richtig reingeguckt haben und noch ein paar andere gefunden hat und bei der ein oder anderen davon ist es so gewesen, dass irgendjemand bei Twitter veröffentlichen musste, dass er gerade eine Sicherheitslücke gemeldet hat und im Prinzip dabei geleakt hat, wie man die Sicherheitslücke ausnutzt und solche Dinge gibt es auch immer wieder. Es sind auch nur Menschen, die Fehler machen oder Idioten, wie auch immer das gerade in dem Fall gewesen sein mag, kann ich gar nicht so genau beurteilen. Auch da ist formal der Prozess eingehalten worden. Also es wird weiterhin abgestimmt und sobald du drei Leute zusammen hast, geht’s. Und dass es gerade Weihnachten war, glaube ich, hat auch nicht unbedingt geholfen bei Log4Shell. Aber auch da wird nicht davon abgesehen, dass wir mehr Augen als nur die des einen Release-Managers haben wollen, um ein Release rauszugeben. Da geht dann auch Gründlichkeit über Schnelligkeit an der Stelle. Also vielleicht die positive Seite dessen, ich habe vor Jahren öfter mal in Open Source Communities gehört, dass die Apache Software Foundation so träge und langsam ist und dass es alles überhaupt keinen Spaß macht, da Dinge zu tun, weil es da so viele Regeln gibt. Es gibt eben auch Dinge, in denen es total super regeln zu haben und nicht immer alles ganz schnell zu machen.

Christoph Iserlohn Ja, interessant. Kann ich anschließen, wie sind denn die Regeln bei MacPorts? Eine der wenigen Bereiche ist Security. Da gibt es auch eine private Kommunikationskanäle für solche Sachen. Aber dass es keinen Release Prozess gibt, gibt es sowas wie einen Maintainer Override bei Sicherheitslücken. Ich könnte jetzt, wenn der Maintainer von einem anderen Paket nicht reagiert, den Patch einspielen oder das Update machen dafür, ohne dass ich irgendwie eine Zustimmung bräuchte. Das kann bei uns jeder machen für solche Sachen. Das ist natürlich ein Risiko bewirkt, dass man damit was einschmuggelt, aber sowas fällt dann relativ schnell auf. Also wenn jemand committet für ein Paket von jemand anders, das fällt dann auf. Da gucken die Leute normalerweise dann auch rein, okay, was ist denn da passiert? Und passiert eigentlich nur bei, wenn Sicherheitslücken sind, dann geht’s. Und vielleicht das zweite, was da interessant ist, ist ja so ein bisschen Eigenwerbung, wo man manchmal auch Package Manager benutzen sollte. Wenn jetzt sowas wie bei Log4Shell passiert, dass kein Release rauskommt, wir als Downstream-Maintainer können ja selber Patches einspielen oder Dinge patchen und das releasen mit einem Patch, der diese Sicherheitslücke schließt, bevor überhaupt ein Upstream-Release gibt. Und ich meine, das Package Manager, das OpenSSH jetzt auch XZ benutzt hat, war ja auch von den Distributionen, was reingepatcht ist und nicht im Standard. Also da können, und das passiert sogar relativ häufig, dass Security Patches in den Downstream schon schneller drin sind, mit einem Patch-Version, wo nur dieses Lücke gemacht wird und gar kein neues Release, sondern nur eine Lücke, die aufgetaucht ist, gepatcht wird, als eigentlich im Upstream, wenn da ein Release-Prozess ist. Weil er vielleicht ein bisschen gründlicher ist, wie bei Apache, oder weil bei manchen Projekten manchmal so Einzelgänger oder was heißt Einzelgänger, aber Projekte, die nicht viele Elemente haben, die sind dann vielleicht auch nicht erreichbar. Also ist Urlaub, ist Wochenende und dann taucht was auf und die Leute gucken da gar nicht rein. Das kann ja durchaus passieren. Ich weiß von Fällen, wo das so passiert ist. Wo dann da erst mal nichts passiert und Leute dann irgendwie nach zwei Wochen sich melden, oh, ich war offline. Ich habe digital Detox gemacht in meinem Urlaub und dann ja, ganz verwundert sind, was alles passiert ist. Ja, natürlich, natürlich. Genau. Genau, an der Stelle ist es manchmal ganz gut, wenn man Package Manager benutzt.

Stefan Bodewig Was bei Single-Maintainer-Projekten natürlich umso häufiger passieren dürfte, die eben Single Point of Failure oder Single Point of Absence in dem Fall wären.

Stefan Bodewig Ich weiß nicht, Mac-Ports ist möglicherweise auf der Liste derer, die man dann informieren würde auch mit drauf. Es ist durchaus nicht unüblich, wenn du an einem Patch arbeitest im Kontext von einem Apache Projekt, dass du auch die Maintainer von anderen Projekten schon mal kontaktierst und denen sagst, hier kommt jetzt was. Und vielleicht sogar den Patch mit denen schon teilst und dass das eben auch an downstream Distributoren geht. Auch natürlich um ein abgestimmtes Release zu haben, da ist die Koordination sowieso wichtig und notwendig, dass eben nicht in dem Moment wo ich sage hier gibt es mein neues Foo XYZ Release alle Leute die Distributionen und Paketmanager nutzen, darauf warten müssen, dass diese neue Release da ist und dass das irgendwie klar ist. Das kann auch möglichst zeitnah in den Distributionen mitgenutzt werden.

Christoph Iserlohn Also solche Koordinationen gibt es tagtäglich. Ich bin nicht in dem, also das ist bei uns natürlich auch nur ein eingeschränkter Kreis auf Zugriff haben. Also wenn du 80 Leute in das schickst, dann liegt das wahrscheinlich auch viel schneller als das Liebes. Das ist ein kleiner Kreis, ich bin nicht dabei, aber das gibt’s, also das haben wir, dass sich, da sind, das ist bei uns natürlich auch ein eingeschränkter Kreis. Ich weiß nicht, wie diese Liste heißt, die du da gerade erwähnt hast, aber da sind halt einen Personenkreis von allen möglichen Linux-Distributionen drauf und MacPorts und ich glaube Boo, also der andere Package Manager für den Mac und wahrscheinlich sowas wie Nix, so übergreifende oder Chocolate auf Windows und ähnliche, die die Pakete bereitstellen und jetzt wo es nicht nur noch reinere Hobby-Projekte sind oder die schon lange bestehen, dass sich da sich koordiniert wird. Wenn man die Software, die von allen wirklich nur genutzt wird, überall nochmal paketiert wird in einer extra Form. Ja, das stimmt. Und das ist auch ganz gut so. Der eine, der ist in dem Patch, jeder weiß, wie die Lücke wahrscheinlich auszunutzen ist und alle anderen müssen dann im Blut, Schweiß und Tränen schnell hinterherziehen, eigene Releases zu bauen. Das funktioniert nicht. Ja, ganz interessanter Einblick. Was lernen wir jetzt daraus? Was sollen denn die Konsequenzen davon sein, dass wir das jetzt entdeckt haben? Ich stelle mir das so vor, da gab es ganz viele Konsequenzen in Sachen, wir hatten einen Log4Schell erwähnt, da gab es ganz viele Konsequenzen in Sachen, was alles in der Supply Chain zu tun ist. Jetzt haben wir alle Tools installiert, die uns warnen, wenn eine unserer Dependencies vielleicht eine bekannte Sicherheitswirkung hat und vielleicht ein Bild kaputtmacht. Du hast gerade erwähnt, die Releases sollten signiert sein, vielleicht. Und es gibt ja auch dieses Salsa-Framework, was sozusagen diese ganze Kette von vorne bis hinten betrachtet. Da wird auch ganz viel mit Signaturen gearbeitet. Da ist schon einiges passiert. Was muss denn jetzt noch passieren, weil ich sage mal so, Tools hätten das nicht entdeckt, keine statischen Code Scanner nicht oder so, egal was jetzt gesagt wird.

Stefan Bodewig Offensichtlich nicht.

Christoph Iserlohn Also jetzt erkennen die Leute das wahrscheinlich, weil sie ihr Tool speziell dafür ausrüsten können für sowas. Aber auch nur genau das. Also Tools hätten sie nicht entdeckt. Eine Signatur für das Tarbol hätte auch nichts genutzt. Der Jin Tan, ich weiß gar nicht, ob es sogar signiert war. Das ist sogar signiert, weil er hat eine Big Bang.

Stefan Bodewig Das ist sogar mit Dias Schlüssel signiert, was auch immer der Schlüssel ist.

Christoph Iserlohn Genau. Also diese ganzen Maßnahmen, die da so drin sind, soweit ich die jetzt überblicke, hätten gesagt, da hätte überhaupt nichts genutzt.

Stefan Bodewig Ich glaube, das trifft für vieles zu, was man sich jetzt gerade überlegen kann. Also ich habe auch immer wieder gelesen, dass man müsse die Open Source Maintainer nur bezahlen und dann würde sowas nicht mehr passieren. Ich denke, in dem Kontext müssten wir uns die Frage stellen, hätte das irgendwas geändert? Wenn jemand der sagt, ich bin gerade aus irgendwelchen Gründen gar nicht in der Lage, Maintainer zu sein, wenn wir dem Geld gegeben hätten, dann wäre es ja auch nicht, wäre dadurch möglicherweise gar nicht besser in der Lage gewesen zu maintain, wenn es gesundheitliche Gründe sind beispielsweise.

Christoph Iserlohn Ich glaube, es will auch gar nicht jeder Geld dafür bekommen. Du hast gesagt, du hast das als Hobby gemacht. Ich mache solche Dinge auch als Hobby. Ich will dafür gar nicht bezahlt werden und eine Verantwortung dafür bekommen.

Stefan Bodewig Ne, das geht mir ganz genauso. Und hinzu kommt eben, dass ein weiterer Aspekt, der da heißt, gut bei sowas wie XZutils, das ist eigentlich fertig. So hin und wieder kann man noch irgendwo eine Kleinigkeit oder es gibt mal einen Bug-Fix, den man machen möchte. Und auch bei vielen, vielen anderen von diesen alten Projekten, auf denen ganz viele Abhängigkeiten aufbauen. Da muss gar nichts getan werden. Also da ist Maintenance nichts, was wirklich einen Vollzeitjob ausfüllen könnte. Und die Frage, warum sollte man, für was würde man die Leute bezahlen? Ich habe überhaupt nichts dagegen, Leute zu bezahlen. Das will ich überhaupt nicht sagen. Ganz im Gegenteil. Ich kann auch jeden verstehen, der als Open-Source-Entwickler gerne auch finanziell entlohnt werden möchte für das, was er da tut. Mein Antrieb ist es nicht. Deshalb mache ich nicht Open Source. Aber ich glaube, es würde das Problem auch nicht lösen. Also zumindest nicht in allen Projekten und in diesem konkreten Fall. Genauso wenig wie im Fall von Log4Shell vor drei Jahren oder wann es gewesen ist. Ich glaube, dass das einen Unterschied gemacht hätte, weil die Leute, die daran arbeiten, alle ihnen Lohn und Brot stehen dafür, dass sie Software entwickeln. Nur vielleicht nicht unbedingt Log4J.

Christoph Iserlohn Ja, ich weiß es gar nicht. Ob das damals was genutzt hätte, weil… Ach so, es gibt ja verschiedene Ursachen. Bei Log4Shell könnte man jetzt zynisch sagen, das ist der Feature Creep. Also warum ist da ein Interpreter drin? War die Ursache und gar nicht, dass die vielleicht keine Zeit hatten oder nicht. Also auch wenn sie dafür bezahlt werden, wäre vielleicht dieses Feature trotzdem drin gewesen, weil irgendjemand das mal gebraucht hat. Genauso kann man mit Geld wahrscheinlich nicht verhindern, dass sich jemand das Vertrauen erschleicht. Also wenn die Personen, die jetzt dahinter stehen, haben ja auch … … scheinbar, so wie ich das überblickt habe, auch erst gute Patches beigetragen.

Stefan Bodewig Richtig. Völlig valide Patches über einen Zeitraum von Jahren.

Christoph Iserlohn Ja, also von daher dann nützt es auch nicht, wenn ich dafür bezahlt wäre und vielleicht keine psychischen Probleme habe und mich viel darum kümmern kann, dass ich nicht trotzdem andere Personen, die gut mitarbeiten, mich auch einlade dazu. Also da müssen wir das Open Source System ja schon irgendwie so diesem ursprünglichen Geist beraubender, dass alle mitarbeiten können. Das wäre dann, weiß nicht, das ist dann vielleicht so, es gibt ja manche Leute, die sagen, die machen das Open Source, aber Patches sind nicht willkommen. Habe ich schon öfter mal jetzt gesehen.

Stefan Bodewig Das ist dann source available oder sowas.

Christoph Iserlohn Ja, es ist trotzdem gar nicht genau eine andere Lizenz oder so. Sie könnten das machen. Aber der Maintainer, die Maintainer nimmt nichts an. Und zwar auch Selbstschutz. Andere sagen, ich kann das einfach nicht. Als einzelne Person. Das Handeln oder sonst was. Oder ich will die Verantwortung nicht. Und ich entwickle das so für mich. Und Patches nehme ich auch gar nicht erst an. Schreibt das große drüber. Wer es nehmen will, kann es nehmen. Das ist eine Open Source Lizenz. Ihr könnt es forken. Und vielleicht das anders aufziehen, aber sowas gibt’s ja. Weiß ich gar nicht. Wie man dieses, ich erschleiche mir Vertrauen überhaupt hätte verhindern können.

Stefan Bodewig Genau, ich bin ähnlich ratlos wie du. Ich möchte auch gar nicht davon ablassen, den Menschen zu vertrauen, die Patches bei meinen Projekten einliefern. Ich möchte nicht bei jedem Pull-Request darüber nachdenken, ob das jemand sein könnte, der gerade einen Social-Engineering-Angriff auf mich vorbereitet und in x Jahren dann, wenn er mein Vertrauen genug gewonnen hat, ausnutzt, um irgendwas Böses zu tun. Deshalb mache ich das nicht. Dann würde ich aufhören wollen Open Source zu entwickeln, wenn ich mit einem solchen Gedanken daran gehen würde.

Christoph Iserlohn Ist dann vielleicht, dass diese Einstellung, mit der du da drangegangen bist, mit der ich auch da drangegangen bin und mit der ganz viele Leute wahrscheinlich auch noch da drangehen, ist uns das alles entwachsen, ist das so groß geworden? Also wenn wir sagen, wir sind Hobbyleute und freuen uns, wenn andere das damit tun und heutzutage läuft die komplette digitale Welt auf solchen Säulen. Da gibt es ja den schönen XKCD-Comic, wo das riesige Schloss da drauf gebaut wird aus Klötzen und irgendwo ist so ein ganz kleines unstabiles Teil, wo dann dransteht hier von einsamen Maintainern in, ich weiß nicht wo seit Jahren für kein Geld und keinen Dank schon wird das betreut oder so. Sinngemäß verlinken wir glaube ich in den Show Notes, das ist ganz witzig. Dass das uns einfach zu groß geworden ist das ganze System, dass das uns aus unseren Hobbyhänden entwachsen ist oder

Stefan Bodewig Da bin ich mir gar nicht sicher. Ich weiß es tatsächlich nicht. Ich habe keine echte Antwort darauf. Das, was ich dir sagen kann, ist, dass sich Open Source aus Sicht des Maintainers heute völlig anders anfühlt als vor 20 Jahren. Alleine deshalb, weil die Verbreitung von Dingen, die auf dem Aufbauen, was du da gemacht hast, so viel größer geworden ist, als das früher war. Vor 20 Jahren waren meine User in Anführungsstrichen Leute, die selber in der Lage gewesen wären, einen Patch zu liefern, wenn sie einen Fehler finden und die haben das dann auch getan. Die haben gesagt, ich habe hier einen Bug gefunden und damit kannst du den fixen. Heute bekomme ich ein Ticket, das sagt, ich habe hier einen Fehler und schon beim Versuch überhaupt mit den Leuten in die Kommunikation zu kommen, was muss ich denn tun, um den Fehler zu reproduzieren? Scheitert es häufig, weil es demjenigen, der den Fehler öffnet, zu viel Arbeit ist, zu kooperieren beim Fixen des Fehlers. Also da ist es glaube ich so, dass ich auch die Erwartungshaltung an Open Source Maintainer deutlich verändert hat, was sich auch ein Stück weit in diesem Begriff der Supply Chain widerspiegelt, weil die Lieferkette impliziert für mich eigentlich, dass ich einen Lieferanten habe, den ich dafür entlohne, dass er mir was liefert und das ist genau nicht das, was bei den Open Source Projekten passiert, sondern wir bauen einfach auf der Arbeit anderer Leute auf. Die die aber vollkommen altruistisch zum Teil einfach nur so geleistet haben und die nie versprochen haben, dass sie das weiter maintainen werden. Und ich habe keine Antwort. Ich kann nur sagen, es fühlt sich ohnehin irgendwie anders an als es mal war. Nostalgie. Leider tut mir leid.

Christoph Iserlohn Ja, stimmt. Ich kann das voll nachvollziehen. Ich habe so einen Wandel auch mitbekommen. Also die Ansprüche der Leute ist anders. Und das, wo ich sehr zwiespältig bin, man will es den Leuten auch einfach machen, zu partizipieren. Also nimmt man Tools, die leicht zugänglich sind. Ich denke daran, dass bei uns, dass wir auf GitHub gewechselt sind aus unseren eigenen hostigen Lösungen mit Shrek. Das vielleicht noch kennt, so ein integriertes Bug Tracker, Source Code Verwaltungssystem, jetzt keine Usability-Freude oder so. Aber man merkt, desto zugänglicher das System ist wie bei GitHub, desto mehr kriegt man, also desto mehr Noise wird erzeugt mit Leuten, die dann Ticketstellen, Bugs aufmachen und so und nicht bereit sind zu kommunizieren, während man das bei dem Tool, was nicht zugänglich war, dann auch Leute, die sich dadurch gearbeitet haben, dann auch Leute waren, ja und ich kann dir auch schon mal, hier sind die Schritte zum Reproduzieren oder ich habe sogar einen Patch dafür geschrieben. Weil die Hürde so hoch ist, dass Leute, die da auf Tiefe eintauchen können, dann auch nur solche Tools nutzen. Und wenn man zugänglich macht, was eigentlich schön ist, dass man sagt, wir öffnen das für mehr, die beitragen können, desto mehr neues kommt rein. Also so ist meine Beobachtung jetzt für, besonders in dem Fall, wo wir von Track auf Github gewechselt sind, dass das so ein bisschen passiert ist. Früher waren Dinge auch umständlich. Vor 20 Jahren oder so, da war das wahrscheinlich auch alles nicht so zugänglich. Ich weiß ja, dass der Apache-Projekte auch zum Teil auf Github sind. Oder mindestens in Github, wo auch Bugs oder Tickets reinkommen, auch wenn es nicht der offizielle Werk ist. Aber die dann ja auch wahrgenommen werden.

Stefan Bodewig Nein, natürlich nicht. Das ist ja auch alles gut und richtig. Also es ist ja um Gottes Willen vor 20 Jahren waren wir glaube ich noch bei CVS. Für viele Leute ist Git ja schon schwierig zu bedienen, also zumindest außerhalb von grafischen Benutzeroberflächen ist. Wobei, wahrscheinlich ist CVS damals einfacher zu bedienen gewesen, als sie gibt. Kommandozeile heute, streichen wir das. Bei CVS gibt es kein Sperren. Doch, doch, es gibt es schon. Auch, aber der Default war das nicht zu tun. Aber ja.

Christoph Iserlohn Aber nur bis die Datei gesperrt war und keiner sie mehr entlocken konnte. Ach so, welches war das? Doch CVS war es schon. Okay. Ja.

Stefan Bodewig Aber wir kommen auf Themen, die gerade eher in alte Männer unterhalten, sich hineinläuft oder so. Ich bin mir nicht ganz sicher. Nein, grundsätzlich, um zurückzukommen, ich glaube, dass viel von den Strukturen, die wir haben, dazu führt, dass wir in ganz viel Software Abhängigkeiten haben, die sich darauf verlassen, dass irgendjemand sich um das Ding kümmert, von dem ich da abhängig bin. Aber die Leute wissen nicht mal, dass du davon abhängig bist. Jemand, der eine Bibliothek bei GitHub zur Verfügung stellt, erfährt im Zweifel nie, welche anderen Bibliotheken denn diese benutzen oder welche anderen Software-Produkte das mitnutzen. Das XML-Unit habe ich eben als Beispiel angeführt, dass das in Spring Boot Testing drin ist. Weiß ich auch eher zufällig, als dass jemand mal zu mir gekommen wäre und gesagt hätte, wir schließen das da jetzt mit ein. Hin und wieder bekomme ich das mal mit, dass jemand sagt, oh, könntest du jetzt den Patch noch machen und Release machen, dann kommt das noch in das nächste Spring Release mit rein. Also auch so ein Druck, den ich nicht als Druck empfinde an der Stelle, zumal die Leute auch mit einem Nein umgehen können. Aber auch das ist eben durchaus normal, dass jemand sagt, okay, diesen Fix, den brauche ich jetzt aber, könntest du da mal ein neues Release machen? Und so habe ich damals eben auch die Diskussion auf der XZ Mailing Liste, ohne in die Texte reingeguckt zu haben, wirklich tiefer empfunden.

Christoph Iserlohn Genau, also manchmal erfährt man das ja auch erst, weil man woanders was kaputt gemacht hat und dann sich Leute melden und dann erfährt man, ja, ihr habt auch die Abhängigkeit. Ja, zum Abschluss hätte ich noch eine Frage über eine Idee, also deine Meinung zu dieser Idee. Du hast so erwähnt, und das ist ja auch so, dass ganz viele Projekte sozusagen ausentwickelt sind und wenig Pflege bedürfen, aber gut, muss sie vielleicht an neuere Technologien anpassen, an Betriebssystem-Updates, an Hardware-Updates. Vielleicht wird auch nochmal eine Sicherheitslücke gefunden, also muss jetzt keine Backdoor sein, sondern es kann ja auch eine normale Sicherheitslücke sein, aber sonst die brauchen eigentlich keine Vollzeit-Maintenance mehr. Und dass man Leute dafür eigentlich gar nicht bezahlen kann, was sollen die denn tun? Der eine oder andere mag das reizen, wenn man Vollzeit bezahlt würde, um eigentlich wenigstens zu tun hat und vielleicht seine anderen Hobbys mitnehmen kann, aber das ist ja jetzt kein Modell, was tragen würde. Aber was ich schon mal in verschiedenen Formen gehört habe, ob man nicht solche Sachen zusammennehmen kann und versuchen ihnen dann das, die in einen Satz wie so bei der Apache Software Foundation oder einer Institution zu stellen. Und da gibt es bezahlte Maintainer und die müssen sich dann halt um mehrere Projekte kümmern. Also wenn genügend da ist, ist halt auch immer was zu tun und die kann man dann bezahlen und die tragen dann sozusagen die, angelehnt an den Bergbau, die Ewigkeitskosten, die so entstanden sind durch das Open Source System, dass man sagt, wir haben jetzt was und das ist dann ein regulärer Job, da können sich auch Leute dann drauf vielleicht auch bewerben, die Bock auf sowas haben und nicht, wir bürden das irgendein Maintainer auf, diese Kosten, die ja sozusagen dadurch entstehen, dass diese Softwareprojekte sind, und die kosten auch noch, haben ja die anderen noch nicht mal eher, und er müsste die übernehmen, sondern dass man das sozusagen sagt, okay, wir versuchen das auf eine Basis zu stellen, die so ein bisschen, naja, zwar auch gemeinnützig ist, aber wo dann auch nicht so was passiert, wir haben nur noch einen Maintainer, und wenn er im Urlaub ist, oder dass es keinen Bock mehr auf das Projekt ist, ist alles weg, sondern für so kritische Sachen, das muss jetzt nicht jedes Softwareprojekt, was jemals auf GitHub gestellt sein, aber sowas gibt ja ganz viel kleine kritische Software, die seit Ewigkeiten existiert, die man braucht, dass man sowas vielleicht mal sammeln könnte unter einem Dach

Stefan Bodewig Hat natürlich auch einen gewissen anderen psychologischen effekt noch für den maintainer den bisherigen sozusagen Nehmt ihr da jemand was weg? Das, was ich bisher maintained habe und ich war der Meinung, ich mach das gut. Jetzt, wenn irgendjemand an mich herantritt und sagt, sollen wir da deine Bibliothek nicht mit in diese XYZ Foundation nehmen, die dafür dann andere Leute bezahlt, um Maintenance zu übernehmen für das Ding, weil du kümmerst dich ja offensichtlich nicht mehr, subtile, der Subtext, den man dann irgendwo mitbekommt, wenn das passiert. Da könnte ich mir vorstellen, dass das schwierig wird, da muss man eben aufpassen, wie das in der Kommunikation funktioniert.

Christoph Iserlohn Ja, da hast du recht. Das ist natürlich wahrscheinlich ein Problem, weil man weiß ja bei vielen jetzt auch nicht wirklich den Status. Also jetzt in dem Fall wäre er vielleicht froh gewesen und gesagt, ja, ich habe psychische Probleme gerade und kann das auch gar nicht alles. Und ich bin froh, dass er so eine Last von mir fällt. Und andererseits kann man genauso sehen, ja, wieso wollt ihr mir das wegnehmen? Ich mache das alles gut und ich habe überhaupt keine Probleme. Man kennt die Leute ja wahrscheinlich dann auch immer, wenn man die anspricht. Ja, genau.

Stefan Bodewig In der Regel nicht, nein. Woher auch?

Christoph Iserlohn Ja, also eigentlich haben wir keine gute Lösung, die wir da auspacken können.

Stefan Bodewig Ich bestimmt nicht, nein.

Christoph Iserlohn Ja, so ist das. Aber trotzdem, es war mir große Freude, mit dir darüber zu sprechen. Auch über deine ganzen Erfahrungen. Auch jetzt am Schluss noch ein bisschen in Nostalgie schwelgen, wie früher alles besser war. Vielen Dank, Stefan. Vielen Dank auch an die Zuhörer und Zuhörerinnen, die es jetzt so lange mit uns ausgehalten haben.

Wenn ihr noch Bemerkungen oder Ideen habt, dann schreibt uns das gerne. Genauso wie auch Feedback allgemein zu unseren Podcasts. Das könnt ihr an security-podcast.innoq.com schreiben. Das ist auch nochmal dann in den Show Notes verlinkt, die Adresse. Da verlinken wir euch auch ganz viele Informationen über die Backdoor selbst, was wir jetzt nicht auf der Tonspur so gut erklären können. Also Blogposts und Artikel über die technischen Details, die bis jetzt bekannt sind. Und auch so eine Zeitleiste, wo man dann auch die ganzen Nachrichten nachlesen kann, also den Verlauf mit den Nachrichten und den Commits und Patches, die da alle passiert sind. Das verlinken wir euch alles in den Show Notes. Da können die technisch oder auch anderweitig Interessierten dann gerne nochmal nachschauen. Und dann würde ich sagen, es ist genug für heute. Wir sind jetzt auch schon über anderthalb Stunden dran. Vielen Dank, Stefan. Bis bald.

Stefan Bodewig Vielen Dank.