GitHub détaille son blocage des attaques basées sur les collisions SHA-1
Avant l'intégration dans Git
Le 21 mars 2017 à 09h31
4 min
Internet
Internet
L’algorithme de hachage SHA-1 n’est plus en odeur de sainteté depuis que des chercheurs ont montré de quelle manière des collisions pouvaient être exploitées dans des attaques. GitHub, qui l’utilise largement, a expliqué hier soir les mécanismes mis en place pour protéger ses utilisateurs.
Une attaque par collision se base sur l’idée qu’un algorithme puisse produire le même hash pour deux fichiers différents. Véritable bête noire dans ce domaine, une collision peut être exploitée pour faire passer un fichier malveillant comme légitime, ou même pour falsifier une signature électronique. Depuis qu’une équipe de chercheurs en a à nouveau montré les risques fin février (attaque SHAttered), SHA-1 fait justement l’objet d’attentions particulières.
GitHub explique comment il pourrait être attaqué
GitHub a d’ailleurs annoncé hier soir certaines mesures visant à court-circuiter les risques pour les utilisateurs. SHA-1 y est en effet utilisé pour identifier l’ensemble des données hébergées, stockées dans des objets. Il fallait donc empêcher que deux objets puissent obtenir le même hash. Un cas de figure accidentel que l’équipe juge extrêmement improbable. On parle donc bien ici d’une attaque éventuelle.
L’éditeur en explique d’ailleurs les mécanismes. Un pirate commence par générer une paire d’objets identifiés tous deux par le même hash. Il doit convaincre ensuite le développeur d’accepter le fichier innocent et attend qu’il le pousse dans son projet via un commit. Le pirate récupère ensuite le dépôt et le propose au téléchargement en ayant remplacé le fichier innocent par sa version malveillante. La signature SHA-1 générée n’aura pas changé.
Détection d'une attaque qui laisse des traces
Pour GitHub, la force brute reste considérée comme bien trop onéreuse pour SHA-1. Par contre, le modèle d’attaque utilisé par les chercheurs suit une ligne définie et « laisse des traces dans les octets », que l’on peut donc détecter si on en connait la signification. Le service s’occupe de cette étape dans tout calcul SHA-1 opéré. Le code de détection utilisé est open source et a notamment été développé par Marc Stevens, l’un des chercheurs à la base de l’attaque SHAttered.
GitHub indique qu’actuellement, aucune attaque de ce type n’a été détectée. L’éditeur rappelle à ce sujet que même si la théorie est tout à fait valide et qu’il est possible de réaliser de telles opérations, elles sont particulièrement coûteuses en l’état : « des centaines de milliers de dollars de calculs ».
Première étape avant l'intégration dans Git
Par ailleurs, la détection mise en place n’est qu’une première étape. Un travail est en cours avec Git pour l’intégrer directement au cœur du système. Les prochaines versions de Git seront donc à même de détecter les collisions et de rejeter toute opération impliquant des paires de fichiers « collisionnés », et ce pour l’ensemble des opérations, que l’on parle d’application de patchs, génération d’objets ou récupération de données depuis d’autres sites.
Surtout, Git réfléchit actuellement à une transition pour sortir de SHA-1 et basculer sur un algorithme plus sécurisé, par exemple SHA-256. Rien n’a encore été décidé à ce stade, mais GitHub précise qu’il suivra le mouvement quand le projet « aura mûri ».
GitHub détaille son blocage des attaques basées sur les collisions SHA-1
-
GitHub explique comment il pourrait être attaqué
-
Détection d'une attaque qui laisse des traces
-
Première étape avant l'intégration dans Git
Commentaires (21)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 21/03/2017 à 10h23
Pourquoi ne pas passer directement au SHA-512 ?
Je ne comprendrai jamais pourquoi ces grosses boites n’utilisent pas les algo disponibles les plus performants… Contraintes de stockage ou charge CPU ?
Le 21/03/2017 à 10h34
C’est une contrainte de git. Git fonctionne via SHA-1 qui était probablement le bon choix lors de sa création. Github étant basé sur git il hérite donc de cette contrainte.
Si il change ils perde toute compatibilité avec l’écosystème git
Le 21/03/2017 à 10h34
The Git project is also developing a plan to transition away from SHA-1 to another, more secure hash algorithm, while minimizing the disruption to existing repository data. As that work matures, we plan to support it on GitHub.
Dans la source, pas de SHA-256…
Le 21/03/2017 à 10h34
Le 21/03/2017 à 10h37
Tu as raison le SHA-256 devrait être suffisant, ensuite, pour le SHA-1, à l’époque ils pensaient aussi avoir du temps avant qu’on parvienne à le mettre en défaut.
Le 21/03/2017 à 10h38
J’avais complètement oublié que c’est Git même qui impose le SHA-1. Merci de me le rappeler :-)
Le 21/03/2017 à 10h50
Et c’est possible de mettre git à jour ?
Je précise que je ne m’y connais pas beaucoup
Le 21/03/2017 à 10h52
Le 21/03/2017 à 11h02
Le 21/03/2017 à 11h15
Ne pas trop prophétisé sur les évolutions future, ça ne réussit pas en général, de mon avis ils vaut mieux prendre en compte le maximum de paramètre même si cela paraît improbable.
Le 21/03/2017 à 11h16
Là on parle uniquement de résolution via la puissance de calcul brute avec une architecture classique. L’arrivée prochaine (entendre par là dans quelques années, une décénie peut-être) de l’informatique quantique change la donne. Et il me semble que justement les algorithmes de hachage sont beaucoup moins robuste avec une approche via des algorithmes quantique.
Le 21/03/2017 à 11h22
Très bonne remarque, d’autant que SHA-512 est plus rapide que SHA-256 (bien que cela puisse surprendre).
À creuser.
Le 21/03/2017 à 11h26
Cet outil détecte effectivement bien les collisions, en tout cas celles qui sont “dérivées” de shattered.
Par exemple, sur ces fichiers :
http://blog.rom1v.com/assets/shadow/shadow1.pdf
http://blog.rom1v.com/assets/shadow/shadow2.pdf
$ bin/sha1dcsum shadow1.pdf shadow2.pdf
9051ae45aeb14f65c3f6b1d8272f551ed38f94ba coll shadow1.pdf
a8b92b2489cb7d699aaf29aa3c2726abe0d7541b coll shadow2.pdf
Le 21/03/2017 à 11h28
Le 21/03/2017 à 11h34
Effectivement l’informatique quantique nourrit un certain nombre d’espoirs (ou de craintes), je ne sais pas si ça sera généralisable et si oui, dans quelle mesure on pourra inventer des nouvelles méthodes cryptographiques robustes, ne serait-ce que pour le hashage (car pour la communication, on a déjà imaginé des techniques non interceptables).
Je ne sais pas non plus dans quelle mesure l’informatique quantique est autant concernée par la future limite minerai-énergie (cf mon commentaire #14), a priori oui.
Le 21/03/2017 à 12h08
Bon ben dans 130 ans alors.
Voire avant avec D-Wave, BlueMix…
Le 21/03/2017 à 13h27
intéressante analyse " />
Le 21/03/2017 à 21h59
SHA-Bit.
" />
Le 22/03/2017 à 19h16
Le 23/03/2017 à 10h05
Théoriquement oui.
Dans les fait c’est compliqué car il ne faut pas que la mise à jour casse l’existant et rende les dépots de code incompatible.
A mon avis le risque est trop mineur pour s’aventurer dans une mise à jour de cette ampleur.
Le 23/03/2017 à 12h38