Die xz-Hintertür, entdeckt mit NixOS und reproduzierbaren Builds

• Die im März 2024 entdeckte xz-Hintertür hätte in betroffenen sshd-Umgebungen zu Remote Code Execution führen können, und der NixOS-Fall zeigt, dass reproduzierbare Builds Manipulationen in der Supply Chain maschinell sichtbar machen können
• Die schädlichen Bestandteile versteckten sich nicht im gesamten xz-Git-Repository, sondern in den maintainerbereitgestellten Release-Tarballs von 5.6.0 und 5.6.1; während des Builds erzeugten sie aus gefälschten .xz-Testdateien Shell-Skripte und Objektdateien
• Der Angriff nutzte ifunc in glibc, um beim Laden von liblzma Code auszuführen, und zielte auf Debian- und Fedora-artige Umgebungen, in denen sshd über libsystemd transitiv von liblzma abhängt
• NixOS bevorzugt normalerweise automatisch von GitHub erzeugte Quellarchive, doch weil xz im Bootstrap-Schritt von nixpkgs liegt, musste man den Maintainer-Tarballs vertrauen, um einen autoconf-Abhängigkeitszyklus zu vermeiden
• Als vorgeschlagene Abwehrmaßnahme wird xz nach dem Bootstrap noch einmal aus GitHub-Quellen gebaut und das Ergebnis mit dem bisherigen Tarball-Artefakt verglichen; nach Aktivierung der Bedingung zeigten sich Unterschiede in der Größe von liblzma.so und das zusätzliche Symbol _get_cpuid

---

Wie sich die xz-Hintertür versteckte

• xz ist eine Komprimierungs- und Dekomprimierungssoftware, die in zentralen Pfaden von Linux-Distributionen häufig verwendet wird, wenn Quell-Tarballs entpackt werden
• Im März 2024 wurde in xz eine Hintertür entdeckt. Der bösartige Maintainer Jia Tan gewann über etwa drei Jahre hinweg Vertrauen, erhielt Push-Rechte für das Repository und schleuste dann zwischen legitimen Beiträgen schrittweise obfuskierten Code ein
• Andres Freund untersuchte eine ssh-Leistungsverlangsamung von 500 ms auf mehreren Debian unstable-Maschinen, verfolgte sie bis zu liblzma zurück und identifizierte sowie dokumentierte die Hintertür
• Ziel der Hintertür war es, ssh zu kapern, sodass ein Angreifer beim Login mit einem bestimmten RSA-Schlüssel beliebige Befehle auf dem Rechner des Opfers ausführen konnte

Bösartige Tarballs und während des Builds erzeugte Objekte

• Die schädlichen Komponenten befanden sich nicht direkt im gesamten Code des xz-Git-Repositories, sondern waren in den von Jia Tan gebauten, signierten und veröffentlichten Release-Tarballs von xz 5.6.0 und 5.6.1 enthalten
• In einigen .xz-Testdateien im Git-Repository war Maschinencode versteckt, und den Release-Tarballs wurden getarnte Änderungen hinzugefügt, um ihn herauszuholen
• Insbesondere die Änderung an m4/build-to-host.m4 wirkte auf den ersten Blick harmlos und war sogar kommentiert, verbarg in Wirklichkeit aber eine Befehlskette zum Entschlüsseln und Entobfuskieren mehrerer gefälschter .xz-Testdateien
• Das Ergebnis dieses Prozesses war zweierlei
  • ein Shell-Skript, das während des xz-Builds ausgeführt wird
  • eine schädliche binäre Objektdatei
• Das während des Builds ausgeführte Shell-Skript übernahm zwei Aufgaben
  • Es prüfte Ausführungsbedingungen der Hintertür wie bestimmte Linux-Distributionen, glibc-Funktionen und das Vorhandensein einer ssh-Installation
  • Es veränderte das legitime Objekt liblzma_la-crc64_fast.o so, dass es das Symbol _get_cpuid aus der Hintertür-Objektdatei verwendet
• Russ Cox’ xz-Skriptanalyse beschreibt im Detail, wie die schädlichen Ressourcen während des Builds erzeugt werden

ifunc-Hijacking bis zu sshd

