mardi 07 octobre
Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Derniers journaux de patrick_g :

Journal : SquirrelMail compromis

Posté par patrick_g (page perso, ) le 19 décembre 2007
0
SquirrelMail est un logiciel de webmail écrit en PHP et disponible sous licence GPL.
Apparemment les versions 1.4.11 et 1.4.12 ont été compromises et les packages qui étaient disponibles en téléchargement sur le site ( http://squirrelmail.org/index.php ) contenaient une modification permettant de prendre le contrôle du serveur exécutant SquirrelMail.

"While initial review didn't uncover a need for concern, several proof of concepts show that the package alterations introduce a high risk security issue, allowing remote inclusion of files. These changes would allow a remote user the ability to execute exploit code on a victim machine, without any user interaction on the victim's server. This could grant the attacker the ability to deploy further code on the victim's server.
We STRONGLY advise all users of 1.4.11, and 1.4.12 upgrade immediately.".

La version de dev 1.5.1 est également compromise : http://thread.gmane.org/gmane.mail.squirrelmail.user/33503

Le problème a été détecté car les sommes de contrôles MD5 des versions téléchargées ne correspondaient pas avec celles publiées sur le site.
Une version saine 1.4.13 est maintenant disponible est les utilisateurs des deux versions antérieures sont invités à mettre à jour d'urgence leur application.

Sur LWN les commentaires se sont orientés sur la résistance réelle de MD5 et sur l'urgence qu'il y aurait à basculer vers SHA-1 ou SHA-256.

En définitive cette affaire est quand même une invitation a toujours vérifier la somme de contrôle quand on télécharge un logiciel sur le net.

> Lire le journal (13 commentaires, moyenne: 1,4).  

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

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

Vérifier la somme ?

Posté par Alexis (page perso, ) le 19/12/2007 à 14:19. (lien). Évalué à 1.

> En définitive cette affaire est quand même une invitation a toujours vérifier la somme de contrôle quand on télécharge un logiciel sur le net.

D'un côté, si le pirate réussit à balancer son paquet piégé à la place du vrai, il doit pas avoir beaucoup de mal à remplacer le fichier signature qui va avec (c'est bien ça la somme de contrôle ?). Et ça m'étonnerait que ce fichier soit vérifié plus souvent que le paquet en question.

  • [^]Re: Vérifier la somme ?

    Posté par imalip (page perso, ) le 19/12/2007 à 14:44. (lien). Évalué à 2.

    C'est pour ca qu'on signe le fichier contenant le md5 avec sa clef GPG :)

    --
    "While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal

    • [^]Re: Vérifier la somme ?

      Posté par boklm (page perso, ) le 19/12/2007 à 15:31. (lien). Évalué à 2.

      Et c'est donc pour ca que verifier la somme de controle ne suffit pas.

  • [^]Re: Vérifier la somme ?

    Posté par Thomas Douillard () le 19/12/2007 à 15:58. (lien). Évalué à 2.

    Donc avoir le MD5 ailleurs que sur le site web ça peut être pas mal ...

Tu laggue un peu.

Posté par Thomas Pedoussaut (page perso, ) le 19/12/2007 à 14:19. (lien). Évalué à 1.

En etant inscrit aux bonnes listes (TM), j'etais au courant depuis le 14 en fin d'apres midi.
http://secunia.com/advisories/28095/

  • [^]Re: Tu laggue un peu.

    Posté par matthieu bollot (page perso, ) le 19/12/2007 à 18:31. (lien). Évalué à 1.

    Han ! et pourquoi t'as pas fait de journal ?!

Rapport avec la faiblesse de MD5?

Posté par Zenitram (page perso, ) le 19/12/2007 à 14:29. (lien). Évalué à 2.

Euh... Le problème a été détecté gràce au checksum MD5, donc il a rempli son boulot...
Donc pourquoi parler de la faible résistance d'un hash qui a fait son boulot?

