Das xz-Backdoor-Problem als Mikrokosmos der Interaktionen in Open-Source-Projekten

• Es gibt zwar viele Analysen zur xz/liblzma-Sicherheitslücke, aber die meisten neigen dazu, die erste Phase des Angriffs zu überspringen
  • Der ursprüngliche Maintainer war ausgebrannt, und nur der Angreifer bot Hilfe an (dadurch erbte der Angreifer das Vertrauen, das der ursprüngliche Maintainer aufgebaut hatte).
• Im Archiv der E-Mail-Threads wird genau dieser Moment der Phase 0 eingefangen

Burnout des Maintainers und das Auftreten des Angreifers

• An den Maintainer wird eine Anfrage gestellt, die vernünftig erscheint

  • "Wird XZ for Java noch gewartet? Ich habe vor einer Woche eine Frage gestellt, aber keine Antwort erhalten."

• Diese Frage bringt den Maintainer dazu, ein "Versagen" einzugestehen
  • Tatsächlich schuldete der Maintainer niemandem etwas und hatte auch nicht versagt, aber es fühlte sich so an
  • Denn die "Community" zu enttäuschen, ist etwas Schreckliches
• Der Maintainer räumt ein, dass er "im Rückstand" ist, und sendet damit ein Signal, dass er Hilfe gebrauchen könnte
• In diesem Thread kommt jedoch keine Hilfe, stattdessen stellt sich der Angreifer von xz/liblzma als jemand vor, der ihm geholfen hat

  • "Jia Tan (der Angreifer in diesem Fall) hat mir geholfen ... und könnte künftig eine größere Rolle übernehmen ... meine Ressourcen sind zu begrenzt, daher ist klar, dass sich langfristig etwas ändern muss."

• Der Maintainer erwähnt, dass seine Ressourcen begrenzt sind und langfristig Veränderungen nötig sein werden

Das Auftreten eines unkooperativen Nutzers

• Ein unkooperativer Nutzer äußert sich kritisch gegenüber dem Maintainer

  • "Bis es einen neuen Maintainer gibt, wird es wohl keine Fortschritte geben. ... Der aktuelle Betreuer hat das Interesse verloren oder kümmert sich nicht mehr um die Wartung. Es ist traurig, ein solches Repository zu sehen."

• Der Maintainer verteidigt sich damit, dass er das Interesse nicht verloren habe, seine Fähigkeit zur Betreuung aber unter anderem durch psychische Gesundheitsprobleme eingeschränkt sei
• Der Maintainer erinnert außerdem daran, dass es sich um ein unbezahltes Hobbyprojekt handelt

Steigende Anforderungen

• Eine Woche später taucht der unkooperative Nutzer erneut auf und macht dem Maintainer Vorwürfe.

  • "Sie ignorieren zahlreiche Patches, die auf dieser Mailingliste langsam vor sich hin verrotten."

  • "Es tut mir leid wegen der psychischen Gesundheitsprobleme, aber es ist wichtig, die eigenen Grenzen zu erkennen. Ich weiß, dass dieses Projekt für alle Mitwirkenden ein Hobbyprojekt ist, aber die Community will mehr."

• Der Anfragende macht zwar Vorschläge, bietet aber keine tatsächliche Hilfe an

  • "Wie wäre es, die Maintainer-Rechte für XZ for C abzugeben, damit Sie sich stärker auf XZ for Java konzentrieren können? Oder XZ for Java an jemand anderen zu übergeben, damit Sie sich auf XZ for C konzentrieren können? Wenn Sie versuchen, beides zu pflegen, wird am Ende vielleicht keines von beiden gut gepflegt."

• Der Maintainer erklärt, dass es nicht einfach sei, einen neuen Co-Maintainer zu finden oder das Projekt vollständig zu übergeben

Die Realität von Open Source-Projekten

• Softwareentwickler sind keine Zahnräder, die man beliebig ein- und ausbauen kann
• Der E-Mail-Thread endet damit, dass ein konsumierender Nutzer weiter Forderungen stellt, aber keinerlei Hilfe anbietet, sodass am Ende nur der Angreifer übrig bleibt

  • "Jia Tan könnte künftig eine größere Rolle im Projekt übernehmen. Er hat außerhalb der Liste viel geholfen und ist faktisch bereits Co-Maintainer. :-)"

• Dieser E-Mail-Thread zeigt im Kleinen die Interaktionen in Open Source-Projekten
• Nutzer stellen Anforderungen an Maintainer, und Maintainer reagieren unterschiedlich auf Stress und Burnout
• Daran muss sich etwas ändern

[GN⁺]

Hacker-News-Kommentare

