{"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\/fr\/blog\/news\/v-nixos-predlozhen-metod-zashhity-ot-podstanovki-bekdorov-takih-kak-v-xz","title":{"rendered":"NixOS propose une m\u00e9thode de protection contre les substitutions de backdoors, comme dans XZ.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Pour inclure dans le d\u00e9p\u00f4t de paquets nixpkgs, utilis\u00e9 dans la distribution NixOS, un mode de compilations reproductibles a \u00e9t\u00e9 propos\u00e9, permettant d'identifier les cas d'injection de backdoors dans le code, rappelant l'incident avec le projet XZ. La m\u00e9thode de protection pr\u00e9sent\u00e9e permet de d\u00e9tecter des modifications dans les archives du code source de la version, absentes dans les d\u00e9p\u00f4ts de code. <\/p>\n
L'essence de la m\u00e9thode est que le code source de la nouvelle version de l'application est assembl\u00e9 deux fois \u2014 la premi\u00e8re fois \u00e0 partir du code t\u00e9l\u00e9charg\u00e9 depuis le d\u00e9p\u00f4t git, et la seconde \u00e0 partir du code distribu\u00e9 dans des archives pr\u00eates \u00e0 l'emploi. Si les fichiers binaires r\u00e9sultant des assemblages diff\u00e8rent, cela soul\u00e8ve des soup\u00e7ons quant \u00e0 d'\u00e9ventuelles modifications cach\u00e9es dans le d\u00e9p\u00f4t ou dans le fichier d'archive contenant le code. <\/p>\n
Rappelons qu'en ce qui concerne le projet XZ, le d\u00e9p\u00f4t de code ne contenait pas de modifications suspectes. Les composants malveillants formant le backdoor \u00e9taient fournis dans les fichiers utilis\u00e9s dans le jeu de tests pour v\u00e9rifier le bon fonctionnement du d\u00e9compresseur XZ. Le backdoor s'activait au niveau du syst\u00e8me de compilation, tandis que le code source de XZ correspondait \u00e0 celui du d\u00e9p\u00f4t. Les macros m4 activant le backdoor pour l'outil Automake \u00e9taient incluses uniquement dans l'archive pr\u00eate contenant le code et absentes du d\u00e9p\u00f4t. <\/p>\n
Le backdoor dans XZ a \u00e9t\u00e9 int\u00e9gr\u00e9 par un attaquant qui a r\u00e9ussi \u00e0 obtenir le statut de mainteneur dans le projet. L'insertion du backdoor n'a pas \u00e9t\u00e9 remarqu\u00e9e imm\u00e9diatement, car les distributions construisent principalement des paquets en chargeant le code \u00e0 partir d'archives pr\u00eates, puisque lors du t\u00e9l\u00e9chargement de code pour la compilation, on peut se contenter d'un seul hachage pour v\u00e9rifier l'int\u00e9grit\u00e9 du fichier d'archive et utiliser des miroirs. L'accent lors de la v\u00e9rification du code est mis sur l'analyse du contenu du d\u00e9p\u00f4t, donc les diff\u00e9rences non \u00e9videntes dans les archives ne peuvent pas toujours \u00eatre identifi\u00e9es imm\u00e9diatement. <\/p>\n
Pour faciliter la v\u00e9rification de la correspondance entre les fichiers d'archive et les vues du d\u00e9p\u00f4t, correspondant aux versions, certains projets open source, comme PostgreSQL, ont introduit un syst\u00e8me de g\u00e9n\u00e9ration r\u00e9p\u00e9table des archives. Dans ce cas, des outils sont fournis pour vous permettre de cr\u00e9er vous-m\u00eame votre archive \u00e0 partir du code, parfaitement conforme \u00e0 l'archive pr\u00eate \u00e0 \u00eatre t\u00e9l\u00e9charg\u00e9e. Si l'archive cr\u00e9\u00e9e de mani\u00e8re ind\u00e9pendante diff\u00e8re de l'archive fournie par le projet principal, cela indique une compromission du d\u00e9p\u00f4t ou de l'archive de r\u00e9f\u00e9rence. <\/p>\n
Le probl\u00e8me est que cette m\u00e9thode n'est pratiqu\u00e9e que dans certains cas, tandis que de nombreux projets continuent d'inclure dans les archives des artefacts suppl\u00e9mentaires absents du r\u00e9f\u00e9rentiel principal, tels que des pages man, de la documentation, des exemples, des scripts de cr\u00e9ation de paquets pour les distributions et des fichiers de compilation suppl\u00e9mentaires. Cela est principalement d\u00fb \u00e0 des raisons historiques et aux caract\u00e9ristiques des processus de cr\u00e9ation des versions. Une simple v\u00e9rification de la conformit\u00e9 entre le contenu du r\u00e9f\u00e9rentiel et l'archive n'est donc pas ad\u00e9quate. <\/p>\n
Comme solution, il a \u00e9t\u00e9 propos\u00e9 de compiler les fichiers binaires de la version \u00e0 partir du d\u00e9p\u00f4t (par exemple, en utilisant l'archive g\u00e9n\u00e9r\u00e9e automatiquement sur GitHub pour le tag de version) ainsi qu'\u00e0 partir de l'archive pr\u00e9par\u00e9e par le mainteneur, puis de comparer le r\u00e9sultat. En tant qu'exp\u00e9rimentation, une telle v\u00e9rification n'a pour l'instant \u00e9t\u00e9 propos\u00e9e que pour le paquet \u00ab xz \u00bb. Si l'exp\u00e9rience s'av\u00e8re concluante, des v\u00e9rifications devraient \u00e9galement \u00eatre utilis\u00e9es pour d'autres paquets dans nixpkgs. \n Source : opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"