Le piège au phoque vérifié : des signatures malléables menacent l'unicité du hachage dans les engagements de Git

Un nouveau travail de recherche de Jacob Ginesin (PhD in Carnegie Mellon and cryptographic auditor in Cure53) dispose d'une hypothèse étendue: qu'une confirmation (commit) signée dans Git est, en soi, un nom unique et immuable pour son contenu. La technique ne brise pas SHA-1 ou SHA-256 ni ne modifie le code; elle profite de la malléabilité des signatures- des manières différentes et valides de représenter la même signature - de réécrire les octets de signature qui sont inclus dans l'objet commit, changeant ainsi leur hash sans toucher les fichiers, l'auteur ou la date. Ginesin documente trois vecteurs concrets (ECDSA, RSA / EdDSA avec des champs OpenPGP non authentifiés et S / MIME avec un codage DER non canonique) et accompagne son étude avec des outils de test et des dépôts de démo qui montrent comment GitHub continue à imprimer le sceau "Vérifié" après ces mutations.

La racine du problème n'est pas Git ou les humains qui signent, mais comment les forges consomment et font confiance à la signature: GitHub et d'autres services ne normalisent pas les signatures avant qu'elles ne soient vérifiées et associent le sceau vérifié au hachage exact de l'objet reçu. Cela permet des scénarios pratiques d'exploitation : bloquer un commit par son hachage laisse un trou - un attaquant peut repousser la même confirmation avec des signatures réencodées sous un hachage différent et, pourtant, le voir marqué comme vérifié -; redoublant systèmes, listes de blocs et bits source qui utilisent seulement le hachage héritera de la même fragilité; un miroir compromis peut retourner des confirmations valablement signées dont la représentation en octets (et donc son hachage) diffère de la version dans la forge canonique.

Il est important de souligner ce que ce n'est pas : ce n'est pas une porte pour changer le contenu sans que la signature le détecte. Le contenu film des blobs et des arbres reste identique, et pincer un hachage complet pour obtenir le code continue de s'assurer que vous recevrez exactement ce que le hachage correspond ou ne parvient pas à télécharger. La question est sémantique et opérationnelle: le sceau "Vérifié" ne garantit pas que le hachage est un nom unique et immuable de l'objet signé Et beaucoup d'outils font confiance à cette garantie erronée.

La leçon pratique rappelle un précédent bien connu dans la cryptographie appliquée: Bitcoin a trébuché sur une symétrie d'ECDSA qui a permis de changer la valeur s par n - s et de modifier l'ID de transaction sans la clé privée; la solution était d'imposer une forme canonique ("low-S") et, dans un changement architectural, de séparer les signatures de l'identification avec SegWit. La recommandation équivalente pour les forges est évidente et technique: canoniser la représentation des signatures avant de vérifier et d'enregistrer un sceau de fiducie. Dans la pratique, cela signifie n'accepter que des formes canoniques (par exemple bas-S pour ECDSA), supprimer ou normaliser les champs non authentifiés OpenPGP et valider / normaliser l'encodage DER dans S / MIME.

Que devrait faire chaque acteur? Pour la forge (GitHub, GitLab, etc.), l'action est claire et urgente: normaliser les signatures avant de les marquer comme vérifié, stocker et revérifier la forme canonisée et invalider les timbres si la signature ou la clé n'est plus canonique ou sont révoqués. Pour les outils qui bloquent par hachage, dédoublent ou calculent la traçabilité, la recommandation est de ne pas faire confiance au hachage brut d'un objet signé entrant: vérifier la signature, la canoniser et ensuite calculer l'identificateur qu'ils utiliseront pour verrouiller ou enregistrer, ou encore baser la déduplication sur les pistes de contenu (tree / blobs) au lieu du hash de l'objet complet commit.

Pour les développeurs et les consommateurs de paquets ou d'Actions, la bonne nouvelle est que les meilleures pratiques ne changent pas racine: continuer à peindre des engagements complets est correct, et l'ancrage également des produits chimiques indépendants des artefacts ou utilisent des systèmes qui vérifient le contenu (par exemple les dérivations de sortie fixes dans Nix) ajoute une sauvegarde qui évite toute sorte de problèmes. Cependant, il y a un ajustement dans la surveillance: le sceau «Vérifié» ne devrait pas être utilisé comme seul critère de sécurité pour accepter ou bloquer le code; ce sceau montre qui a signé, et non pas que le hachage est une identité unique et unbribe.

Le travail de Ginesin a été rapporté aux projets pertinents (Git, GNU et Forges) et, au moins au moment de sa publication, il s'attendait toujours à un spread patch. La communauté a des arrangements conceptuels matures : la canonicalisation des signatures est une pratique bien connue et bien comprise. Le premier point évident de l'attention est S / MIME, où l'outil public reproduit des cas que les git locaux strictes rejettent mais que GitHub accepte comme "Vérifié".

Bref, nous sommes confrontés à un problème de confiance opérationnelle et non d'intégrité du contenu : les fourchettes doivent corriger leur pipeline de vérification afin que la bande « Vérifiée » signifie vraiment ce que les utilisateurs attendent. Dans l'intervalle, les gestionnaires de l'infrastructure de sécurité et d'approvisionnement devraient mettre à jour leur logique de verrouillage et de déduplication pour valider et canoniser les signatures avant de compter sur le hachage, et les développeurs devraient continuer à ancrer les unités avec des hachages complets et, si possible, avec des contrôles supplémentaires et des mécanismes de vérification reproductibles des appareils.

Pour lire le travail et les tests publiés par Ginesin, vous pouvez voir leur liste dans arXiv et jouer les démos; la recherche de l'auteur offre le document et les documents associés en ouvert: arXiv - recherche par Jacob Ginesin. Pour comprendre comment GitHub présente et documente la vérification des signatures dans les engagements, sa page de documentation officielle est un point de référence utile: C'est pas vrai. Docteurs - A propos de la vérification de la signature du commit. Pour vérifier localement les signatures d'engagement et voir comment git gère la vérification, la documentation git sur git-vérify-commit est pratique : git-vérify-commit.