• Bei dynamisch gelinkten Programmen lädt der dynamische Loader zur Laufzeit Shared Libraries in den Speicher und trägt Symboladressen in die Global Offset Table (GOT) ein
• ifunc in glibc ist eine Funktion, mit der beim dynamischen Laden eine von mehreren Implementierungen derselben Funktion ausgewählt werden kann; die xz-Hintertür nutzte dies als Pfad zur Ausführung von Schadcode
• ssh auf einigen Distributionen wie Debian und Fedora ist für systemd-Benachrichtigungsunterstützung mit libsystemd gelinkt, und libsystemd ist wiederum mit liblzma gelinkt
  • In diesen Umgebungen hängt sshd transitiv von liblzma ab
• Beim Start von sshd lädt der dynamische Loader libsystemd und liblzma; ist die Hintertür installiert, wird beim Laden von liblzma Schadcode ausgeführt
• Die Hintertür sorgte dafür, dass der ifunc-Resolver das bösartige Symbol _get_cpuid aufruft, und manipulierte die noch nicht schreibgeschützte GOT, um die Adresse von RSA_public_decrypt auf eine schädliche Funktion umzubiegen
• Als Referenz können die Detailanalyse von Securelist sowie der Forschungsartikel zu Angriffsvektoren und Gegenmaßnahmen dienen

Vertrauenswürdige Quellen und die Bootstrap-Beschränkungen von NixOS

• Dieser Angriff konnte wirksam sein, weil viele Distributionen xz aus maintainerbereitgestellten Tarballs statt aus den ursprünglichen Quellen der Git-Forge bauten
• Der Tarball-Workflow hat historische und praktische Gründe
  • Er stammt aus der Zeit früher Linux-Distributionen vor git
  • Er bewahrt den Zustand des Quellcodes zum Release-Zeitpunkt in einem in sich geschlossenen Archiv
  • Er kann Zwischenartefakte wie Manpages und configure-Skripte enthalten und so den Build-Aufwand verringern
  • Komprimierung bringt Vorteile bei der Speichereffizienz
• Aus Sicherheitssicht sollte man, wo technisch möglich, aus Quellen bauen, die von der vertrauenswürdigsten verfügbaren Instanz authentifiziert wurden
  • Bei Projekten, die auf GitHub entwickelt werden, können die von GitHub zu jedem Release automatisch erzeugten Archive verwendet werden
  • Dieselbe Logik gilt auch für vertrauenswürdige Drittplattformen wie Codeberg, SourceHut und GitLab
• NixOS verwendet ein funktionales Paketmanagement-Modell, bei dem Build-Rezepte für Pakete in Nix-Ausdrücken definiert werden
• In NixOS gibt es, wo möglich, eine Kultur der Nutzung automatisch von GitHub erzeugter Quellarchive via fetchFromGitHub, doch das xz-Paket holte per fetchurl einen manuell hochgeladenen Maintainer-Tarball
• Der Grund ist, dass xz Teil des Bootstrap-Schritts von nixpkgs ist
  • Bootstrap ist der Prozess, mit dem sich der gesamte Paketbestand von nixpkgs ausgehend von einer kleinen Menge Seed-Binaries neu bauen lässt
  • stdenv ist die grundlegende Compiler-Umgebung, die andere Pakete verwenden
  • stdenv hängt zur Laufzeit von xz ab, und Pakete wie coreutils benötigen xz, um Quellarchive im Format .tar.xz zu entpacken
• Um xz aus GitHub-Quellen zu bauen, wird autoconf benötigt, um das configure-Skript zu erzeugen, doch autoconf hängt selbst ebenfalls von xz ab
  • Im Maintainer-Tarball ist das configure-Skript bereits enthalten und durchbricht so diesen Abhängigkeitszyklus
  • Daher ist es an der Stelle im nixpkgs-Graphen, an der xz gebaut wird, schwierig, GitHub-Quellarchive zu verwenden, und man musste den Maintainer-Tarballs vertrauen

Vergleich der Konvergenz von Artefakten statt Vergleich der Quellen

• Es wirkt zunächst naheliegend, den Maintainer-Tarball mit dem GitHub-Quell-Tarball auf Gleichheit zu vergleichen, in der Praxis passt dieser Ansatz aber nicht gut
• Daniel Stenberg erklärte, dass es ein Feature sei, wenn sich Release-Tarballs von den Quellen unterscheiden
  • Zwischenartefakte wie Manpages und configure-Skripte können im Tarball enthalten sein
  • Das ist besonders nützlich, wenn Distributionen autoconf-Abhängigkeiten vermeiden wollen
