IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Un développeur teste dans Webkit les deux fichiers PDF servant de PoC pour la collision de hash sur SHA-1
Et provoque malencontreusement une panne

Le , par Stéphane le calme

349PARTAGES

11  0 
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

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de dourouc05
Responsable Qt & Livres https://www.developpez.com
Le 25/02/2017 à 14:18
Citation Envoyé par Beanux Voir le message
Après le coût de calcul intervient. Selon les support (par exemple les cartes à puces), ce n'est pas forcément possible.
Après dans ce genre de cas (puces crypto etc), c'est surtout un challenge qui est a relever pour permettre l'authentification, et on peut se contenter d'une fonction crypto "moins sur" mais qu'on sait incassable en un temps donné.
BLAKE2 est un finaliste pour SHA-3 : sa sécurité est très proche de Keccak (qui a été choisi comme SHA-3 au terme de la compétition), mais il est plus rapide à calculer que MD5 (https://leastauthority.com/blog/BLAK...-than-MD5.html). Quelle raison reste-t-il d'utiliser MD5, SHA-1 ?
4  0 
Avatar de dourouc05
Responsable Qt & Livres https://www.developpez.com
Le 26/02/2017 à 16:19
Citation Envoyé par Artemus24 Voir le message
Je croyais que le hashage avait pour but de chiffrer un fichier, et c'est tout. Et que vient faire la comparaison entre ces deux fichiers ???
Quel est le but justement de cette comparaison et pourquoi le fait qu'ils produisent la même emprunte provoque un bug ?
Pour reprendre ton parallélisme avec les fonctions modulo : le hachage n'a pas l'objectif de chiffrer quoi que ce soit, juste de donner une empreinte de taille réduite. Un SHA-1 te donne une empreinte de 20 octets : impossible de retrouver le fichier d'origine de façon unique avec seulement ces 20 octets — tout comme il est impossible d'inverser ta fonction modulo pour retrouver 1 000 000 ou 803 depuis 27.

Citation Envoyé par Artemus24 Voir le message
Oui, mais un cas particulier ne peut pas remettre en cause le fonctionnement de ce sha-1.
Justement, ce n'est pas qu'un cas particulier : on a maintenant une technique qui permet de créer des collisions comme et quand on veut, avec des moyens "limités" (en tout cas, rien qui soit hors de portée d'une agence gouvernementale).

Citation Envoyé par Artemus24 Voir le message
Mais ne croyez-vous pas que le principe du hashage, soit complètement utopique ?
On cherche surtout à ce que créer une collision soit extrêmement difficile pour un attaquant. On peut survivre sans une fonction parfaite en sécurité.
4  0 
Avatar de dourouc05
Responsable Qt & Livres https://www.developpez.com
Le 25/02/2017 à 22:11
Citation Envoyé par Artemus24 Voir le message
Désolé pour mon ignorance, mais pourriez vous traduire vos propos au sujet du Hashage.
Dois-je comprendre que le hashage, c'est comme la fonction modulo. On finit tôt ou tard par retrouver le même cycle.
Le principe de ces fonctions de hachage, c'est que deux entrées différentes, même légèrement, donneront deux sorties (empreintes) différentes (voire franchement différentes). Il n'y pas vraiment de notion de cycle. Les chercheurs ont trouvé un moyen de produire une collision, c'est-à-dire trouver deux fichiers qui ont la même empreinte par SHA-1.

Le problème, ici, c'est que SVN détermine si deux fichiers sont différents par un test sur le résultat d'une fonction de hachage : dans l'immensément grande majorité des cas, c'est suffisant ; grâce à cette collision, cette technique a été mise à mal, d'où le problème.
2  0 
Avatar de Iradrille
Expert confirmé https://www.developpez.com
Le 25/02/2017 à 23:25
Citation Envoyé par Artemus24 Voir le message
Dois-je comprendre que le hashage, c'est comme la fonction modulo. On finit tôt ou tard par retrouver le même cycle.
Cycle je sais pas (j'imagine qu'ils essaient d'éviter); mais plusieurs fichiers peuvent avoir le même hash, oui.

Citation Envoyé par Artemus24 Voir le message
Et en quoi la collision a provoqué un gros bug. Je n'ai rien compris de ce problème.
Un fichier est un grand nombre (exemple, un fichier d'1Mo => 2^8096 => ~10^2730); un hash est un "petit" nombre (160 bits pour SHA-1 => ~10^53).

Il n'y a "que" 10^53 hashs différents, et une infinité de fichiers possible en entrée => plusieurs (une infinité) fichiers auront le même hash.
Quand 2 fichiers différents ont le même hash, c'est une collision. Les fonctions de hashages sont faites pour que les collisions soient rares et non prévisibles (preuve de la rareté, le bug de SVN vient seulement d'être trouvé).

Le hashage est utilisé pour vérifier qu'un fichier (ou n'importe quel autre contenu) n'ai pas été altéré (sinon son hash change); si on est capable de créer des collisions, le hashage ne sert plus à rien puisqu'on peut altérer un fichier sans modifier son hash.
2  0 
Avatar de Beanux
Membre éclairé https://www.developpez.com
Le 26/02/2017 à 1:22
Je pense qu'a la base on est partie sur les hash de fichiers, alors que de toute façon, pour les fichiers la collision existe obligatoirement.

@Artemus24, voit la fonction de hashage comme un moyen d'identification de quelque chose, mot de passe fichier ou autre. Là, des chercheurs ont montré qu'on peut trouver un autre fichier/mot de passe qui aurait le même hash/"identifiant".

Pour expliquer plus dans le détail, par exemple, les sites web stockent les mot de passe sous forme de hash (pour simplifier). Si on arrive à récupérer la base de données, tu récupères les hash, et donc tu peux construire un autre mot de passe basé la dessus.
Il y a le même principe avec les torrent. les fichiers sont identifié avec un hash.
Quand tu télécharges un fichier par ce biais, ton client compare le hash et indique si c’est bien le bon fichier. Le fait que deux fichier puissent avoir le même hash, signifie que tu pourrait envoyer un fichier malicieux en lui ayant donné le même hash, via des torrent qui sont sains (exemple, les distributions linux entre autre).

@dourouc05 a priori aucune raison. Même dans le cas de vérifier les téléchargement de fichiers. Mais les habitudes ont la vie dure.
2  0 
Avatar de Beanux
Membre éclairé https://www.developpez.com
Le 27/02/2017 à 3:14
@Artemus24

Donc pour reprendre, le hashage, c’est une fonction. Pas un programme informatique ou autre. Comme la fonction addition (7+8) qui fait qu' l'on prend le premier nombre que l'on ajoute au deuxième, ce qui nous donne 15, ce sont des mathématiques. Il n'y a aucun bug. C'est très important de comprendre cela.
Il peut y avoir des bugs quand on traduit la fonction en un programme. Mais avant ça la fonction de hashage, elle existe en dehors de toute conception informatique, seulement mathématique.

Autre chose juste pour éviter des confusions, si l'on parle de fonction de hachage, il vaut mieux parler de d'encrypter, ou d'utiliser la racine crypter, plutôt que chiffrer. Parce que dans sa définition le chiffrement est réversible, celui du d’encrypter ne l'est pas.

Citation Envoyé par Artemus24 Voir le message

Disons que vous avez une infinité de fichiers, à l'identique des nombres naturels (1, 2, 3, 4, ..., N).
Quand je calcule le modulo 97 de deux nombres, il est possible d'avoir deux nombres différents, qui produises le même reste.
C'est de cela dont je voulais parler.
Pour la comparaison avec le modulo, elle est peu approprié. Parce qu'il n'y a pas de relation d'ordre avec les fonction de hachage.
Cette notion de cycle c'est ce qui est appelé collision, c’est à dire que pour 2 hash donnés, il y a un même résultat.
Oui cela existe, oui toutes les fonctions de hachage ont des collisions (ce que vous avez nommé "cycles", mais ce qui est important c'est de ne pas arriver à partir du hash à trouver un résultat potentiel qui a mené à ce hash.

Citation Envoyé par Artemus24 Voir le message

Le seul moyen de contourner le problème, si j'ai bien compris vos explications à tous, c'est de trouver une autre phrase en clair, qui par le chiffrement, donnera la même phrase chiffrée ci-avant.
Exemple, si je donne le hash "abec64d508a87095ac33f69e1fa40f591b5c5c14", il est a peu près impossible de trouver que "ceci est un hash" a été sa source. Et il est a peu près impossible de trouver un quelconque texte/fichier qui pourrait générer ce hash. Enfin a peu près sauf depuis la publication qui est à l'origine de cet article.
Ici, le modulo est un bon exemple, si on me donne x mod 97 = 3, trouver un x est simple, mais trouver le x que moi j'ai utilisé pour générer ce 3, n'est pas possible. J'ai utilisé 488, mais cela aurait pu être 353374, ou tout aussi bien 3. Sauf que le modulo génère des collision bien trop élevées.

Citation Envoyé par Artemus24 Voir le message

Maintenant, je comprends mieux. L'emprunte est une garantie de la non altérabilité d'un fichier.
Même si le cas qui est ici décrit est fort rare, vis-à-vis de ceci : (160 bits pour SHA-1 => ~10^53), et même en augmentant à 2048 bits, le problème continuera d'exister.
Oui, je sais, le cas avec 2048 bits sera encore plus rare que celui à 160 bits.
Mais ne croyez-vous pas que le principe du hashage, soit complètement utopique ?
L'important n'est pas la probabilité de collision. Qui elle est complétement utopique. Elle est et sera toujours présente. on prend un entrée un nombre infini de possibilité pour le réduire à un nombre fini; Il y aura toujours de collisions, c'est inévitable.
Et ce n’est pas l’important, l'important est qu'il soit impossible ou extrêmement difficile a partir du hash de retrouver sa source (cf exemple au dessus dans mon message), et que les probabilité de collision soit tout de même assez basses pour permettre une sécurité suffisante.

Citation Envoyé par Artemus24 Voir le message

Je ne voie pas trop l'intérêt de ce que vous avancez car l'algorithme de chiffrement est connu de tout le monde.
Je parle bien sûr du chiffrement qui va de la phrase en clair ==> la phrase chiffrée.
Dans votre base de données, vous connaissez que la phrase chiffrée.
L'opération inverse est impossible car la réversibilité du chiffrement n'est pas possible.
Le seul moyen de contourner le problème, si j'ai bien compris vos explications à tous, c'est de trouver une autre phrase en clair, qui par le chiffrement, donnera la même phrase chiffrée ci-avant.

Oui, mais un cas particulier ne peut pas remettre en cause le fonctionnement de ce sha-1.
Justement le papier des chercheur dit qu'a partir du hash, il est possible trouver une phrase en claire qui fournira ce hash. Peut importe si cette phrase en clair a réellement été celle qui a servit à générer le hash. Le problème et qu'a partir du hash, il soit possible de trouver quelque chose qui puisse générer ce hash.

En pratique ça veux dire que si j'ai le hash de votre mot de passe de developpez.net (si ils utilisent ce système, et si ils n'ont pas ajouté d'autres systèmes de sécurité), je peux avoir accès a votre compte sans connaitre votre mot de passe.
Et ça c’est un problème. la possibilité de faire passer pour autre chose quelque chose qui ne l'est pas, en ayant que le hash à sa disposition.
2  0 
Avatar de TiranusKBX
Expert confirmé https://www.developpez.com
Le 28/02/2017 à 8:00
Citation Envoyé par Artemus24 Voir le message
[...]Ok, je comprends mieux ! Mais je ne voie toujours pas l'intérêt de cette multiplicité des hash.
Par analogie, auriez-vous intérêt à mettre plusieurs serrures douteuses sur votre porte, où bien une seule si elle est infalsifiable ?
Toutes les serrures quelles soient de bonne ou mauvaise qualité ne survivent à la perceuse et le foret métal, plus tu à de serrures plus c'est long à ouvrir
2  0 
Avatar de disedorgue
Expert éminent sénior https://www.developpez.com
Le 25/02/2017 à 14:45
Citation Envoyé par Beanux Voir le message
Je partage l'avis de BlueScreenJunky, avec une fonction de hachage, il est impossible de ne pas avoir de collision.
Quelque soit la fonction de hachage, si la taille du hash est plus petit que ce que tu cherches à hacher, il y a obligatoirement un risque de collision.
Pour causer plus math, l'ensemble des résultats de la fonction de hachage (qui est un ensemble fini, vu qu'il a une taille fixe) est un sous ensemble des choses que tu peux hacher (et cet ensemble est infini) parce que tu peux hacher les résultats de ta fonction de hachage. mal dit et un dessin serait plus parlant
Malheureusement, c'est pas toujours vrai dans la vraie vie: même si le hash est plus petit que que le message que l'on hash...
Un exemple flagrant, c'est les mots de passe: on peut avoir un mot de passe qui dépasse la taille de son propre hash mais comme on nous restreint souvent d'avoir un mot de passe de taille min et max et de plus sur jeu d'alphabet réduit, la collision peut ne pas se produire puisque l'ensemble des mot de passe est aussi fini.
1  0 
Avatar de TiranusKBX
Expert confirmé https://www.developpez.com
Le 27/02/2017 à 7:47
Ha! ça me fait marrer
Depuis le temps tous le monde devrait savoir que pour éviter ce problème il faut utiliser à minima 2 algorithmes de Hash et utiliser leur 2 ou plus références, mais non on préfère accorder toute nôtre confiance à une seule serrure sur la porte
1  0 
Avatar de Beanux
Membre éclairé https://www.developpez.com
Le 27/02/2017 à 17:26
Citation Envoyé par Artemus24 Voir le message

Ne peut-on pas trouver une autre technique qui consisterait à verrouiller le fichier et que seul celui qui va l'utiliser pourrait le déverrouiller. Cela garanti aucune falsification, non ?
Il en existe plein d'autre, par exemple, le SHA2 est aussi une fonction de hachage qui elle est encore fiable. Et le SHA3 est aussi la pour proposer une alternative viable au SHA2.

Citation Envoyé par Artemus24 Voir le message

J'avais en tête le chiffrement d'un texte. Or "Dourouc05" me confirme que cela n'a aucun rapport, juste la création d'une emprunte afin de garantir qu'il n'y a, par son auteur, aucune falsification.
Donc les termes de chiffrer ou de crypter ne sont pas appropriés.
Citation Envoyé par Artemus24 Voir le message

Or là, je ne comprends plus très bien. Est-ce pour crypter un texte ou juste garantir que ce texte n'a pas été falsifié ?
Car Dourouc05 dit que c'est une emprunte et vous, un cryptage non réversible.
Le terme crypter est un terme qui est mal utilisé (normalement il n'existe pas) dans la langue française: https://chiffrer.info/
Le mot cryptage (pour moi), peut être employé à cette fin, parce que c'est une méthode à sens unique. Néanmoins je concède que cela prête a confusion.

Citation Envoyé par Artemus24 Voir le message

Je ne suis pas du tout convaincu de ce que vous dites. Dans l'exemple donné du hash sha-1, il y a une emprunte de 160 bits.
Vous pouvez utiliser autant d'algorithme que vous désirez, pour complexifié votre emprunte, au final, elle aura toujours 160 bits.
Je vous invite à lire la page wikipédia des fonctions de hachage. Elle vous expliquera très bien le des fonctions de hachage (la partie considérations mathématique peut être passé).
Mais l’intérêt n’est pas qu'il y ai une unicité absolue des empreintes/hash, c’est la non réversibilité de cette opération qui est importante.
Il est important qu'il y ai un grand nombre d'empreinte aussi, et sur 160 bit, les chercheurs en sécurité ont estimé cela suffisant.

En revanche je ne comprends pas ce que vous mentionnez en parlant de "bug en cascade".
1  0