NixOS bietet eine Methode zum Schutz vor der Einführung von Backdoors, wie sie in XZ vorkommen.

Um in das Paketrepository nixpkgs, das in der NixOS-Distribution verwendet wird, aufgenommen zu werden, wurde ein Modus für reproduzierbare Builds vorgeschlagen, der es ermöglicht, Fälle von Backdoor-Integration im Code zu identifizieren, ähnlich dem Vorfall mit dem Projekt XZ. Die vorgestellte Schutzmethode ermöglicht es, Modifikationen in den Archiven mit dem Quellcode der Veröffentlichung zu erkennen, die in den Code-Repositories fehlen.

Das Prinzip der Methode besteht darin, dass der Quellcode der neuen Version der Anwendung zweimal kompiliert wird – einmal aus dem Code, der aus dem Git-Repository heruntergeladen wurde, und einmal aus dem Code, der in vorgefertigten Archiven verteilt wird. Wenn die resultierenden Binärdateien unterschiedlich sind, ergibt sich ein Grund für den Verdacht auf versteckte Modifikationen im Repository oder in der Archivdatei mit dem Code.

Erinnern wir uns daran, dass im Fall des Projekts XZ das Code-Repository keine verdächtigen Änderungen enthielt. Die die Backdoor bildenden bösartigen Komponenten wurden innerhalb von Dateien geliefert, die im Testset zur Überprüfung der korrekten Funktion des XZ-Dekomprimierers 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 aktivierenden Backdoor m4-Makros für das Automake-Toolset waren nur im fertigen Archiv mit dem Code enthalten und fehlten im Repository.

Die Backdoor in XZ wurde von einem Angreifer implementiert, der den Status eines Maintainern im Projekt erlangt hatte. Die Implementierung der Backdoor blieb sofort unbemerkt, da die Distributionen hauptsächlich Pakete erstellen, indem sie Code aus vorkompilierte Archiven herunterladen, da bei der Code-Download für den Build eine einzige Prüfziffer zur Integritätsüberprüfung der Archivdatei ausreicht und Spiegelserver genutzt werden können. Der Schwerpunkt bei der Überprüfung des Codes liegt auf der Analyse des Inhalts des Repositories, weshalb nicht offensichtliche Unterschiede in den Archiven nicht immer sofort erkannt werden können.

Um die Überprüfung der Übereinstimmung von Archivdateien und Repository-Schnitten, die den Veröffentlichungen entsprechen, zu vereinfachen, haben einige Open-Source-Projekte wie PostgreSQL ein System zur reproduzierbaren Erstellung von Archiven eingeführt. In diesem Fall wird ein Werkzeugset bereitgestellt, mit dem Sie Ihr Archiv eigenständig aus dem Code erstellen können, das vollständig mit dem bereitgestellten Archiv für den Download übereinstimmt. Wenn das unabhängig erstellte Archiv und das vom Hauptprojekt bereitgestellte Archiv unterschiedlich sind, liegt eine Kompromittierung des Repositories 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 aufnehmen, die im Hauptrepository fehlen, wie man-Seiten, Dokumentationen, Beispiele, Skripte zur Erstellung von Paketen für Distributionen und zusätzliche Build-Dateien. Dies geschieht hauptsächlich aus historischen Gründen und aufgrund der Besonderheiten im Prozess der Veröffentlichung. Eine einfache Übereinstimmungsprüfung von den Inhalten des Repositories und des Archivs ist in diesem Fall nicht ausreichend.

Als Lösung wurde vorgeschlagen, die Binärdateien der Veröffentlichung sowohl aus dem Repository (zum Beispiel kann das automatisch generierte Archiv in GitHub für das Release-Tag verwendet werden) als auch aus dem Archiv, das vom Maintainer vorbereitet wurde, zu kompilieren und dann das Ergebnis zu vergleichen. Als Experiment wurde eine solche Überprüfung bisher nur für das Paket „xz“ vorgeschlagen. Wenn das Experiment erfolgreich ist, wird angestrebt, diese Überprüfung auch für andere Pakete in nixpkgs zu verwenden.

Quelle: opennet.ru