Piraté ou pas, le noyau Linux est bien protégé

Ce fut un choc d'apprendre que le site Kernel.org avait été piraté le mois dernier. Certes, le fait est devenu monnaie courante, une nouvelle banale dans le monde en général... Mais pas dans la maison Linux.

Le site Kernel.org a été piraté, mais le noyau Linux n'a pas été affecté. Sans aucun doute, les investigations se poursuivent sur plusieurs fronts, et Kernel.org s'emploie à faire en sorte que chacun de ses 448 utilisateurs changent de mot de passe et de clés SSH. Reste que, en attendant, il semble qu'il n'y ait aucun besoin de s'inquiéter au sujet du code Linux. Une bonne nouvelle pour ceux qui connaissent et aiment ce code (maj).

Trois raisons pour lesquelles cela semble bien être le cas, ont émergé depuis que le piratage a été découvert. En substance, elles se résument par le fait que le développement du noyau se fait à l'aide de Git, un logiciel de gestion de versions décentralisé (il est distribué sous licence libre GNU GPL version 2), créé par Linus Torvalds, le créateur du noyau Linux. Voilà en quoi cela fait une différence

« Un hachage cryptographiquement sûr »

« Les dommages potentiels résultant du piratage du site Kernel.org ont beaucoup moins de conséquence que sur des banques de logiciels classiques », indique le communiqué publié sur le site Kernel.org. En effet, Git indexe les fichiers d'après leur somme de contrôle calculée avec la fonction SHA-1. « Pour chacun des 40 000 fichiers environ du noyau Linux, la table de hachage SHA-1 est cryptographiquement sûre, et calculée en fonction du contenu unique et exact du fichier, » explique la note. « Git prend en compte, pour établir le nom de chaque version du noyau, de l'historique de tout le développement jusqu'à la version en question. Une fois qu'il est publié, il n'est pas possible de changer les anciennes versions sans que l'on s'en rende compte. » Par ailleurs, ces fichiers et leurs hachages liés sont répartis dans plusieurs endroits : sur la machine kernel.org et ses miroirs, sur les disques durs de plusieurs milliers de développeurs travaillant sur le noyau, de ceux qui maintiennent la distribution Linux et d'autres personnes impliquées dans kernel.org, » ajoute le site. « L'altération de n'importe quel fichier dans le référentiel kernel.org serait immédiatement repéré par chaque développeur au moment de la mise à jour de leur référentiel personnel, ce que font la plupart d'entre eux quotidiennement. »

«Inutile de s'inquiéter» 

Jonathan Corbet, rédacteur en chef de LWN.net et contributeur pour le noyau Linux, a eu les mêmes mots rassurant. Tout en admettant que la violation était « troublante et embarrassante », celui-ci a écrit que « il n'y avait pas besoin de s'inquiéter de l'intégrité du noyau source ou de tout autre logiciel hébergé sur les systèmes de kernel.org. » Si les développeurs travaillaient sur des bouts de codes pour les envoyer ensuite comme de simples fichiers, ceux-ci pourraient être vulnérable aux logiciels malveillants ajoutés par des intrus, » a expliqué Jonathan Corbet. « Mais ce n'est pas comme ça que se fait le développement du noyau Linux. »

Comme le fait remarquer le journaliste, la fonction de hachage de Git produit des nombres en 160 bits, et chaque fois que le contenu d'un fichier est modifié, le « hash » change aussi. « Un pirate n'aurait aucun moyen de modifier un fichier sans changer en même temps le hash correspondant. Git vérifie les hash régulièrement, et une tentative pour corrompre un fichier serait presque immédiatement repérée, » a-t-il ajouté.

« On le verrait tout de suite » 

Il y a également le fait que « pour un état donné de l'arborescence du noyau source, Git calcule un hash basé sur les valeurs de hash de tous les fichiers contenus dans cet arbre, et les valeurs de hash de tous les précédents états de l'arbre », a expliqué Jonathan Corbet. « Par exemple, le hash du kernel version 3.0 est 02f8c6aee8df3cdc935e9bdd4f2d020306035dbe. Il n'y a aucun moyen de modifier les fichiers contenus de cette version - ou dans une quelconque version précédente - sans changer cette valeur de hachage. Si quelqu'un (même via la banque de logiciels kerneg.org) tentait de proposer un noyau 3.0 avec un hachage différent, on verrait tout de suite qu'il y a un problème. »

On peut trouver plus d'explications sur le blog du développeur Git Junio Hamano C, comme indiqué sur The H, qui fournit encore plus de détails techniques.

Alors, si ces experts disent vrai - et on peut être sûr que c'est le cas - le noyau Linux est tout à fait sain et sauf.

LMI