Kees Cook, ancien administrateur système en chef de kernel.org et leader de l'équipe de sécurité d'Ubuntu, a démontré la possibilité de créer un commit dont l'identifiant raccourci correspond à un commit déjà ajouté dans le noyau Linux. L'expérience a été réalisée pour confirmer la pertinence de la transition vers des identifiants de commit raccourcis de 16 caractères dans le noyau Linux, discutée précédemment dans la liste de diffusion des développeurs du noyau, mais non approuvée par Linus Torvalds.
Les identifiants raccourcis des commits sont générés en laissant les 12 premiers caractères du hachage SHA-1 (48 bits sur 160 bits). Étant donné que le nombre d'objets dans le noyau identifiés par le hachage SHA-1 a dépassé 13 millions, l'apparition de collisions lors de l'utilisation du préfixe de 12 caractères n'est qu'une question de temps. Des exemples d'objets déjà ajoutés au noyau, qui se chevauchent par leurs identifiants de 11 caractères, sont présentés. De plus, il est mentionné que des chevauchements d'identifiants de 12 caractères avaient déjà été constatés en octobre, mais qu'une utilitaire checkpatch a révélé des problèmes avant l'envoi du patch.
Les identifiants raccourcis sont utilisés lors de la publication de liens courts vers des commits, ainsi qu'ils sont indiqués lors de l'envoi de modifications dans le tag « Fixes », en tant que référence à un commit, le problème ayant été résolu dans le patch envoyé (par exemple, « Fixes: e21d2170f366 »). L'apparition de collisions, où plusieurs modifications différentes sont liées à un seul identifiant raccourci, peut entraîner des dysfonctionnements des outils d'analyse et de vérification des modifications, prenant en compte le contenu des tags « Fixes ». Par exemple, ces tags sont pris en compte dans le gestionnaire check_fixes, utilisé dans la branche linux-next, ainsi que dans les scripts d'analyse des corrections de vulnérabilités et de suivi du cycle de vie des patches.
Linus Torvalds a exprimé des doutes face à la proposition d'augmenter la taille minimale des identifiants raccourcis, car en réalité, le nombre de commits dans le référentiel est bien inférieur au nombre d'objets (environ 1/8). Il est peu probable que, si des collisions aléatoires se produisent, elles aient lieu entre un commit et un objet d'un autre type (comme un blob ou une branche). Selon lui, les identifiants raccourcis sont conçus pour être visibles, lisibles et faciles à citer, et il n'y a pour l'instant aucune raison objective d'en augmenter la taille.
Un des développeurs a proposé de réduire la taille tout en augmentant le nombre de bits significatifs, en utilisant un nouveau format basé sur le codage Base36 (caractères 0-9a-z) au lieu des chiffres hexadécimaux. Selon Linus, un tel changement causerait plus de problèmes que cela n'en résoudrait. Par exemple, il faudrait ajouter la prise en charge du nouveau format dans les utilitaires existants et introduire un identifiant de format pour faire la distinction entre l'ancien et le nouveau format.
Pour démontrer que le problème des identifiants raccourcis n'est pas théorique et qu'il ne vaut pas la peine d'attendre pour le résoudre, Kees Cook a élaboré une modification de la documentation du noyau, dont l'identifiant raccourci (1da177e4c3f4) correspond à l'identifiant du commit ayant créé la branche du noyau 2.6.12-rc2. Une collision a pu être obtenue après 6 heures de calcul sur un système équipé d'un GPU NVIDIA GeForce RTX 3080.
La recherche a été effectuée à l'aide de l'outil lucky-commit : des espaces aléatoires étaient ajoutés au texte du patch cible jusqu'à ce que le préfixe SHA-1 de 12 caractères corresponde à ceux déjà présents dans le noyau. Selon Kees, le problème réside moins dans les collisions aléatoires que dans la possibilité de manipuler les identifiants raccourcis à des fins malveillantes, par exemple pour contourner certaines vérifications.
Source : opennet.ru
