Jeudi dernier, une équipe composée de chercheurs issus du Centrum Wiskunde et Informatica (CWI, Pays-Bas) et de Google a annoncé avoir mis au point une méthode pour briser l'algorithme SHA-1 qui a longtemps été utilisé pour vérifier l'authenticité des documents numériques. Dans le cadre de la rédaction détaillée de leur réalisation, les chercheurs ont également publié deux fichiers PDF comme preuve de la collision réalisée, les deux fichiers ayant des hachages SHA-1 identiques, mais affichant des contenus différents.Mais le PoC a provoqué involontairement sa première victime : le système de contrôle de versions utilisé par le moteur de navigateur Webkit a été corrompu après qu’un individu a téléchargé les deux fichiers PDF, qui ont été utilisés comme PoC, sur le référentiel Webkit. Le bogue réside dans Apache Subversion (souvent abrégé SVN, d’après le nom de sa commande svn), un système de contrôle de versions open source que WebKit et d'autres grandes organisations de développement de logiciels utilisent pour garder une trace du code soumis par les membres individuels.
SVN utilise SHA-1 pour trouver et fusionner des fichiers en double. Cependant, lorsque le système a rencontré les deux fichiers PDF qui ont servi à créer la collision SHA-1, SVN a fait l’expérience d’un bogue qui a engendré des erreurs.
Selon le rapport de bogue, le dépôt WebKit a été corrompu jeudi lorsque quelqu’un a voulu tester comment le système aurait géré les PDF. Presque immédiatement, le système a connu des échecs. Les erreurs se sont poursuivies jusqu'à vendredi et ont finalement poussé un utilisateur à demander : « est-ce qu’il est possible de résoudre ce problème ? Est-ce que nous allons devoir supprimer tout l’historique SVN depuis ce commit du serveur afin d'éviter la collision hash ? ». Les réponses indiquent que le dépôt est resté au moins partiellement endommagé même après la suppression des fichiers PDF. D’ailleurs, un message sur une liste de diffusion de WebKit a indiqué que les systèmes de mise en miroir ont été dans l’incapacité d'être mis à jour.
Sur le site dédié à l’évènement autour de la collision de hash (partage des fichiers ayant servis au PoC, séance de Q&R sur ce qui est impliqué et différentes informations relatives à SHA-1) qui a été mis à jour, les chercheurs ont précisé que SVN est affecté : « s'il vous plaît, faites attention, étant donné que les collisions des fichiers SHA-1 brisent actuellement les dépôts SVN. Les serveurs Subversion utilisent SHA-1 pour la déduplication et les référentiels sont corrompus lorsque deux fichiers collisionnels sont affectés au référentiel. Cela a été découvert dans le référentiel Subversion de WebKit et confirmé de manière indépendante par nous. Nous avons remarqué que dans certains cas, en raison de la corruption, d'autres commits sont bloqués ».
Mais SVN n’est pas le seul affecté étant donné que GIT n’est pas épargné. « GIT s'appuie fortement sur SHA-1 pour l'identification et la vérification de l'intégrité de tous les objets de fichier et commits. Il est essentiellement possible de créer deux référentiels GIT avec le même hachage commit de tête et différents contenus, par exemple un code source bénin et un disposant d’une porte dérobée. Un attaquant pourrait potentiellement servir sélectivement l’un ou l’autre des dépôts aux utilisateurs ciblés. Cela exigera des attaquants de calculer leur propre collision », ont noté les chercheurs.
Si Firefox avait l’intention de considérer SHA-1 comme étant insécurisé au début de cette année, cette expérience a précipité son action : depuis le 24 février 2017, SHA-1 est désormais déprécié.
Source : SHAttered, liste de diffusion Webkit, Webkit BugZilla
Envoyé par Beanux
, mais ce qui est important c'est de ne pas arriver à partir du hash à trouver un résultat potentiel qui a mené à ce hash.
