Comment la nouvelle collision SHA-1 affectée Git?
Récemment, une équipe de chercheurs a généré deux fichiers avec le même hachage SHA-1 ( https://shattered.it/ ).
Étant donné que Git utilise ce hachage pour son stockage interne, dans quelle mesure ce type d'attaque influence-t-il Git?
Edit, fin décembre 2017: Git version 2.16 acquiert progressivement des interfaces internes pour permettre différents hachages . Il y a encore un long chemin à parcourir.
La réponse courte (mais insatisfaisante) est que les fichiers d'exemple ne sont pas un problème pour Git - mais deux autres fichiers (soigneusement calculés) pourrait être.
J'ai téléchargé ces deux fichiers, shattered-1.pdf et shattered-2.pdf, et les placer dans un nouveau référentiel vide:
macbook$ shasum shattered-*
38762cf7f55934b34d179ae6a4c80cadccbb7f0a shattered-1.pdf
38762cf7f55934b34d179ae6a4c80cadccbb7f0a shattered-2.pdf
macbook$ cmp shattered-*
shattered-1.pdf shattered-2.pdf differ: char 193, line 8
macbook$ git init
Initialized empty Git repository in .../tmp/.git/
macbook$ git add shattered-1.pdf
macbook$ git add shattered-2.pdf
macbook$ git status
On branch master
Initial commit
Changes to be committed:
(use "git rm --cached <file>..." to unstage)
new file: shattered-1.pdf
new file: shattered-2.pdf
Même si les deux fichiers ont la même somme de contrôle SHA-1 (et affichent principalement la même chose, bien que l'un ait un fond rouge et l'autre un fond bleu), ils obtiennent des hachages Git différents :
macbook$ git ls-files --stage
100644 ba9aaa145ccd24ef760cf31c74d8f7ca1a2e47b0 0 shattered-1.pdf
100644 b621eeccd5c7edac9b7dcba35a8d5afd075e24f2 0 shattered-2.pdf
Ce sont les deux sommes de contrôle SHA-1 pour les fichiers stockés dans Git : l'un est ba9aa... et l'autre est b621e.... 38762c.... Mais - pourquoi?
La réponse est que Git stocke les fichiers, non pas comme eux-mêmes, mais plutôt comme la chaîne littérale blob, un blanc, la taille du fichier décimal et un ASCII octet NUL, et puis les données du fichier. Les deux fichiers ont exactement la même taille:
macbook$ ls -l shattered-?.pdf
... 422435 Feb 24 00:55 shattered-1.pdf
... 422435 Feb 24 00:55 shattered-2.pdf
donc les deux sont préfixés avec le texte littéral blob 422435\0 (où \0 représente un seul octet, un la C ou Python octal s'échappe dans les chaînes).
Peut-être de façon surprenante - ou non, si vous savez quoi que ce soit sur la façon dont SHA-1 est calculé - en ajoutant le même préfixe à deux fichiers différents qui ont néanmoins produit le même somme de contrôle avant , les amène à produire maintenant différents sommes de contrôle.
La raison pour laquelle cela ne devrait pas surprendre est que si le résultat final de la somme de contrôle n'était pas extrêmement sensible à la position , ainsi que la valeur, de chaque bit d'entrée, il serait facile de produire des collisions à la demande en prenant un fichier d'entrée connu et en réorganisant simplement certains de ses bits. Ces deux fichiers d'entrée produisent la même somme malgré un octet différent à char 193, line 8, mais ce résultat a été obtenu, selon les chercheurs, en essayant plus de 9 quintillions ( échelle courte ) d'entrées. Pour obtenir ce résultat, ils ont placé des blocs de données brutes soigneusement choisis, à une position qu'ils contrôlaient, qui affectaient les sommes, jusqu'à ce qu'ils trouvent des paires de entrées qui ont entraîné une collision.
En ajoutant l'en-tête blob, Git a déplacé la position , détruisant les 110 années-GPU de calcul en un seul accident plus ou moins accidentel rot.
Maintenant, sachant que Git fera cela, ils pourraient répéter leurs 110 années de calcul GPU avec des entrées commençant par blob 422435\0 (à condition que leurs blocs sacrificiels ne soient pas trop poussés; et le nombre réel d'années-GPU de calcul nécessaires varierait probablement, car le processus est un peu stochastique ). Ils trouveraient alors deux fichiers différents dont l'en-tête blob pourrait être supprimé. Ces deux fichiers auraient désormais des sommes de contrôle SHA-1 différentes, mais lorsque git add- ed, les deux produiraient la même somme de contrôle SHA-1.
Dans ce cas particulier, le premier fichier ajouté "gagnerait" l'emplacement. (Supposons qu'il s'appelle shattered-3.pdf.) Un Git assez bon - je ne suis pas du tout sûr que le Git actuel soit aussi bon; voir Réponse basée sur l'expérience de Ruben à Comment Git gérerait-il une collision SHA-1 sur un blob? - remarquerait que git add shattered-4.pdf, tentant d'ajouter le deuxième fichier, est entré en collision avec le premier mais différent shattered-3.pdf et vous avertirait et échouerait le git add étape. Dans tous les cas, vous ne pourrez pas ajouter ces deux fichiers à un seul référentiel.
Mais d'abord, quelqu'un doit dépenser beaucoup plus de temps et d'argent pour calculer la nouvelle collision de hachage.
Peut-être que la réponse de Linus pourrait faire la lumière:
Une personne de l'IIRC a travaillé sur le paramétrage des hypothèses SHA1 de git afin qu'un référentiel puisse éventuellement utiliser un hachage plus sécurisé. Jusqu'où cela est-il allé? Il y a encore beaucoup de "40" constantes dans git.git HEAD.
Je ne pense pas que vous souhaitiez nécessairement changer la taille du hachage. Vous pouvez utiliser un hachage différent et utiliser simplement les mêmes 160 bits.
Puisque nous avons maintenant des collisions dans des fichiers PDF PDF valides), des collisions dans des objets valides de validation et d'arborescence git peuvent probablement être construites.
Je n'ai pas encore vu l'attaque, mais git ne fait pas que hacher les données, il y ajoute un champ type/longueur. Cela a généralement tendance à rendre les attaques par collision beaucoup plus difficiles, car vous devez également rendre la taille résultante identique, ou vous devez également pouvoir modifier le champ de taille dans l'en-tête.
les pdf n'ont pas ce problème, ils ont un en-tête fixe et vous pouvez ajouter arbitrairement des données silencieuses au milieu qui ne sont tout simplement pas affichées.
Les fichiers PDF constituent donc un bien meilleur vecteur d'attaque, précisément parce qu'ils sont un format de données assez opaque. Git a des données opaques à certains endroits (nous cachons des choses dans les objets de validation intentionnellement, par exemple, mais par définition, ces données opaques sont assez secondaires.
Autrement dit: je doute que le ciel tombe pour git en tant qu'outil de gestion du contrôle des sources. Voulons-nous migrer vers un autre hachage? Oui. Est-ce "game over" pour SHA1 comme les gens veulent le dire? Probablement pas.
Je n'ai pas vu les détails de l'attaque, mais je parie
(a) le fait que nous ayons un encodage de taille séparé le rend beaucoup plus difficile à faire sur les objets git en premier lieu
(b) nous pouvons probablement facilement ajouter quelques vérifications de santé mentale supplémentaires aux données opaques que nous avons, pour rendre beaucoup plus difficile de cacher les données aléatoires dont dépendent ces attaques.
Linus