• Aus Sicht der Supply-Chain-Sicherheit wird diese Flexibilität jedoch zu der Last, dem Maintainer auf ehrliches Handeln vertrauen zu müssen
• Reproduzierbare Builds sind die Eigenschaft, dass zwei Builds unter denselben Bedingungen bitgenau identische Artefakte erzeugen
• Die Gruppe reproducible-builds hat das Ziel, möglichst viele Pakete reproduzierbar zu machen, und Reproducible Builds: Increasing the Integrity of Software Supply Chains behandelt dies als Eigenschaft zur Erhöhung des Vertrauens in die Verteilung binärer Artefakte
• Einen Ansatz, auch die Erzeugung von Tarballs selbst reproduzierbar zu machen, hat das PostgreSQL-Projekt übernommen
  • Nutzer können damit unabhängig prüfen, ob ein Maintainer-Tarball ehrlich aus den ursprünglichen Quellen erzeugt wurde
  • Allerdings muss dies vom Maintainer des Upstream-Projekts umgesetzt werden, weshalb die Verbreitung in der FOSS-Community langsam sein kann

Vorgeschlagenes Erkennungsverfahren in NixOS

• Wenn xz bitgenau reproduzierbar ist und der Maintainer-Tarball keine Änderungen enthält, die den Build-Prozess beeinflussen, dann sollten ein Build aus dem GitHub-Tarball und ein Build aus dem Maintainer-Tarball dieselben Artefakte erzeugen
• Die vorgeschlagene Methode baut xz nach dem Bootstrap ein weiteres Mal, diesmal mit dem GitHub-Quellarchiv via fetchFromGitHub, und vergleicht das Ergebnis mit dem xz-Artefakt aus dem bisherigen Bootstrap-Schritt
• Das Implementierungsbeispiel legt unter pkgs/tools/compression/xz eine Datei after-bootstrap.nix an und baut xz 5.6.1 aus GitHub-Quellen
  • Der Maintainer-Tarball enthält das configure-Skript bereits, beim Build aus GitHub-Quellen müssen dagegen autoconf, libtool, automake und weitere Werkzeuge verwendet werden, um ./autogen.sh auszuführen
• Als Vergleichsschritt wird compareArtifacts hinzugefügt, das am Ende des Builds liblzma.so vergleicht
  • Im Beispiel wurde nur liblzma.so verglichen, weil genau diese Datei von der Hintertür verändert wurde, doch der Ansatz lässt sich auf alle binären und Bibliotheksartefakte verallgemeinern
• Auf einer sauberen master-Revision war der Build xz-after-bootstrap erfolgreich, und beide Artefakte waren identisch
• Bei der Revision c53bbe3, die die Hintertür enthielt, sah es zunächst ebenfalls identisch aus
  • Unter NixOS wurde die Hintertür nicht aktiviert; ein Grund dafür war, dass das Installationsskript prüfte, ob die Variable RPM_ARCH gesetzt ist
  • Nachdem mit env.RPM_ARCH = true; die Bedingung aktiviert wurde, traten binäre Unterschiede in liblzma.so zutage
• Nach dem Speichern und Vergleichen der beiden liblzma.so-Dateien war das Artefakt mit Hintertür 258 KB groß, das nach dem Bootstrap aus GitHub-Quellen gebaute Artefakt 210 KB, also eine Differenz von rund 48 KB
• Ein Symbolvergleich mit nm zeigte die zusätzlichen Symbole _cpuid, _get_cpuid und __tls_get_addr@GLIBC_2.3; _get_cpuid ist ein in mehreren technischen Berichten zur xz-Hintertür dokumentiertes Symbol

Einsatzmöglichkeiten und Grenzen

• Die vorgeschlagene Schutzmaßnahme würde auf alle Pakete angewendet, die im Bootstrap-Schritt gebaut werden und keine vertrauenswürdigen Quellarchive verwenden
• Fügt man *-after-bootstrap-Pakete als Channel-Blocker hinzu, kann ein Build-Fehler zu einem starken Alarm werden, der Eingreifen von Maintainern erfordert
• Als Proof of Concept für den xz-Fall wurde im nixpkgs-Repository ein Pull Request eröffnet
• Diese Methode setzt voraus, dass das Zielpaket bitgenau reproduzierbar ist
  • Von 2017 bis 2023 wurden 17 nixpkgs-unstable-Revisionen als Stichprobe genommen und die non-fixed-output derivations von stdenv mit nix-build --check neu gebaut
  • In allen Revisionen war xz bitgenau reproduzierbar
  • In 12 der 17 Revisionen gab es 1 bis 2 Pakete, die zwar baubar, aber nicht reproduzierbar waren; zum Beispiel war gcc von 2017 bis 2021 und bash bis 2019 durchgehend nicht reproduzierbar