Je ne vois aucun gain à basculer vers SHA-1 ou 256 dans ce cas précis...

  • [^]Re: Rapport avec la faiblesse de MD5?

    Posté par Julien Fontanet (Jabber id, page perso, ) le 19/12/2007 à 14:38. (lien). Évalué à 1.

    Je crois que l'on a trouvé des failles statistiques sur MD5 qui permettent de facilement créer des fichiers avec des hashs identiques.

    Ces failles n'existent pas à ce jour en sha 256 (enfin il me semble).

    • [^]Re: Rapport avec la faiblesse de MD5?

      Posté par TeXitoi (Jabber id, page perso, ) le 19/12/2007 à 14:56. (lien). Évalué à 2.

      Non, il existe des algos pour trouver deux suites de bits avec la même somme md5 en un nombre d'opération inférieur à celui donnée théoriquement (voir le paradoxe des dates d'anniversaires).

      Par contre, fabriquer un fichier avec une somme md5 donné, il n'y a rien là dessus à ma connaissance, et même si ca existait, pour que ce fichier contienne ce qu'on veux, laisse tomber, déjà, pour avoir un fichier avec la même somme md5 qui soit réellement un tar.gz, ca doit être très très très dur...

      Donc pas vraiment de risque avec le md5 pour cette utilisation, même s'il est vrai que ca coute pas beaucoup plus cher de mettre les autres hashs en même temps.

      • [^]Re: Rapport avec la faiblesse de MD5?

        Posté par Brice Arnould ( un_brice ) (page perso, ) le 19/12/2007 à 15:31. (lien). Évalué à 1.

        déjà, pour avoir un fichier avec la même somme md5 qui soit réellement un tar.gz, ca doit être très très très dur...

        C'est fait ici pour des archives autoextractibles : http://eprint.iacr.org/2004/356
        Et je suppose que ça pourrait être transposé très facilement aux tarballs vu que tar ignore les données consécutives à celles qu'il est censé traité.

        Le papier présente aussi un schéma d'attaque. En résumé :
        Le gars qui veut détruire le monde crée un programme indispensable et le distribue avec à la fin un padding qui permet une collision.
        Le code est audité par Théo de Raadt, Bruce Schneier et Superman, tout va bien.
        Il dit à son ftp de publier une version qui installe un ver quand c'est un packageur qui la télécharge (en utilisant une liste d'IPs, l'user agent ou ce qu'il veut). Cette version a le même MD5.
        Il détruit le monde.

        --
        Respect à RMS.

      • [^]Re: Rapport avec la faiblesse de MD5?

        Posté par Brice Arnould ( un_brice ) (page perso, ) le 19/12/2007 à 15:33. (lien). Évalué à 1.

        déjà, pour avoir un fichier avec la même somme md5 qui soit réellement un tar.gz, ca doit être très très très dur...

        C'est fait ici pour des archives autoextractibles : http://eprint.iacr.org/2004/356
        Et je suppose que ça pourrait être transposé très facilement aux targz vu que tar ignore les données consécutives à celles qu'il est censé traité.

        Le papier présente aussi un schéma d'attaque. En résumé :
        Le méchant qui veut détruire le monde crée un programme indispensable et le distribue avec à la fin un padding qui permet une collision.
        Le code est audité par Théo de Raadt, Bruce Schneier et Superman, tout va bien.
        Le méchant dit à son ftp de publier une version qui installe un ver quand c'est un packageur ou un système de build qui la télécharge (en ayant une liste d'IPs ou avec l'user agent).
        Il détruit le monde.

        --
        Respect à RMS.

      • [^]Re: Rapport avec la faiblesse de MD5?

        Posté par Ackira () le 19/12/2007 à 15:34. (lien). Évalué à 1.

        Ce que tu dis est facilement réalisable... Il suffit de trouver de la place pour une suite de bits suffisament grande dans le fichier (il y a tellement de formats de fichiers avec des tronçons inutilisés...)
        Je te renvois pour cela à cette étude:
        http://www.win.tue.nl/hashclash/Nostradamus/
        Des chercheurs ont créé et publié 10 fichiers pdf au contenu différent avec la même somme MD5.

        Donc oui, MD5 est mort et enterré (du moins pour la sécurité).

Rappel sur l'intégrité et l'authenticité

Posté par L () le 19/12/2007 à 14:58. (lien). Évalué à 1.

La somme de contrôle MD5/SHA* ne permet que de vérifier l'intégrité d'un fichier après téléchargement. Si l'archive compromise et la somme de contrôle MD5/SHA* sont sur le même serveur compromis, un pirate moins négligeant que dans cette histoire peut modifier l'archive et mettre à jour la somme de contrôle MD5/SHA* : tous ceux qui se contenteraient de vérifier la somme de contrôle n'y verrait que du feu et l'authenticité des fichiers ne serait pas garantie.

En aucun cas les sommes de contrôle MD5/SHA* ne garantissent l'authenticité d'un fichier. Pour garantir l'authenticité d'un fichier, c'est à dire qu'il provient bel et bien de l'auteur à qui appartient la clé publique librement disponible, il faut que le fichier soit signé avec un logiciel tel que GPG (et la clé privée de l'auteur qu'il est le seul à pouvoir utiliser).

Pour ma part, je vérifie systématiquement l'authenticité des logiciels que je télécharge quand ceux-ci sont signés avec GPG. Si seules les sommes de contrôles MD5/SHA* sont disponibles, je télécharge le logiciel sur un serveur et les sommes de contrôle MD5/SHA1 sur un autre afin de limiter les dégâts si un des deux serveurs est compromis : bien évidemment, cette solution a l'inconvénient que si les fichiers d'origines étaient déjà modifiés avant leur mirroring, je n'y verrais rien, contrairement au cas où le fichier aurait été signé par l'auteur.

Revenir en haut de page

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.0759s (dont 0.0089 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !