In NixOS wurde eine Methode zum Schutz vor der Einführung von Backdoors, wie sie im Projekt XZ vorkamen, vorgeschlagen.

Um in das Repository der Pakete nixpkgs, das in der NixOS-Distribution verwendet wird, aufgenommen zu werden, wurde ein Modus für reproduzierbare Builds vorgeschlagen. Dieser erlaubt es, Fälle der Codeeinführung von Backdoors zu erkennen, die an den Vorfall im Projekt XZ erinnern. Die vorgestellte Schutzmethode ermöglicht es, Modifikationen in den Archiven des Quellcodes der Veröffentlichung zu entdecken, die in den Code-Repositories nicht vorhanden sind.

Der Kern der Methode besteht darin, dass der Quellcode der neuen Version der Anwendung zweimal kompiliert wird – einmal aus dem Code, der aus dem git-Repository geladen wird, und ein zweites Mal aus dem Code, der in fertigen Archiven verteilt wird. Wenn sich die resultierenden Binärdateien unterscheiden, gibt es Anlass zur Vermutung, dass versteckte Modifikationen im Repository oder in der Archivdatei mit dem Code vorliegen.

Zur Erinnerung: Im Fall des Projekts XZ enthielt das Code-Repository keine verdächtigen Änderungen. Die schädlichen Komponenten, die die Backdoor bilden, wurden in Dateien geliefert, die im Testset zur Überprüfung der korrekten Funktion des XZ-Dekompressors verwendet wurden. Die Backdoor wurde auf der Ebene des Build-Systems aktiviert, während der Quellcode von XZ mit dem Code im Repository übereinstimmte. Die die Backdoor aktivierenden m4-Makros für das Automake-Werkzeug waren nur im fertigen Archiv mit dem Code enthalten und fehlten im Repository.

Die Backdoor in XZ wurde von einem Angreifer eingebaut, der den Status eines Maintainers im Projekt erlangt hatte. Die Einführung der Backdoor wurde zunächst nicht bemerkt, da die Distributionen hauptsächlich Pakete kompilieren, indem sie Code aus fertigen Archiven laden. Denn bei der Kodierung für den Build kann man sich auf eine einzige Prüfziffer zur Überprüfung der Integrität der Archivdatei stützen und Spiegelserver nutzen. Bei der Überprüfung des Codes liegt der Fokus auf der Analyse des Inhalts des Repositories, weshalb nicht offensichtliche Unterschiede in den Archiven nicht immer sofort identifiziert werden können.

Um die Überprüfung der Übereinstimmung von Archivdateien und Schnappschüssen von Repositorys, die den Veröffentlichungen entsprechen, zu vereinfachen, haben einige Open-Source-Projekte wie PostgreSQL ein System zur wiederholbaren Archivgenerierung eingeführt. In diesem Fall wird ein Werkzeugset bereitgestellt, das es ermöglicht, aus dem Code ein eigenes Archiv zu erstellen, das vollständig mit dem fertigen Archiv übereinstimmt, das zum Download verfügbar ist. Wenn das unabhängig erstellte Archiv und das vom Hauptprojekt bereitgestellte Archiv unterschiedlich sind, liegt eine Kompromittierung des Repositorys oder des Referenzarchivs vor.

Das Problem ist, dass eine solche Methode nur in bestimmten Fällen praktiziert wird, während viele Projekte weiterhin zusätzliche Artefakte in die Archive einfügen, die im Hauptrepository fehlen, wie man-Seiten, Dokumentation, Beispiele, Paketserien für Distributionen und zusätzliche Build-Dateien. Dies geschieht in der Regel aus historischen Gründen und aufgrund der Besonderheiten der Veröffentlichungsprozesse. Einfache Überprüfungen der Übereinstimmung von Repository-Inhalten und Archiv sind in diesem Fall nicht geeignet.

Als Lösung wurde vorgeschlagen, die Binärdateien der Veröffentlichung sowohl aus dem Repository (zum Beispiel kann das automatisch generierte Archiv auf GitHub für das Release-Tag verwendet werden) als auch aus dem vorbereiteten Archiv des Betreuers zu sammeln und anschließend die Ergebnisse zu vergleichen. Als Experiment wurde eine solche Überprüfung vorerst nur für das Paket „xz“ vorgeschlagen. Wenn das Experiment erfolgreich ist, planen die Überprüfungen, auch in anderen Paketen in nixpkgs eingesetzt zu werden.

Quelle: opennet.ru