• Der Ansatz lässt sich nicht auf alle stdenv-Pakete anwenden, langfristig könnte er aber selektiv für Pakete mit guter Reproduzierbarkeit aktiviert werden
• Ken Thompsons Problem des trusting trust bleibt eine theoretische Grenze dieses Verfahrens
  • Es muss angenommen werden, dass ein nicht vertrauenswürdiges xz im Bootstrap-Schritt den Build von xz-after-bootstrap nicht indirekt so kontaminieren kann, dass die Artefakte identisch erscheinen
  • Ein solcher Angriff wäre zwar sehr komplex, doch die Methode setzt diese Annahme voraus
• Dieses Erkennungsverfahren schlägt nur dann an, wenn Änderungen am Tarball das endgültige Artefakt beeinflussen
  • Da die Hintertür in NixOS-Binärdateien nicht enthalten war, hätte man sie in diesem Fall ohne separate Aktivierung der Bedingung nicht entdeckt

[GN⁺]

Hacker-News-Kommentare

• Es sollte festgehalten werden, dass NixOS und reproduzierbare Builds die xz-Backdoor nicht erkannt haben. Tatsächlich hat auch NixOS den bösartigen xz-Build an Nutzer ausgeliefert; er funktionierte nur nicht, weil die Malware nicht auf NixOS abzielte.
  Auch ein NixOS-Entwickler sagte: „Als die Backdoor öffentlich wurde, war ich überrascht, dass die bösartige Version von xz an unsere Nutzer ausgeliefert worden war.“ Wie immer sind Theorie und Praxis verschieden, und was xz möglich gemacht hat, war weniger eine technische Schwachstelle als vielmehr eine menschliche Schwachstelle in der realen Welt. Die Community tut sich schwer damit anzuerkennen, dass sich solche Probleme nicht immer allein durch bessere Software patchen lassen.

  • Die deklarative Konfiguration von Nix ist ziemlich nützlich, um die Abwehr gegen Angriffe auf verschiedene Weise zu verbessern, aber es gibt noch viel ungenutztes Potenzial. Persönlich würde ich feingranulare Einweg-Container mit höchster Priorität umsetzen wollen; Guix hat so etwas bereits.
    Wenn man jeden Prozess mit eingeschränkten Rechten ausführen und ihm, abgesehen von den für die Aufgabe nötigen Verzeichnissen, sogar den Zugriff auf ~/ verwehren könnte, ließe sich zum Beispiel verhindern, dass ein bösartiges pip-Paket SSH-Schlüssel stiehlt. Trotzdem denke ich, dass der Grund, warum die xz-Backdoor unter NixOS nicht funktionierte, die ungewöhnliche Nicht-FHS-Dateisystemstruktur von NixOS war.
  • Trotzdem war der Artikel gut. NixOS stellt eine technische Lösung gegen Build-Artefakte in den Vordergrund, die vom Quellcode getrennt sind – also gegen nicht reproduzierbare Artefakte –, und die xz-Backdoor versteckte sich genau in einem solchen Build-Artefakt.
  • Genau. Der Titel klang so, als hätte der Nix-Ansatz die Backdoor möglicherweise erkannt, tatsächlich ist der Artikel aber eher ein Vorschlag, wie man Nix ändern müsste, damit es solche Backdoors erkennen kann.
  • Gut, dass betont wurde, dass reproduzierbare Builds die xz-Backdoor nicht tatsächlich vor anderen Entdeckungswegen gefunden haben.
    Heutzutage wird die tatsächliche Realität oft abgewertet, wenn sie nicht zu den persönlichen Gefühlen oder Wertvorstellungen über die objektive Realität passt. Ich habe zwar persönliche Wertvorstellungen, sehe die tatsächliche Realität aber nicht als weniger wichtig an als meine Gefühle dazu. Wie es in einem beliebten Spruch heißt: Der Unterschied zwischen Theorie und Praxis besteht darin, dass beide in der Theorie gleich sind, in der Praxis aber nicht. Ich hoffe, dass die Erkenntnis, dass die reproduzierbaren Builds von NixOS den xz-Angriff hätten finden können, es aber nicht taten, zu Fortschritten führt, bei denen solche Builds künftig analysiert werden, um andere Angriffe schneller zu entdecken.
  • Der Grund ist ein bisschen lustig. Der NixOS-Bootstrap lädt den Quellcode herunter, und dieser Quellcode ist ein mit xz komprimierter Tarball.

