Comment un projet Debian vise à laisser nos ordinateurs à l’écart de la CIA !

Lunar, l’un des principaux développeurs du projet Reproducible Builds de Debian a récemment mis à jour un important trou de sécurité qui pourrait impacter tous les logiciels open source, incluant la plupart des distributions Linux. Il expose potentiellement les utilisateurs à un examen minutieux par des tierces parties, dont les agences de renseignement. Son projet est conçu pour combler cette faille.

Un des grands avantages des logiciels open source repose dans les tierces parties qui peuvent inspecter le code pour s’assurer qu’il exécute correctement ce qu’il est censé réaliser. Si un code malicieux est présent, il peut être détecté et éliminé. Cependant, quand le logiciel est distribué sous la forme d’un exécutable binaire, il existe toujours un risque qu’un code malicieux, absent du code source initial, ait pu être ajouté.

Cela ne peut pas nécessairement dire que le développeur a intentionnellement distribué un code corrompu. Si le développeur utilise un compilateur corrompu, celui-ci peut introduire un malware à la transformation du code source en exécutable.

Une preuve de concept made in CIA qui motive le projet

Cette situation peut sembler un peu tirée par les cheveux, mais représente dans les faits un réel problème de sécurité. Les révélations d’Edward Snowden ont dévoilé les travaux de la CIA pour exploiter cette faiblesse afin d’installer des logiciels espions sur les appareils des consommateurs à travers le monde.

Dans une conférence récente organisée par la CIA, une équipe de développeurs a présenté une preuve de concept. Ils ont réussi à court-circuiter les certificats numériques d’Apple pour produire une version corrompue de l’environnement de développement maison XCode. Le compilateur inclus dans XCode est utilisé indépendamment pour produire des applications pour les systèmes d’exploitation OS X et iOS. La version corrompue embarquait un logiciel espion dans chaque application compilée, à l’insu du développeur. Ces applications pouvaient alors être placées sur l’App Store d’Apple, et être potentiellement installées sur des millions d’appareils pommés. La conséquence évidente est que ces applications auraient permis aux agences de renseignement d’espionner les conversations et messages privés de millions d’utilisateurs de par le monde.

Si Apple est une cible de choix, Linux est une cible encore plus tentante. Les utilisateurs avertis sur les questions de sécurité, notamment les plateformes commerciales, utilisent bien souvent Linux pour ses qualités sécuritaires avancées. Ces utilisateurs sont bien sûr les plus en ligne de mire d’agences comme la CIA.

Un concept qui impose un gros travail de remaniement

Les antivirus peuvent détecter des fragments de malware connus, mais cette reconnaissance ne peut être active qu’après la découverte et l’analyse d’une première instance d’un programme malicieux. Cette stratégie ne protège donc pas contre l’infection par des malware non détectés. Le seul moyen d’être sûr qu’un exécutable binaire ne contient pas un code inattendu est de comparer le résultat de la compilation de deux codes sources. Si le résultat d’une compilation ne correspond pas avec un exécutable binaire de référence, il peut donc contenir du code ajouté, potentiellement malfaisant. Bien que ce concept semble particulièrement basique, il pose un réel problème. Le code source de la majorité des paquetages Linux est écrit d’une manière qui ne permet de reproduire un binaire identique à chaque compilation. Ce phénomène possède plusieurs causes dont voici une liste non exhaustive :

• Des horodateurs embarqués dans le code
• L’incrémentation de la numérotation des builds
• Des différences entre différents fichiers systèmes, qui créent une différence entre un fichier compilé sur deux machines différentes
• Les chemins de fichiers de la machine cible sont embarqués dans le binaire et différentes machines peuvent stocker des fichiers ressources équivalents dans différents espaces
• Des données aléatoires liées à la gestion mémoire et processeurs sont embarqués dans le fichier compilé.

La problématique posée par la reproductibilité des compilations requiert donc un nombre important de changements à réaliser :

1. Le code source doit être modifié pour que les variables soient toujours initialisées avec des valeurs statiques (pour éviter les valeurs aléatoires parfois attribuées par la gestion de la mémoire)
2. Eliminer l’utilisation d’horodateurs, les chemins de fichiers source et les estampilles de version
3. Spécifier exactement l’environnement de compilation, de façon rendre le processus reproductible sur chaque ordinateur.

Comme vous pouvez l’imaginer, ce travail est déjà méticuleux sur un seul projet et le projet Debian contient plus de 20 000 paquetages dont la majorité doit être remaniée. Il suffit d’un seul paquetage pour infecter des milliers d’ordinateurs. Ce travail doit donc être effectué !

Si vous voulez suivre l’avancement des travaux, une page wiki du projet est disponible et affiche l’état des paquetages dont la compilation est considérée reproductible à cette heure. La présentation détaillée du projet par Lunar contient tous les éléments techniques liés aux modifications des paquetages.

Sources : www.linuxjournal.com