Vulnérabilités dans OpenSSL

Posté par  . Modéré par Benoît Sibaud.
Étiquettes :
0
1
oct.
2003
Sécurité
Des problèmes de sécurité viennent d'être révélé par le projet OpenSSL, la bibliothèque de cryptographie. La faille découverte permet un déni de services et une corruption de pile favorisant alors l'exécution de code hostile.

Toutes les versions inférieures à 0.9.6j et 0.9.7b sont affectées.

Il est recommandé de passer à la version 0.9.7c ou 0.9.6k et de recompiler les programmes liés statiquement à OpenSSL.

Aller plus loin

  • # Re: Vulnérabilités dans OpenSSL

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

    Des packages OpenSSL 0.9.7c sont disponibles pour Slackware 9.1 et slackware-current depuis 2 heures et demi environ. Par contre, il va falloir attendre plusieurs heures pour que les miroirs se mettent à jour, et vu qu'ils sont surchargés depuis la sortie de Slackware 9.1, je vous suggère de mettre à jour vous-même OpenSSL si votre site est sensible.

    • [^] # Re: Vulnérabilités dans OpenSSL

      Posté par  . Évalué à 8.

      En effet, les ftp sont plutôt encombrés par l'arrivée de la Slackware 9.1 mais bon il n'y a pas que le ftp dans la vie ... ya aussi rsync que moins de monde utilise :-)

      Une petite synchro, un coup de upgradepkg et hop !

      Il y a deux petits scripts bien sympathiques sur le forum de Slackware Francophone à l'adresse http://slackware.tuxfamily.org/forum/viewtopic.php?t=37(...) (au premier tiers de la page).

      À noter que dans slackware-current sont aussi arrivés :
      - perl 5.8.1
      - samba 3.0
      - xfce 4.0

      bonheur quand tu nous tiens :-)

      bon rsync ;-)

    • [^] # Re: Vulnérabilités dans OpenSSL

      Posté par  . Évalué à 1.

      Avec ma veine légendaire, je viens de répondre à la personne qui a fait les dits scripts :-))

      En tout cas, merci beaucoup :-)

  • # Re: Vulnérabilités dans OpenSSL

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

    Des updates pour la Mandrake 9.2 (qui n'est pas encore disponible) sont aussi déjà la depuis hier soir (cf ftp://ftp.lip6.fr/pub/linux/distributions/mandrake/updates/9.2/RPM(...) par exemple)

    • [^] # Re: Vulnérabilités dans OpenSSL

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

      ceux pour la MDK 9.1 & consorts sont aussi sortis.

    • [^] # Gentoo, ça criant

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

      ~.~

      Gentoo est encore à la traine: l'ebuild de la 0.96k est distribué, et depuis hier. Mais marqué instable: pour l'utiliser, il faut l'éditer à la main ou alors spécifier son numèro de version demander à utiliser une version instable... sur le bugzilla ils prévoient le passage à la 0.97c dans quelques jours. Et en attendant, rien.

      Je me rappelle que lors des dernières failles du noyau, ils avaient mis 1 mois pour intègrer les patchs à leur noyeau.
      Et après il viennent parler d'une "hardened Gentoo"... ça me fait rire, même en tant qu'adepte de cette distrib.

      Vivement Zynot ! (bon, oké, ça à pas l'air d'avancer trop vite en ce moment)

      • [^] # Re: Gentoo, ça criant

        Posté par  . Évalué à 4.

        Barf il faut relativiser.

        Est-ce-qu'il existe des exploits publics pour ces failles ? Non, aucun à ma connaissance.

        Est-ce-que l'on peut être surs, 5 minutes après l'annonce de la nouvelle version, qu'elle peut être immédiatement installée sur tous les serveurs en prod sans rien casser ? Non.

        Si tu tiens à passer immédiatement à la nouvelle version sur ta Gentoo, tu peux, le paquetage est prêt. Il suffit d'admettre que tu souhaites installer quelque chose qui n'a pas encore été complétement testé. Un délai de quelques jours avant de marquer ces paquetage "stable" me paraît tout à fait raisonnable.

        • [^] # Re: Gentoo, ça criant

          Posté par  . Évalué à 4.

          En plus tu es de mauvaise foi car c'est marqué comme stable depuis ce midi.
          Et l'advisory officiel de Gentoo vient d'être envoyé sur Bugtraq et FD.

          • [^] # Re: Gentoo, ça criant

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

            °_°

            Je viens de faire un "emerge sync".
            emerge -p openssl
            [ebuild UD] dev-libs/openssl-0.9.6j [0.9.6k]
            ...
            http://www.gentoo.org/cgi-bin/viewcvs.cgi/dev-libs/openssl/openssl-(...)
            ...
            Si je suis de mauvaise fois, les mirroirs sont plus à jour que le CVS.
            Mais non! L'histoire est encore plus drôle.
            Lis l'historique du CVS: ils avaient oublié de spécifier que le package était disponible aussi pour sparc, et du coup ils ont rajoutté le mot clef "sparc" après coup.
            Sans penser à mettre le "~sparc" qui aurait indiqué que c'est une version instable (sur cette architecture) !

            Au passage, notte que tu as approuvée l'idée de Gentoo de ne pas mettre à jour la librairie, jusqu'à ce que tu crois qu'elle avait été mise à jour (alors qu'elle l'est par erreur, et seulement sur cette architecture). Dans ces conditions, m'accuser de mauvaise fois...

        • [^] # Re: Gentoo, ça criant

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

          Est-ce-qu'il existe des exploits publics pour ces failles ? Non, aucun à ma connaissance.

          Merveilleux: on est à l'abris des scripts kiddies ! (à priori)
          Je serais très surpris que personne n'arrive à exploiter cette faille dans les trois prochains jours.

          Est-ce-que l'on peut être surs, 5 minutes après l'annonce de la nouvelle version, qu'elle peut être immédiatement installée sur tous les serveurs en prod sans rien casser ? Non.

          Passer de la version 0.9.6j à la 0.9.6k, sachant que cette dernière consiste juste en 4 correctifs de sécurité... disons que c'est moins risqué que de garder une version vérolée.
          C'est d'ailleurs ce que se sont dit les mainteneurs des autres distros, semble-t'il.

          Si tu tiens à passer immédiatement à la nouvelle version sur ta Gentoo, tu peux, le paquetage est prêt. Il suffit d'admettre que tu souhaites installer quelque chose qui n'a pas encore été complétement testé. Un délai de quelques jours avant de marquer ces paquetage "stable" me paraît tout à fait raisonnable.

          Le fait est qu'un type qui fait confiance aux gestionnaires de sa distro (comme moi jusqu'à recement) se trompe.

          Un type qui installe un matin une gentoo avec la dernière version des packages doit en plus lire la liste des failles récentes et appliquer les mises à jour manuellement. Ceci requierant la modification/restauration du fichier de conf, pour evitter de se faire jetter comme quoi le package est experimental (ou alors il est habitué aux errements de Gentoo, et il a des scripts ou alias à portée de main).
          Et après, chaque mise à jour automatique essaieras en plus de passer tous ses packages en stable ou instable. Reste la (contraignante) possibilité d'afficher la liste les packages à mettre à jour, puis de les installer un par un. Mais alors ces packages ne seront pas supprimés par depclean, et ce même si ils ne ne sont plus utiles à aucun programe, car ils seront considérés comme utiles par eux mêmes. Jusqu'au prochain formatage.

          Pour moi, cet exemple, celui du kernel, et d'autres (pas seulement au niveau des packages) ne relèvent pas de la prudence mais plutôt d'un grave problème d'organisation. Il n'y a même pas de règles régissant le passage d'un package instable en stable !

          • [^] # Re: Gentoo, ça criant

            Posté par  . Évalué à 2.

            Pourquoi tu ne postes ceci sur les forums Gentoo ?

            • [^] # Re: Gentoo, ça criant

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

              Parce que les dirigeants de Gentoo ont déjà démontrée leur aptitude à ne pas écoutter la comunautée, et que mon post ne changerais rien.
              Et aussi parce que je prefère pointer du doigt les défaut de l'organisation actuelle, et ainsi pousser à un changement un profondeur, que d'essayer de l'aider à se rendre crédible.

              Mais surtout parce que je parle très mal anglais. -_^

          • [^] # Re: Gentoo, ça criant

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

            > C'est d'ailleurs ce que se sont dit les mainteneurs des autres distros, semble-t'il.

            Ou les mainteneurs d'autre distros font confiance a ceux qui maintiennent le package. L'instabilité des packages ne vient pas de l'instabilité des logiciels mais du systeme de dépendance ...

      • [^] # Re: Gentoo, ça criant

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

        > Je me rappelle que lors des dernières failles du noyau, ils avaient mis 1 mois pour intègrer les patchs à leur noyeau.

        1/ tu es libre de ne pas prendre gentoo-sources, yen a plein d'autres.
        2/ pour gentoo-sources, il existe pfeifer-sources qui est la version de developpement, bcp plus a jour, pour les pressés.
        3/ gentoo-sources inclus grsecurity

  • # librairie de cryptographie

    Posté par  . Évalué à 10.

    Zut il me semblait que c'était une bibliothèque.

    http://www.42-networks.com/faq/library.html(...)

    • [^] # Bibliothèque !

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

      \o/ !

      Je ne suis pas tout seul !

    • [^] # Re: librairie de cryptographie

      Posté par  . Évalué à 10.

      Ca deviendra une librairie si les brevets logiciels passent: il faudra payer pour chaque fonction ;-)

    • [^] # Re: librairie de cryptographie

      Posté par  . Évalué à 2.

      et moi qu'il s'agissait de chiffrement et non de cryptographie ...

      BeOS le faisait il y a 20 ans !

      • [^] # Re: librairie de cryptographie

        Posté par  . Évalué à 5.

        raté !
        chiffrement, déchiffrement, gestion de certificats, signature, authentification, choix de divers algorithmes,... c'est l'objet de la cryptographie

        l'erreur est de parler de cryptage au lieu de chiffrement ;)

    • [^] # Re: librairie de cryptographie

      Posté par  . Évalué à 4.

      Dans une bibliothèque tu empruntes les fonctions et il faut les rendre sous deux semaines sinon tu as des pénalités. Dans une librairie tu peux acheter les fonctions et ensuite elles sont à toi.

  • # patches "exec shield" et "systrace"

    Posté par  . Évalué à 10.

    pour ceux qui aiment modifier leur noyau, c'est le moment de rappeler que la plupart des failles liées à des débordements de tampon (buffer overflow) sont bégnines avec le patch "exec shield" de Ingo Mollnar

    et pour les paranos, la quasi totalité des failles, quelque soit leur nature, sont confinables en lancant chaque programme internet dans une sandbox (interactive donc facile à paramétrer et elle nous alerte en cas d'anomalie) du patch systrace. Le surcout total en CPU est minime (de l'ordre de 1%).

    tout ceci n'empeche évidemment pas de mettre à jour dès que possible openssl

    • [^] # Re: patches "exec shield" et "systrace"

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

      Petite question par rapport a ce patch, si tu installes des kernels avec grsecurity, il devient pas vraiment necessaire non ?

      Steph

      • [^] # grsecurity/execshield

        Posté par  . Évalué à 2.

        en ce qui concerne les overflows je crois que exec shield est plus complet: il controle les variables stack, heap et static

        • [^] # Re: grsecurity/execshield

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

          Non grsec vérifie cela aussi mais ces extensions ne sont pas activées par défaut dans la mandrake : il faut recompiler le noyau. Le BIG inconvénient si on met la sécurité maximale dans GRSec, c'est que certaines applications se plantent (sans dommage pour le système, mais elles ne fonctionnent pas quand même). C'est notamment le cas du X Window System ...

          • [^] # option de recompilation ?

            Posté par  . Évalué à 2.

            il me semble qu'il y a une option dans gcc pour lui interdire de mettre du code exécutable dans les même zones mémoires que les variables, ce qui est la principale incompatibilité avec ces patches

    • [^] # xsupervisor et fireflier

      Posté par  . Évalué à 5.

      pour être complet en matière de sécurité je cite aussi les programmes xsupervisor pour X, et fireflier (firewall interactif) pour iptables

  • # En Anglais dans le texte

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

    Il y a une petite erreur dans la news, toutes les versions d'OpenSSL sont vulnérables à un des problèmes, je cite : "1. Certain ASN.1 encodings that are rejected as invalid by the parser
    ... This issue does not affect OpenSSL 0.9.6"

    Alors que la seconde affecte bien toutes les versions : "All versions of OpenSSL up to and including 0.9.6j and 0.9.7b and all
    versions of SSLeay are affected."

    Steph

  • # Zut encore une faute :o)

    Posté par  . Évalué à 5.

    Je cite :

    All versions of OpenSSL up to and including 0.9.6j and 0.9.7b and all
    versions of SSLeay are affected

    On doit donc lire dans la news :

    Toutes les versions inférieures ou égales à 0.9.6k et 0.9.7c sont affectées.

    Sinon la phrase suivante :

    Il est recommandé de passer à la version 0.9.7c ou 0.9.6k

    n'a plus de sens !

    • [^] # Re: Zut encore une faute :o)

      Posté par  . Évalué à 1.

      La logique a du me faire encore un tour.

      • [^] # Re: Zut encore une faute :o)

        Posté par  . Évalué à 1.

        Mais que fait la police ?

        Maintenant c'est « corrigé » comme cela :

        Toutes les versions inférieures à 0.9.6j et 0.9.7b sont affectées.

        Alors que ça devrait être :

        Toutes les versions inférieures ou égales à 0.9.6j et 0.9.7b sont affectées.

        Ok, je vais faire simple, tu choisis :

        1/
        Toutes les versions inférieures à 0.9.6k et 0.9.7c sont affectées.

        2/
        Toutes les versions inférieures ou égales à 0.9.6j et 0.9.7b sont affectées.

        Copier-coller et hop !

        ;-)

        • [^] # Re: Zut encore une faute :o)

          Posté par  . Évalué à 0.

          ça dépend si on prend le terme "inférieur" comme inférieur strict ou pas... dans les maths francaises il y a toujours l'ambiguïté

          en revanche chez les anglais elle n'y est pas, et pour dire "inférieur ou égal" ils disent "non supérieur" je crois

  • # Re: Vulnérabilités dans OpenSSL

    Posté par  . Évalué à 3.

    Toutes les versions inférieures ou égales à 0.9.6k et 0.9.7c sont affectées.
    (...)
    Il est recommandé de passer à la version 0.9.7c ou 0.9.6k

    le "ou égales" n'est t-il pas de trop dans la phrase? ou est-il conseilllé de mettre à jour sur une version affectée?

  • # Soyons précis dans nos traductions, merci.

    Posté par  . Évalué à 10.

    Je suis exaspéré de voir partout "malicioux" traduit en "malicieux". "malicious" est un faux-ami qui se traduit par "méchant" ou "malveillant" et surtout pas par "malicieux". Désolé mais un ver, un virus... c'est pas franchement malicieux.

    Dans la même série (un peu plus discutable peut-être), il y a "to forge" qui certes peut se traduire par "forger" (du métal) mais qu'on devrait plutôt traduire par "contrefaire". Pour moi "forged IP packets" se traduit par "paquets IP contrefaits" et non "forgés"...

    Question ouverte aux modérateurs : ne pourrait-on pas mettre en place un système permettant de proposer des corrections sur le style ou l'orthographe ? Ceci délesterait les forums des messages sybillins du style "s/malicieux/malveillant/g"...

    • [^] # Re: Soyons précis dans nos traductions, merci.

      Posté par  . Évalué à 3.

      Vous aurez corrigé : s/malicioux/malicious/.
      Dans la même veine il serait sympathique de pouvoir corriger/supprimer ses propres contributions... :) Rien de plus horrible qu'un pinailleur tel que moi qui par étourderie s'expose au feu nourri d'autre pinailleurs (pires, sans doute :).

      • [^] # Re: Soyons précis dans nos traductions, merci.

        Posté par  . Évalué à 2.

        il serait sympathique de pouvoir corriger/supprimer ses propres contributions

        100% ok, mais ça pose un problème de cohérence avec le thread...
        (imagine que tu retires ce que d'autes ont commenté)

        • [^] # Re: Soyons précis dans nos traductions, merci.

          Posté par  . Évalué à 2.

          Et un truc genre, le commentaire avec en dessous la liste des correctinons appliquées?

          Ceci dit, le problème est toujours le même, le site ne bouge pas des masses, et il semble pas que les admins soit super réactif... de là à dire qu'il s'en foute de leur communauté, je ne franchirai pas ce pas... mais je finis par me poser des questions....

        • [^] # Re: Soyons précis dans nos traductions, merci.

          Posté par  . Évalué à 1.

          On peut peut-etre contourner cela en gardant l'historique du post, visible par tous.
          Ainsi, si qq dit "machin c'est genial" et qu'il change en "machin c'est nul", on verra tout de suite que le gars n'est pas fiable.

          On peut aussi rajouter un truc dans le genre ou une correction coute un [-], mais je ne sais pas si l'effet serait benefique (ca peut faire reflechir avant de poster) ou nefaste (du coup, on eviterait de corriger, pour ceux qui font gaffe a leux XP)

          On peut aussi rajouter un truc qui me semble important avec l'historique: mettre en evidence qu'il y a un historique sur le post, combien il y a eu de modifs, et quelle taille fait la modif. 2 lettres modifiees signifient generalement une correction orthographique, alors que 2 paragraphes changes, supprimes ou rajoutes signifient un changement majeur de signification du post.

          Il faudrait aussi peut-etre mettre en evidence qu'un post qui repond a un autre qui a ete modifie, repond a une ancienne version du post et non pas a celle visible.

          Bref, ca necessite beaucoup de modifs. Et comme d'hab, y'a qu'a, mais faut qq pour le faire.

          Le bonjour chez vous,
          Yves

        • [^] # Re: Soyons précis dans nos traductions, merci.

          Posté par  . Évalué à 1.

          ce qu'il faudrait, c'est un systeme de news à la wiki ;)

          (comment ca, c'est pas faisable ?)

    • [^] # Re: Soyons précis dans nos traductions, merci.

      Posté par  . Évalué à 8.

      En fait l'origine du terme malicieux est la même : le malin, le diable, est malfaisant... et malicieux.

      Etre malicieux dans un sens plus ancien, c'était donc associé à une certaine malfaisance -- quoi que pas nécessairement si péjorativement connoté. Mais cette connotation péjorative est moindre en Français, de nos jours.

      • [^] # Re: Soyons précis dans nos traductions, merci.

        Posté par  . Évalué à 2.

        "cette connotation péjorative est moindre en Français, de nos jours."

        Je trouve que c'est donc une bonne idée de parler de "programmes malicieux" pour remettre ce terme au goût du jour.

        BeOS le faisait il y a 20 ans !

        • [^] # Re: Soyons précis dans nos traductions, merci.

          Posté par  . Évalué à 2.

          A la vérité, c'est raison qu'on fasse grande différence entre les fautes qui viennent de notre faiblesse, et celles qui viennent de notre malice.

          |\/|0N7A19N3, m4d sk1ll3D h4x0r'Z w1k1 4b0u7 b4k4^2 14m3rz & 814cK H47

  • # en passant

    Posté par  . Évalué à 3.

    éxécuter ça le fait pas trop... exécuter c'est plus mieux...

    Je trolle dès quand ça parle business, sécurité et sciences sociales

  • # Re: Vulnérabilités dans OpenSSL

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

    Et FreeS/WAN dépend-il d'OpenSSL ? Si c'est le cas, c'est super grave pour mon réseau !

    • [^] # Re: Vulnérabilités dans OpenSSL

      Posté par  . Évalué à 2.

      Et FreeS/WAN dépend-il d'OpenSSL ?

      Un petit ldd devrait te donner la réponse.

      Si c'est le cas, c'est super grave pour mon réseau !

      Quoi, t'as encore tâché ton kimono, et t'as une compète demain ?

Suivre le flux des commentaires

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