• Es gibt die Meinung, dass Entwickler viel mentale Energie verschwenden, wenn sie versuchen, freundlich zu Nutzern zu sein und in Kommentaren gute Absichten zu erkennen. Solche Ansichten kommen meist aus Side Projects, die aus Spaß betrieben werden (Emulatoren, Game-Remakes usw.). Diese Projekte vermeiden es, Spenden zu erwähnen, um Probleme rund um Spenden oder Urheberrecht zu vermeiden. Es gibt viel Interesse am Projekt, aber echtes qualifiziertes Interesse, das tatsächlich beitragen kann, ist äußerst begrenzt. Gespräche unter Nutzern sind erlaubt und werden gefördert, können aber manchmal als „Vorschläge“ oder „Forderungen“ wahrgenommen werden, die die Motivation der Entwickler senken. Es ist wichtig, die Community zu erhalten, aber es gibt auch die Sorge, Menschen auszuschließen, die nicht direkt beitragen.

• Der erste Schritt des Problems war ein Social-Engineering-Angriff, bei dem Open-Source-Projektentwickler unter Druck gesetzt wurden, Angreifern mehr Kontrolle über das Repository zu überlassen.

• Als Maintainer einer sicherheitsorientierten Open-Source-Bibliothek lastet bei jedem PR der Verdacht schwer, ob diese Person helfen oder mich ausnutzen will. Ich glaube, die einzige Lösung ist, das Entwicklungstempo zu verlangsamen, aber die Gefühle dabei sind dieselben wie im Artikel beschrieben. Wenn es einen einfachen Weg gäbe, eine vertrauenswürdige Community von Experten um Hilfe zu bitten, würde ich das jederzeit begrüßen.

• Wie bei Kryptowährungen, AI und auch in diesem Fall läuft das größte Problem letztlich auf Vertrauen hinaus. Kryptowährungen versuchen, das Vertrauensproblem mit Code zu lösen, LLMs versuchen, mit Blendwerk Vertrauen zu gewinnen, und Angreifer haben teilweise Erfolg damit, Vertrauen zu waschen. Ausgerechnet die wichtigsten Technologen denken über Vertrauen nicht richtig nach. In diesem Fall gibt es Verständnis für erschöpfte, unbezahlte Open-Source-Entwickler.

• Es gibt die Frage, ob ein SSH-Server mit eingerichtetem Port Knocking gegen diese Backdoor sicher wäre. Da RCE erst nach einer Verbindung zum SSH-Server ausgeführt werden kann, scheint es kein Problem zu geben, wenn der Port hinter einer sinnvollen TCP-/UDP-Knocking-Sequenz verborgen ist. Port Knocking ersetzt keine ordentliche SSH-Konfiguration, ist aber als zusätzliche Verteidigungsschicht nützlich, um bei SSH-Schwachstellen vorzubeugen oder Zeit für eine Reaktion zu gewinnen.

• Es gibt einen Link zu einem Problem im Zusammenhang mit einem Linux-spezifischen Patch für OpenSSH. Ohne diesen Patch wäre das Problem nicht aufgetreten. Das ist kein Problem von OpenSSH, sondern von Linux.

• Es gibt die Meinung, dass die Leute selbst nach dem left-pad-Vorfall harte Abhängigkeiten und Komplexität noch immer nachlässig behandeln. OpenSSH ist eine riesige Wand aus Code. Komplexe Systeme sind grundsätzlich schwer zu vertrauen, egal in welcher Sprache sie geschrieben sind.

• Wenn ein chinesischer Hacker böswillig handeln will, warum sollte er dann einen chinesischen Namen/Handle verwenden? Um bei Open-Source-Maintainern mehr Vertrauen zu gewinnen, wäre ein englischer oder europäischer Name besser. Umgekehrt ergibt es für einen nichtchinesischen Hacker mehr Sinn, einen chinesischen Namen zu verwenden, wenn er böswillig handeln will (China ist böse usw.).

• Das Konto Jigar Kumar scheint Teil eines Social-Engineering-Angriffs zu sein und hätte hochgradig verdächtig wirken müssen.

• Softwareentwickler sind keine austauschbaren Teile, und es gibt Überlegungen, die Berechtigung zum Kommentieren oder zur Teilnahme in der Community einzuschränken. Wenn GitHub zum Beispiel ein „Gate“ einführen würde, könnte das erste Gate darin bestehen, dem Test-Suite einen Test hinzuzufügen, der eine Versionsnummer und den Hash der Testausgabe erzeugt. Wenn man diese Nummer dem Profil hinzufügt, könnte GitHub darauf vertrauen, dass der Nutzer zumindest make test heruntergeladen und ausgeführt hat. Das zeigt ein gewisses Maß an Engagement.