{"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\/news\/v-nixos-predlozhen-metod-zashhity-ot-podstanovki-bekdorov-takih-kak-v-xz","title":{"rendered":"In NixOS wurde eine Methode zum Schutz vor der Einf\u00fchrung von Backdoors, wie sie im Projekt XZ vorkamen, vorgeschlagen.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Um in das Repository der Pakete nixpkgs, das in der NixOS-Distribution verwendet wird, aufgenommen zu werden, wurde ein Modus f\u00fcr reproduzierbare Builds vorgeschlagen. Dieser erlaubt es, F\u00e4lle der Codeeinf\u00fchrung von Backdoors zu erkennen, die an den Vorfall im Projekt XZ erinnern. Die vorgestellte Schutzmethode erm\u00f6glicht es, Modifikationen in den Archiven des Quellcodes der Ver\u00f6ffentlichung zu entdecken, die in den Code-Repositories nicht vorhanden sind. <\/p>\n
Die Essenz 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 wurde, und ein zweites Mal aus dem Code, der als fertige Archive verteilt wird. Wenn die resultierenden Bin\u00e4rdateien unterschiedlich sind, gibt es einen Grund zur Annahme, dass im Repository oder in der Archivdatei mit dem Code versteckte Modifikationen vorliegen. <\/p>\n
Zur Erinnerung: Im Fall des Projekts XZ enthielt das Code-Repository keine verd\u00e4chtigen \u00c4nderungen. Die sch\u00e4dlichen Komponenten, die die Backdoor bilden, wurden in Dateien geliefert, die im Testset zur \u00dcberpr\u00fcfung der korrekten Funktion des XZ-Dekompressors 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 die Backdoor aktivierenden m4-Makros f\u00fcr das Automake-Werkzeug waren nur im fertigen Archiv mit dem Code enthalten und fehlten im Repository. <\/p>\n
Die Backdoor in XZ wurde von einem Angreifer eingebaut, der den Status eines Maintainers im Projekt erlangt hatte. Die Einf\u00fchrung der Backdoor wurde zun\u00e4chst nicht bemerkt, da die Distributionen haupts\u00e4chlich Pakete kompilieren, indem sie Code aus fertigen Archiven laden. Denn bei der Kodierung f\u00fcr den Build kann man sich auf eine einzige Pr\u00fcfziffer zur \u00dcberpr\u00fcfung der Integrit\u00e4t der Archivdatei st\u00fctzen und Spiegelserver nutzen. Bei der \u00dcberpr\u00fcfung 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\u00f6nnen. <\/p>\n
Um die \u00dcberpr\u00fcfung der \u00dcbereinstimmung von Archivdateien und Snapshots des Repositories, die den Releases entsprechen, zu vereinfachen, haben einige Open-Source-Projekte, wie PostgreSQL, ein System f\u00fcr wiederholbare Archivgenerierung eingef\u00fchrt. In diesem Fall wird ein Werkzeugset bereitgestellt, mit dem man selbst aus dem Code sein eigenes Archiv erstellen kann, das vollst\u00e4ndig mit dem verf\u00fcgbaren Archiv zum Download \u00fcbereinstimmt. Wenn das unabh\u00e4ngig erstellte Archiv und das vom Hauptprojekt bereitgestellte Archiv unterschiedlich sind - 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 einf\u00fcgen, die im Hauptrepository fehlen, wie man-Seiten, Dokumentation, Beispiele, Paketserien f\u00fcr Distributionen und zus\u00e4tzliche Build-Dateien. Dies geschieht in der Regel aus historischen Gr\u00fcnden und aufgrund der Besonderheiten der Ver\u00f6ffentlichungsprozesse. Einfache \u00dcberpr\u00fcfungen der \u00dcbereinstimmung von Repository-Inhalten und Archiv sind in diesem Fall nicht geeignet. <\/p>\n
Als L\u00f6sung wird vorgeschlagen, die Bin\u00e4rdateien des Releases sowohl aus dem Repository (zum Beispiel kann das automatisch generierte Archiv in GitHub f\u00fcr den Release-Tag verwendet werden) als auch aus dem vom Maintainer vorbereiteten Archiv zu erstellen und dann das Ergebnis zu vergleichen. Derzeit ist eine solche \u00dcberpr\u00fcfung als Experiment nur f\u00fcr das Paket \u201exz\u201c vorgesehen. Wenn das Experiment erfolgreich ist, planen sie, \u00e4hnliche Pr\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":"