{"id":122969,"date":"2025-03-25T10:22:42","date_gmt":"2025-03-25T08:22:42","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/v-nixos-predlozhen-metod-zashhity-ot-podstanovki-bekdorov-takih-kak-v-xz"},"modified":"2025-03-25T10:22:42","modified_gmt":"2025-03-25T08:22:42","slug":"v-nixos-predlozhen-metod-zashhity-ot-podstanovki-bekdorov-takih-kak-v-xz","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/novosti-interneta\/v-nixos-predlozhen-metod-zashhity-ot-podstanovki-bekdorov-takih-kak-v-xz","title":{"rendered":"NixOS bietet eine Methode zum Schutz vor der Einf\u00fchrung von Backdoors, wie sie in XZ vorkommen.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Um in das Paketrepository nixpkgs, das in der NixOS-Distribution verwendet wird, aufgenommen zu werden, wurde ein Modus f\u00fcr reproduzierbare Builds vorgeschlagen, der es erm\u00f6glicht, F\u00e4lle von Backdoor-Integration im Code zu identifizieren, \u00e4hnlich dem Vorfall mit dem Projekt XZ. Die vorgestellte Schutzmethode erm\u00f6glicht es, Modifikationen in den Archiven mit dem Quellcode der Ver\u00f6ffentlichung zu erkennen, die in den Code-Repositories fehlen. <\/p>\n
Der Kern der Methode besteht darin, dass der Quellcode der neuen Version der Anwendung zweimal kompiliert wird \u2014 zun\u00e4chst aus dem Code, der aus dem Git-Repository geladen wurde, und dann aus dem Code, der in fertigen Archiven bereitgestellt wird. Wenn die dabei entstandenen Bin\u00e4rdateien unterschiedlich sind, besteht Anlass zur Vermutung, dass es verborgene Modifikationen im Repository oder in der Archivdatei mit dem Code gibt. <\/p>\n
Erinnern wir uns daran, dass im Fall des Projekts XZ das Code-Repository keine verd\u00e4chtigen \u00c4nderungen enthielt. Die die Backdoor bildenden b\u00f6sartigen Komponenten wurden innerhalb von Dateien geliefert, die im Testset zur \u00dcberpr\u00fcfung der korrekten Funktion des XZ-Dekomprimierers verwendet wurden. Die Backdoor wurde auf der Ebene des Build-Systems aktiviert, w\u00e4hrend der Quellcode von XZ mit dem Code im Repository \u00fcbereinstimmte. Die aktivierenden Backdoor m4-Makros f\u00fcr das Automake-Toolset waren nur im fertigen Archiv mit dem Code enthalten und fehlten im Repository. <\/p>\n
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\u00e4chlich Pakete erstellen, indem sie Code aus vorkompilierte Archiven herunterladen, da bei der Code-Download f\u00fcr den Build eine einzige Pr\u00fcfziffer zur Integrit\u00e4ts\u00fcberpr\u00fcfung der Archivdatei ausreicht und Spiegelserver genutzt werden k\u00f6nnen. Der Schwerpunkt bei der \u00dcberpr\u00fcfung des Codes liegt auf der Analyse des Inhalts des Repositories, weshalb nicht offensichtliche Unterschiede in den Archiven nicht immer sofort erkannt werden k\u00f6nnen. <\/p>\n
Um die \u00dcberpr\u00fcfung der \u00dcbereinstimmung von Archivdateien und Snapshots des Repositories, die den Releases entsprechen, zu erleichtern, haben einige Open-Source-Projekte wie PostgreSQL ein System f\u00fcr die wiederholbare Erstellung von Archiven eingef\u00fchrt. In diesem Fall steht ein Werkzeug zur Verf\u00fcgung, mit dem man aus dem Code sein eigenes Archiv erstellen kann, das vollst\u00e4ndig mit dem fertigen Archiv \u00fcbereinstimmt, das zum Download verf\u00fcgbar ist. Wenn das unabh\u00e4ngig erstellte Archiv und das vom Hauptprojekt bereitgestellte Archiv unterschiedlich sind \u2014 liegt eine Kompromittierung des Repositories oder des Referenzarchivs vor. <\/p>\n
Das Problem ist, dass eine solche Methode nur in bestimmten F\u00e4llen praktiziert wird, w\u00e4hrend viele Projekte weiterhin zus\u00e4tzliche Artefakte in die Archive aufnehmen, die im Hauptrepository fehlen, wie man-Seiten, Dokumentationen, Beispiele, Skripte zur Erstellung von Paketen f\u00fcr Distributionen und zus\u00e4tzliche Build-Dateien. Dies geschieht haupts\u00e4chlich aus historischen Gr\u00fcnden und aufgrund der Besonderheiten im Prozess der Ver\u00f6ffentlichung. Eine einfache \u00dcbereinstimmungspr\u00fcfung von den Inhalten des Repositories und des Archivs ist in diesem Fall nicht ausreichend. <\/p>\n
Als L\u00f6sung wird vorgeschlagen, die Bin\u00e4rdateien des Releases sowohl aus dem Repository (z.B. kann das automatisch generierte Archiv von GitHub f\u00fcr das Release-Tag verwendet werden) als auch aus dem vom Betreuer vorbereiteten Archiv zu bauen und dann die Ergebnisse zu vergleichen. Experimentell wurde eine solche \u00dcberpr\u00fcfung zun\u00e4chst nur f\u00fcr das Paket \u201exz\u201c vorgeschlagen. Wenn das Experiment erfolgreich ist, ist geplant, diese \u00dcberpr\u00fcfungen auch in anderen Paketen in nixpkgs zu verwenden. \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"