• Der Autor scheint zu sehr auf die Art und Weise fixiert zu sein, wie es diesmal zufällig passiert ist. Der Jia-Tan-Vorfall ist nur ein einzelnes Beispiel; zu glauben, nur diese Methode sei möglich, ist kurzsichtig.
  Man kann sich genügend Szenarien vorstellen, in denen die hier vorgeschlagene Verteidigung nicht greifen würde. Auch als Nix-Nutzer halte ich es für unwahrscheinlich, dass NixOS das erkannt hätte. Tatsächlich hat es das ja nicht. Zwar habe ich gerade gesagt, dass es beim nächsten Mal anders passieren könnte, aber Nix ohne Belege zu vertrauen, wäre ebenfalls töricht.

• NixOS ist hier nicht besonders relevant. Die xz-Backdoor zielte konkret auf Red Hat und Debian ab.
  Nach derselben Logik wäre es ähnlich relevant zu sagen, dass die xz-Backdoor Windows nicht betroffen hat. Ironischerweise wurde diese Backdoor am Ende von einem Microsoft-Mitarbeiter entdeckt, was oft übersehen wird.

  • Ein etwas verbessertes NixOS oder Guix hätte diese Backdoor automatisch erkannt, sobald sie ins Repository gelangt wäre. Deshalb ist es relevant.

• Im Artikel heißt es, Distributionen sollten den Quellcode statt aus traditionellen Installations-Tarballs direkt aus einem Versionskontrollsystem, zum Beispiel Github, beziehen.
  Ich verstehe aber nicht, was das lösen soll. Ein böswilliger Maintainer könnte doch einfach einen binären Blob direkt ins Quellcode-Repository aufnehmen, oder? Der Autor scheint Github so zu vertrauen, als würde es Code verifizieren, aber natürlich macht Github keine solche Prüfung.

  • Was dieser Ansatz löst, ist das Problem, dass „das, was geprüft wurde“ und „der für den Software-Build verwendete Quellcode“ oft nicht identisch sind.
    Verifizierte reproduzierbare Builds hätten helfen können, Fälle wie die Kompromittierung von xz utils oder die Manipulation von SolarWinds Orion zu verhindern, und das ist den Aufwand durchaus wert.
  • Diese Kritik trifft nicht ganz. Wenn man aus dem Source baut, können man selbst und alle anderen den Source prüfen; wenn man aber aus dem bereitgestellten Tarball baut, verändert der autoconf-Prozess Dateien, sodass sie sich im Vergleich zum ursprünglichen Source grundsätzlich unterscheiden.
    Wenn man von einem Github-Release eine Binärdatei herunterlädt und ausführt, bleibt einem nichts anderes übrig, als dem Maintainer vollständig zu vertrauen. Nix macht das nur bei Closed-Source-Paketen so.

• Die Argumentation stützt sich darauf, dass der XZ-Maintainer bösartigen Code in einem Tarball versteckt hat, der nicht in Git eingecheckt war.
  Der Autor zeigt, dass Nix so konfiguriert werden kann, dass es aus Git einen Tarball erzeugt und diesen in den Binär-Build einfließen lässt. Aber ich sehe nicht, warum das eine Funktion sein soll, für die man Nix oder NixOS braucht. Jedes Build-System, auch solche für RPMs oder Debs, kann so konfiguriert werden, dass es als Zwischenschritt einen Tarball erzeugt. Tatsächlich arbeitet Debian schon lange mit reproduzierbaren Builds als wichtigem Ziel. https://wiki.debian.org/ReproducibleBuilds

  • Der Artikel zitiert im Abschnitt „Leveraging bitwise reproducibility“ tatsächlich das reproducible-builds-Projekt. Der Kern des Artikels sind zwei Punkte.
    Erstens konnte der NixOS-Build-Prozess keinen vollständigen Source-Build von xz durchführen, weil xz sehr früh im Bootstrap zu früh benötigt wurde. Zweitens schlägt er Anpassungen an nixpkgs vor, um automatisch zu erkennen, ob für die frühe Bootstrap-Phase nötige nixpkgs-Abhängigkeiten kompromittiert wurden. Andere Ökosysteme können natürlich ebenfalls vollständige Source-Builds versuchen und Abweichungen finden. Der zentrale Punkt des Artikels ist, dass nixpkgs das derzeit nicht kann.

