Journal md5 (encore) mis à mal

Posté par  (site web personnel) .
Étiquettes : aucune
0
23
sept.
2005
Ben voila, tout est dans le titre.
Un petit gars qui programme en C# a codé des petits programmes permettant de camoufler 2 binaires dans un fichier ayant le même md5.
L'article: http://www.codeproject.com/useritems/HackingMd5.asp(...)

un commentaire sur slashdot interessant:
deux pages html avec le meme md5:
http://www.doxpara.com/t1.html(...)
http://www.doxpara.com/t2.html(...)

c'est bluffant (si on regarde pas le code source).

  • # slashdot

    Posté par  (site web personnel) . Évalué à 4.

    l'article sur slashdot : http://it.slashdot.org/it/05/09/23/0618252.shtml?tid=172&tid=93(...)

    C'est un exemple de collision de hash (j'ai pas trop bien compris tes explications) : en gros 2 ISOs pourraient avoir le même md5sum.

    Ceci est aussi possible avec RSA (un peu plus dur néanmoins) je crois (chercher RSA-200), ou je confonds tout...

    • [^] # Re: slashdot

      Posté par  . Évalué à 10.

      Je ne vois pas ce qu'il y a de bluffant. c'est un peu le principe des hash.
      Si tu trouves un algo de hash sans collision alors cela signifie que tu as une bijection entre ton message et ton hash. Cet algo te permet donc de reconstruire le message de départ d'après le hash.
      Et là t'as trouvé un super algo de compression ;-)

      • [^] # Re: slashdot

        Posté par  . Évalué à 10.

        ou un hash de grosse taille

      • [^] # Re: slashdot

        Posté par  . Évalué à 10.

        Le problème n'est pas qu'il soit possible de trouver une collision, mais que ceci soit possible sans utiliser la force brute, autrement dit, dans un laps de temps raisonnable.

        Tom

        • [^] # Re: slashdot

          Posté par  . Évalué à 10.

          En fait, il faut même plus pour que ce soit intéressant.

          Que toto.c ait un hash commun avec
          un truc plus ou moins aléatoire, ce n'est pas bein grave.

          Là où ça peut devenir génant, c'est si on arrive à provoquer
          des collitions entre

          toto.c et toto_backdoor.c

          • [^] # Re: slashdot

            Posté par  . Évalué à -9.

            Commentaire tout à fait pertinent.

          • [^] # Re: slashdot

            Posté par  (site web personnel) . Évalué à 2.

            C'est ce qu'il se passe ici, enfin presque : on fait un toto.exe et un toto_backdoor.exe

          • [^] # Re: slashdot

            Posté par  . Évalué à 8.

            En fait oui, on peut 'facilement', mais pour faire cela, il faut être l'auteur de toto.c

            De ce que j'ai lu, il y a une 'entête particulière' qui doit être mis dans toto.c et toto_backdoor.c pour que cela fonctionne, ce qui limite un peu tout de même la porté de la chose, et du fait c'est 'reconnaissable' par 'signature'. en effet le nombres de "vecteur" qui font collisions ne sont pas infini, et ils ne sont pas facile à trouver.

          • [^] # Re: slashdot

            Posté par  (site web personnel) . Évalué à 5.

            Que toto.c ait un hash commun avec un truc plus ou moins aléatoire, ce n'est pas bein grave.

            L'attaque utilisée ne produit pas un machin aléatoire mais deux fichier très proches. En fait on utilise un propriété de md5 (appelée length extension) qui ne fait que seul le début des fichiers est différent. L'objectif est de produire deux fichiers du genre : si (X) alors A sinon B où seul X varie pour donner soit A, soit B.

            Un des risque est d'obtenir des signatures identiques sont des fichiers très différent. Par exemple, on produit deux fichiers avec le même md5 l'un contenant Je donne 1.000.000¤ à Toto et l'autre Toto me donne 1.000.000¤. Je fais signer le 1er message à Toto avec une signature (par exemple RSA/Md5). Puis je vais voire un notaire mais avec le 2e fichier, la signature est aussi valable. Bien sûr c'est complètement théorique puisque avec l'attaque actuelle un examen des fichiers montrerait la supercherie.

            Pour info : deux fichiers postscript aec le même hash md5 mais au contenus bien différents : http://www.cits.rub.de/MD5Collisions/(...)

            Pour la petite histoire, l'attaque a été publiée il y a plusieurs mois par une équipe de cryptographes chinois qui avait mal implémenté le md5. Le premier papier publié cassait en fait un algo proche de md5 mais avec un problème d'endianness. Une version corrigée du papier a ensuite été publié quelques heures plus tard.

  • # Comme répété auparavant

    Posté par  . Évalué à 10.

    Le md5 est surtout utilisé actuellement pour vérifier qu'un transfert s'est fait correctement. Il ne sert normalement pas à authentifier l'origine ou à certifier que le fichier est sûr.

    • [^] # Re: Comme répété auparavant

      Posté par  (site web personnel) . Évalué à 9.

      il est tres utilise malheureusement pour la verification des mot de passe aussi...

      • [^] # Re: Comme répété auparavant

        Posté par  . Évalué à 10.

        a zut j'avais oublié cette application de MD5 mais ça change rien à la situation actuelle puisque pour trouver une séquence avec le même MD5sum il faut en essayer plusieurs donc ça revient à faire une attaque par force brute ce qui peut être très long.

        Je n'ai pas lu comment trouver 2 séquences défférentes avec le même MD5sum il y a une méthode particulière ou faut essayer toutes les possibilités? si il y a une méthode c'est peut être plus rapide que la force brute mais encore faut t'il avoir la séquence de départ donc une situation peu probable quand on cherche un mot de passe.

  • # idée amusante mais...

    Posté par  . Évalué à 5.

    ça ne change pas grand chose au statut de MD5. Un gars a démontré qu'il existe des collision MD5 mais elles ne sont pas facile à trouver, la preuve il n'en fourni qu'une. ça prouve que MD5 n'est pas sûr pour une fonction de sécurité mais en tant que fonction de vérification d'intégrité des données elle garde tout son sens : la probabilité que 2 fichiers différents produise le même hachage MD5 est très faible dont lorsqu'un système d'installation installe un programme il utilise MD5 pour s'assurer que le fichier utilisé est correctement récupéré (intégrité des donnée) mais il ne donne aucune garantie sur l'origine du fichier (il y a GPG pour ça ).

    En plus dans l'exemple décrit il faut que le pirate fournisse un installateur modifié et 2 archives qui contiennent chacunes le bon programme et le mauvais programme. Quel est l'intérêt pratique (ok c'est un bon exercice intellectuel) de diffuser une archive qui contient un code malveillant non activé puis ensuite une autre avec le code malveillant activé? autant directement diffuser l'archive avec le code malveillant.

    • [^] # Re: idée amusante mais...

      Posté par  . Évalué à 6.

      la probabilité que 2 fichiers différents produise le même hachage MD5 est très faible

      Non ! Le principe du hash de fichier n'est pas là !

      Le but est d'obtenir une fonction pour laquelle :
      1 - toutes les valeurs sont équiprobables
      2 - le hash de deux fichiers peu différents impliquent des valeurs très différentes

      Mais rien n'est dis dans le cas où les fichiers sont très différents, tout simplement parce qu'on essaie de résumer des centaines de Mo en qq octets, et il est illusoire de dire qu'il n'existe pas (ou même qu'il n'y a pas bcp) de fichiers ayant le même hash.

      Du coup, les attaques sont à rechercher dans les fichiers très différents ...

      • [^] # Re: idée amusante mais...

        Posté par  . Évalué à 4.

        Les attaques sont surtout à rechercher dans les fichiers spécialement préparés pour l'occasion.

        L'exemple suivant le montre très bien http://www.cits.rub.de/MD5Collisions/(...)

        Les fichiers concernés ne sont pas très différents.

        Par contre, ils n'ont pas la même taille. Il s'impose donc, quand on base des verifs sur le md5, de ne pas oublier de vérifier la taille du fichier.

  • # oui mais

    Posté par  (site web personnel) . Évalué à 10.

    oui mais si j'ai bien compris l'article il ne s'agit pas de trouver une collision avec un fichier existant mais à partir d'un fichier en trouver deux autres qui sont en collision.

    Tu as au départ une source S1, tu as à l'arrivée une source S2 et une collision C. S1 et S2 n'ont pas la même taille ni le même hash.

    La conséquence :
    - ça ne permet pas de pervertir un fichier qui a déjà été distribué par un tiers (puisque S1 != S2 et avec des hash différents)
    - ça n'est pas extensible à tous les formats ou toutes les données (dans un exe il est facile de rajouter des bits morts, dans d'autres formats c'est impossible ou limité)
    - ca ne permet pas de fausser les mots de passe gérés avec un algo basé sur md5


    Ce que ça permet c'est par contre préparer un code méchant et un code gentil, diffuser le gentil, puis plus tard, l'air de rien, diffuser le méchant pendant un ou deux jours sans changer le md5. Ca demande quand même une mauvaise foi sur le distributeur initial dès le départ (ce qui n'empeche pas que ce soit gênant, on est d'accord).
    Reste aussi que même dans les formats où c'est possible de rajouter des bits morts pour générer la collision, il n'est pas impossible que ce soit visible (pour ceux qui savent comment est fait un binaire, je pense qu'il doit être visible qu'un gros flot d'octet est inutilisé à la fin).

    • [^] # Re: oui mais

      Posté par  . Évalué à 2.

      Ce que ça permet c'est par contre préparer un code méchant et un code gentil, diffuser le gentil, puis plus tard, l'air de rien, diffuser le méchant pendant un ou deux jours sans changer le md5. Ca demande quand même une mauvaise foi sur le distributeur initial dès le départ (ce qui n'empeche pas que ce soit gênant, on est d'accord).

      Heu, c'est tout de même inquiétant ! On peut imaginer que dans quelques temps des éditeurs de sécurité en mal d'idée, ayant vendu des firewalls et des antivirus à tout le monde se disent qu'ils peuvent faire plus d'argent en vendant également des vérificateurs d'intégrité du système à la tripwire. L'utilisateur lambda se sent en sécurité.
      D'un autre côté, on a un éditeur A qui vend un logiciel. Le logiciel est enregistré par le vérificateur d'intégrité. Sauf que A avait trifouillé son logiciel pour pouvoir par la suite faire des modifications tout en by-passant le vérificateur d'intégrité. Du genre A dit: "bon, maintenant, c'est fini le piratage, maintenant nos logiciels envoient des informations à nos serveurs pour vérification". Et bah, l'utilisateur lambda il se dira : "dans ses rêves ! m'en fous, mon vérificateur d'intégrité me dira si son logiciel change ! j'suis tranquille !"

      Bref, scénario catastrophe. Mais bon même si ça a une probabilité de 1% de se produire, faut pas l'oublier !

      • [^] # Re: oui mais

        Posté par  (site web personnel) . Évalué à 2.

        Oui oui. En même temps :
        - si c'est du close source y'a pas besoin de changer le soft pour faire ça, suffit que la fonctionnalité soit déjà présente et qu'elle ne soit qu'activée par la suite (par rapport à une date par exemple). Le hash n'a pas changé, le soft n'a pas changé, pas besoin de collision md5.
        - si c'est de l'open source on verra des trucs bizarres dans les sources

        - dans tous les cas annexer la taille au md5 (chose qu'on vérifie souvent) montrera le problème.

        Ceci dit oui, c'est inquiétant.

  • # Même hash et même taille ?

    Posté par  . Évalué à 8.

    Le même hash Ok, mais le même hash et la même taille de fichier ça paraît plus difficile.

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 4.

      Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: Même hash et même taille ?

        Posté par  . Évalué à 4.

        "De toute façon, on n'a qu'à passer à sha1sum et le problème est réglé pour quelques temps non ? :)"

        Heuu non..... SHA1 est en passe d'etre atomisé aussi. Pour l'instant il tiens par des bouts de ficelle. on en est a du 2^69 (je crois) donc atteignable par un ordi.

        Actuellement c'est un peu la panic chez les crypto (enfin autant que ca peut être la planic chez des universitaires ;-) ). Ils sont en train de se mettre a rechercher un nouveau algo de hash car tous les autres vont tomber a plus ou moins long terme

        • [^] # Commentaire supprimé

          Posté par  . Évalué à 3.

          Ce commentaire a été supprimé par l’équipe de modération.

          • [^] # Re: Même hash et même taille ?

            Posté par  (site web personnel) . Évalué à 2.

            «Sinon, il reste la solution la plus sûre actuellement : signer les fichiers avec GPG. »

            Si mes souvenirs sont bons, GPG utilise lui même le SHA1 ou un autre hash du même style, ce n'est donc pas une solution

            • [^] # Re: Même hash et même taille ?

              Posté par  . Évalué à 2.

              effectivement gpg est basé sur des fonctions de hashages standart ; donc il ne depend pas que de sha1.
              gpg est un outil de chiffrement pas de hash .

              Quand aux autres fonctions de hash crypto forte (> à 2^80) on en connais : ripemd160 , whirlpool, sha-256 et > etc...

              • [^] # Re: Même hash et même taille ?

                Posté par  (site web personnel) . Évalué à 4.

                Le problème c'est que concernant les autres fonctions de hash, soit elles n'ont été que peu étudiées (ripemd, whirlpool...) et par conséquent on a peu d'infos sur de potentielles attaques, soit elles commencent à avoir du plomb dans l'aile. On a désormais une attaque réaliste sur sha1, sha-256, sha-384 et sha-512 tiennent encore mais pour combien de temps ? C'est pour cette raison de la communauté des cryptographes s'est soudain senti ces derniers mois une nouvelle passion pour les algos de hash.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.