NixOS propose une méthode de protection contre les substitutions de backdoors, comme dans XZ.

Pour inclure dans le dépôt de paquets nixpkgs, utilisé dans la distribution NixOS, un mode de compilations reproductibles a été proposé, permettant d'identifier les cas d'injection de backdoors dans le code, rappelant l'incident avec le projet XZ. La méthode de protection présentée permet de détecter des modifications dans les archives du code source de la version, absentes dans les dépôts de code.

L'essence de la méthode est que le code source de la nouvelle version de l'application est compilé deux fois : la première fois à partir du code téléchargé depuis le dépôt git, et la seconde fois à partir du code distribué dans des archives prêtes. Si les fichiers binaires résultants des compilations diffèrent, cela suscite des soupçons quant à la présence de modifications cachées dans le dépôt ou dans le fichier archive contenant le code.

Rappelons qu'en ce qui concerne le projet XZ, le dépôt de code ne contenait pas de modifications suspectes. Les composants malveillants formant le backdoor étaient fournis dans les fichiers utilisés dans le jeu de tests pour vérifier le bon fonctionnement du décompresseur XZ. Le backdoor s'activait au niveau du système de compilation, tandis que le code source de XZ correspondait à celui du dépôt. Les macros m4 activant le backdoor pour l'outil Automake étaient incluses uniquement dans l'archive prête contenant le code et absentes du dépôt.

Le backdoor dans XZ a été intégré par un attaquant qui a réussi à obtenir le statut de mainteneur dans le projet. L'insertion du backdoor n'a pas été remarquée immédiatement, car les distributions construisent principalement des paquets en chargeant le code à partir d'archives prêtes, puisque lors du téléchargement de code pour la compilation, on peut se contenter d'un seul hachage pour vérifier l'intégrité du fichier d'archive et utiliser des miroirs. L'accent lors de la vérification du code est mis sur l'analyse du contenu du dépôt, donc les différences non évidentes dans les archives ne peuvent pas toujours être identifiées immédiatement.

Pour simplifier la vérification de la correspondance des fichiers d'archives et des instantanés du référentiel correspondant aux versions, certains projets open source, comme PostgreSQL, ont introduit un système de génération d'archives répétables. Dans ce cas, un outil est fourni, permettant de créer soi-même une archive à partir du code, correspondant exactement à l'archive prête à être téléchargée. Si l'archive créée indépendamment et l'archive fournie par le projet principal diffèrent, cela signifie qu'il y a eu compromission du référentiel ou de l'archive de référence.

Le problème est que cette méthode n'est pratiquée que dans certains cas, tandis que de nombreux projets continuent d'inclure dans les archives des artefacts supplémentaires absents du référentiel principal, tels que des pages man, de la documentation, des exemples, des scripts de création de paquets pour les distributions et des fichiers de compilation supplémentaires. Cela est principalement dû à des raisons historiques et aux caractéristiques des processus de création des versions. Une simple vérification de la conformité entre le contenu du référentiel et l'archive n'est donc pas adéquate.

Comme solution, il est proposé de rassembler les fichiers binaires des versions, tant à partir du référentiel (par exemple, on peut utiliser l'archive générée automatiquement sur GitHub pour le tag de version) que de l'archive préparée par le responsable, puis de comparer les résultats. Pour l'instant, cette vérification n'est proposée qu'à titre d'expérimentation pour le paquet « xz ». Si l'expérience est concluante, ce type de vérification sera envisagé pour d'autres paquets dans nixpkgs.

Source : opennet.ru