• Wenn man sich auf einen Fall konzentrieren will, den NixOS hätte verhindern können, sollte man sich den CrowdStrike-Vorfall ansehen. Allein die Möglichkeit, mit der gestrigen Konfiguration zu booten, wenn die heutige nicht funktioniert, hätte den größten Teil des Schadens abgemildert.

  • Allerdings ist das ein Problem von Windows, dem diese Boot-Flexibilität fehlt. Ubuntu kann das auf ZFS ebenfalls.

• Wer ein vertrauenswürdiges Framework nutzt, ist sicher, bis dieses Framework selbst angegriffen wird. Die xz-Backdoor wurde zwar entdeckt, war aber nicht mit dem Ziel entworfen worden, im Nix-Ökosystem zu funktionieren.
  Irgendwann, wenn ein Nix-Core-Entwickler ein Spion ist oder eine ähnliche Situation entsteht, wird es auch Angriffe geben, die auf das Nix-Ökosystem abzielen. Ich hoffe, niemand antwortet so, als sei Nix inhärent sicher. Wenn Nix in ein bis zwei Jahren erfolgreich angegriffen wird, könnte ich fast versucht sein, wiederzukommen und die Leute eingestehen zu lassen, dass sie falschlagen.

  • Der Maßstab war in der Vergangenheit und wird auch künftig absolute Sicherheit nicht sein. Das ist ein unmöglicher Maßstab, den nichts erfüllen kann. Trotzdem ist es objektiv wahr, dass Software heute im Allgemeinen sicherer ist als vor 30 Jahren.
    Die stärkere Behauptung lautet: „Nix ist schwerer und teurer anzugreifen als traditionelle Build-Systeme.“ Wenn du also einen billigen Weg findest, Nix anzugreifen, komm dann wieder. Bis dahin ist die Aussage, dass Nix auf technischer Ebene schwerer anzugreifen ist als alternative Systeme, zumindest plausibel und tatsächlich sehr wahrscheinlich.
  • Die Backdoor war zwar nicht auf Nix ausgerichtet, musste aber, um nicht aufzufallen, auch während des Builds unter Nix unverdächtig bleiben.

• NixOS geht zwar ein Stück weiter, aber die meisten anderen Distributionen kompilieren ebenfalls alles aus dem Quellcode, verifizieren kryptografisch, dass die verwendeten Quellen nicht manipuliert wurden, und haben versionsgebundene Abhängigkeiten zwischen Paketen. Auch Debian hat reproduzierbare Builds.
  Das Problem war, dass das Build-System vorkompilierte Objektdateien nicht entfernt hat, bevor es aus dem Quellcode gebaut hat. Selbst wenn man das behebt, kann man beliebig viele Backdoors einbauen, wenn niemand den Quellcode prüft; weder NixOS noch irgendeine andere Distribution kann das verhindern.

• Eine hervorragende technische Analyse, aber der Titel ist falsch und irreführend. Auch wenn man sagen könnte, er sei „technisch korrekt“, trifft es im besten Fall eher den Sinn einer eingeschleusten Backdoor.
  Das zeigt gut, dass wir Build-Manager-Tools brauchen, die über Union-Dateisystem-Schichten hinausgehen. Zum Beispiel müssen sie nachverfolgen und erzwingen, dass Tests die Build-Artefakte nicht kontaminieren können. Nötig wäre ein kausaler Tracking-Graph, der zeigt, wie Dateien im Build-Prozess andere Dateien beeinflussen; dieser Graph sollte explizit erstellt und dann erzwungen werden oder Unterschiede zu früheren Tracking-Graphen melden.

• Stimmt. Es wäre definitiv schwieriger geworden, die Backdoor zu verstecken. Aber unmöglich ist es bei Weitem nicht.
  Wenn man will, kann man jederzeit eine Backdoor im Quellcode verstecken. Es erfordert nur mehr Aufwand, sie wie einen plausiblen Bug aussehen zu lassen, und die Wahrscheinlichkeit, entdeckt zu werden, steigt.