Il y a quelques jours, 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.Ils ont mis à jour le site web dédié à l’évènement autour de la collision de hash pour indiquer des conséquences sur certains systèmes à l’instar de GIT. La raison ? « 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 ».
Pour rappel, Linus Torvalds et d'autres développeurs de noyau Linux ont créé GIT en 2005 comme système de contrôle de version distribué de Linux. Il est également utilisé par de nombreuses grandes entreprises, y compris Facebook, Google et Twitter, pour gérer leurs bases de code. GIT est également utilisé dans GitHub, l’un des sites de gestion de code source les plus populaires au monde.
Raison pour laquelle Linus Torvalds s’est penché sur le problème et a livré les résultats de son analyse.
« Tout d'abord, le ciel ne nous tombe pas sur la tête. Il y a une grande différence entre utiliser d'un hachage cryptographique pour des choses comme une signature de sécurité et s’en servir pour générer un "identificateur de contenu" d’un système de contenu-adressable comme git », a assuré Linus.
La différence résidant donc dans la raison de l’utilisation. « Un hachage qui est utilisé pour la sécurité est essentiellement une déclaration de confiance : et si vous pouvez tromper quelqu'un, vous pouvez l’emmener à vous faire confiance même quand il ne devrait pas vraiment ». Raison pour laquelle « lorsqu'un tel hachage est rompu, la raison même du hash disparaît fondamentalement ».
En revanche, dans un projet comme git, le hachage n'est pas utilisé pour la « confiance » : « notre confiance est dans les gens, et puis nous finissons par avoir beaucoup de mesures technologiques en place pour sécuriser les données réelles ». La raison de l'utilisation d'un hachage cryptographique dans un projet comme git est parce qu'il garantit à peu près qu'il n'y a pas d'affrontements accidentels, et est également excellent dans la détection d’erreurs ; même s’il n’est pas en mesure de corriger les erreurs, il est très bon lorsqu’il faut détecter les données corrompues.
« Deuxièmement, la nature particulière de cette attaque SHA-1 signifie qu'elle est réellement assez facile à atténuer, et il y a déjà eu deux ensembles de correctifs affichés pour cette atténuation », a-t-il continué. Linus note deux choses :
- l'attaquant ne peut pas simplement générer une collision aléatoire, mais doit être capable de contrôler et de générer à la fois le « bon » et le « mauvais » objet ;
- vous pouvez réellement détecter les signes de l'attaque dans les deux côtés de la collision.
Linus explique que la première remarque implique qu’il est vraiment difficile de cacher l'attaque dans des données qui sont transparentes (par données transparentes, il parle du fait que « vous voyez réellement et réagissez à toutes les données, au lieu d’avoir une espèce de “ bulle ” de données qui agit comme une boîte noire et ne vous permet de ne voir que les résultats finals).
« Dans les exemples PDF, le format PDF a agi comme "la boîte noire", et ce que vous voyez est l'impression qui a seulement une relation très indirecte au codage de pdf. Mais si vous utilisez git pour le contrôle de source comme dans le noyau, les choses dont vous vous souciez vraiment est le CODE SOURCE, qui est très transparent », a-t-il rappelé. « Alors, fondamentalement, si les données dont vous vous souciez principalement sont ce genre de code source transparent, l'attaque est assez limitée. Vous VERREZ l'attaque. Elle ne va pas silencieusement modifier vos données devant vous ».
En plus de ces arguments, Linus rappelle « qu’il y a effectivement une transition assez simple vers un autre hash qui ne va pas briser le monde - ou même de vieux dépôts git ». Il a expliqué que git finira par s'éloigner de SHA1 : « il y a un plan, il ne semble pas du tout mauvais, et vous n'aurez même pas à convertir votre dépôt ».
Source : billet Linus Torvalds
Et vous ?
Que pensez-vous des raisons qu'il a évoquées ? 
Envoyé par Artemus24
