Nouvelle vulnérabilité dans l’implémentation OpenSSL

86
8
avr.
2014
Sécurité

Une vulnérabilité dans l’implémentation de l’extension heartbeat (RFC 6520) d’OpenSSL a été découverte conjointement par une équipe de chercheurs en sécurité (Riku, Antti and Matti) à Codenomicon et Neel Mehta de Google Securité. On retrouve ici un vieux bogue des familles : le read overrun.

OpenSSL 1.0.1, jusqu’à 1.0.1f inclus, et OpenSSL 1.0.2-beta1 sont affectés. Ce sont les versions utilisées dans la plupart des distributions.

Cette dernière permet la lecture de 64 Kio dans la mémoire des clients et serveurs affectés (mais l’attaque peut être rejouée à chaque heartbeat), autorisant la lecture de données comme les clés privées et, bien sûr, les données échangées une fois ces dernières retrouvées (et ce, même en mode hors ligne s’il n’y avait pas de forward secrecy utilisé).

Il est difficile, voire impossible, de faire une détection post‐mortem d’infiltration, l’attaque ne laissant pas d’entrée suspecte dans le journal système.

Passer à OpenSSL 1.0.1g, redémarrer tous les services utilisant libssl et remplacer l’intégralité de ses certificats (la clef privée étant vulnérable) est donc nécessaire.

  • # Pour voir si c'est cassé chez vous

    Posté par (page perso) . Évalué à 10.

  • # un effet Snowden?

    Posté par . Évalué à 10.

    Je me demande pourquoi les libs de securite se trouvent brutalement audite. Est-ce lie aux relations de Snowden sur la NSA?

    • [^] # Re: un effet Snowden?

      Posté par (page perso) . Évalué à 10.

      Le chiffrement est de plus en plus utilisé, et logiquement de plus en plus testé (soit par audit, soit directement en prod par les utilisateurs…). D'autant que ce n'est pas figé : nouveaux algos en permanence, découverte de nouvelles classes de failles de sécu, problèmes dans les algos, etc. Et aussi nouvelles méthodes d'audit je présume (généralisation du fuzzing, attaque ciblée sur tel ou tel point).

      Une liste partielle tirée des alertes Debian juste sur 2014 et 2013 :

      [7 avril 2014] DSA-2896 openssl - Mise à jour de sécurité
      [5 avril 2014] DSA-2894 openssh - Mise à jour de sécurité
      [13 mars 2014] DSA-2879 libssh - Mise à jour de sécurité
      [3 mars 2014] DSA-2869 gnutls26 - Vérification de certificat incorrecte
      [22 février 2014] DSA-2866 gnutls26 - Défaut de vérification de certificat
      [7 janvier 2014] DSA-2837 openssl - Erreur de programmation
      [1er janvier 2014] DSA-2833 openssl - Plusieurs vulnérabilités
      [18 décembre 2013] DSA-2821 gnupg - Attaque par canal auxiliaire
      [20 octobre 2013] DSA-2782 polarssl - Plusieurs vulnérabilités
      [10 octobre 2013] DSA-2774 gnupg2 - Plusieurs vulnérabilités
      [10 octobre 2013] DSA-2773 gnupg - Plusieurs vulnérabilités
      [24 septembre 2013] DSA-2763 pyopenssl - Contournement de vérification de nom d'hôte
      [29 juillet 2013] DSA-2731 libgcrypt11 - Fuite d'informations
      [29 juillet 2013] DSA-2730 gnupg - Fuite d'informations
      [29 mai 2013] DSA-2697 gnutls26 - Lecture hors limites de tableau
      [13 février 2013] DSA-2622 polarssl - Plusieurs vulnérabilités
      [13 février 2013] DSA-2621 openssl - Plusieurs vulnérabilités
      

      Ou de voir le nombre d'alertes sécu directement à la source chez gnutls ou openssl par exemple.

      • [^] # Re: un effet Snowden?

        Posté par (page perso) . Évalué à 7.

        Enfin, j'ai toujours eu l'impression qu'il y avait beaucoup de faille sur openssl. Cette bibliothèque revient très régulièrement dans la liste (ce n'est qu'une impression).

        • [^] # Re: un effet Snowden?

          Posté par (page perso) . Évalué à 6.

          Ce n'est pas qu'une impression. Et c'est aussi une des raisons qui fait que les développeurs d'OpenSSH ont préféré réécrire eux-même le code du parsing d'ASN1 notamment.
          Ceci étant le plus gros problème amha reste quand même la façon dont sont traités les problèmes de sécurité avec Openssl (absence de communication avec les distribs ou la communauté par ex.)

          • [^] # Re: un effet Snowden?

            Posté par . Évalué à 10.

            J'en profite pour linker un article très intéressant intitulé "What Heartbleed Can Teach The OSS Community About Marketing" : http://www.kalzumeus.com/2014/04/09/what-heartbleed-can-teach-the-oss-community-about-marketing/

            Ca explique en gros comment le fait d'avoir donné un nom à la fois émotionnel et informatif ainsi qu'un logo au bug a permis une prise de conscience ainsi qu'une réaction immédiate vers la résolution du bug dans le monde entier.

            Si le bug avait été "marketé" comme les autres, c'est-à-dire juste par sa fiche "CVE-2014-0160", il n'y aurait jamais eu cet élan de communication.

        • [^] # Re: un effet Snowden?

          Posté par (page perso) . Évalué à 10.

          Cette bibliothèque revient très régulièrement dans la liste

          Plus un outil est utilisé, plus il est interessant d'y trouver une faille et/ou de l'auditer pour trouver des failles.
          Ca marche pareil pour tous les outils.

          Et la, en plus, la sécurité est devenu (enfin!) quelque chose d'important, tout le monde s'y met car on est tout simplement de plus en plus présent sur le net, et avec nos thunes en ligne.

          • [^] # Commentaire supprimé

            Posté par . Évalué à -2.

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

          • [^] # Re: un effet Snowden?

            Posté par . Évalué à 1.

            TeX me semble moins utilisé qu'OpenSSL, pourtant ça me paraît plus intéressant d'y trouver une faille que dans OpenSSL.

            Cette signature est publiée sous licence WTFPL

        • [^] # Re: un effet Snowden?

          Posté par . Évalué à 8.

          j'ai toujours eu l'impression qu'il y avait beaucoup de faille sur openssl.

          Je n'ai aucune donnée pour évaluer cette fréquence. Par contre, j'ai lu des critiques acerbes sur la qualité du projet OpenSSL, notamment un échange cinglant sur la liste de développement d'OpenBSD. Grosso modo, ils disaient que si le projet avait été piloté normalement, programmé proprement, et s'il avait respecté un minimum les bonnes pratiques, le bug aurait eu un impact mineur. Selon eux, c'est une accumulations d'erreurs structurelles qui en a fait une faille critique.

          Pour se faire une idée du code d'OpenBSD, je recommande la lecture de OpenSSL is written by monkeys (le site a un certificat auto-signé). C'est un compte-rendu des 8 jours qu'un développeur a passé dans le code d'OpenSSL. Les exemples de code qu'il cite au jour 4 sont impressionnants.

          • [^] # Re: un effet Snowden?

            Posté par (page perso) . Évalué à -10. Dernière modification le 10/04/14 à 15:09.

            (le site a un certificat auto-signé).

            Difficile du coup de croire au sérieux de la personne sur la sécurité…

            Les exemples de code qu'il cite au jour 4 sont impressionnants.

            Bof.
            Il y aura toujours des gens pour dire que l'autre fait de la merde, en attendant si il n'est pas content il peut contribuer ou faire un concurrent qui sera plus mieux bien pour prouver qu'il a raison (ou pas).

            En attendant, ben reste qu'on n'a pas mieux en réalité. Trop facile de critiquer comme ça.

          • [^] # Re: un effet Snowden?

            Posté par . Évalué à 0.

            Pour se faire une idée du code d'OpenBSD, je recommande la lecture de OpenSSL is written by monkeys (le site a un certificat auto-signé). C'est un compte-rendu des 8 jours qu'un développeur a passé dans le code d'OpenSSL. Les exemples de code qu'il cite au jour 4 sont impressionnants.

            Le "if (0)" est de toute beauté ! Je serai curieux de voir si d'autres projets utilisent cette construction (je n'ai pas réussi à faire la requête sur Oloh).

    • [^] # Re: un effet Snowden?

      Posté par . Évalué à 5.

      Pour ce qui est de Heartbleed, ci-dessous une explication du programmeur qui a introduit le bug en 2011 en "oubliant de valider une variable".

      http://www.smh.com.au/it-pro/security-it/man-who-introduced-serious-heartbleed-security-flaw-denies-he-inserted-it-deliberately-20140410-zqta1.html
      http://www.20minutes.fr/high-tech/1349037-20140411-heartbleed-erreur-triviale-selon-programmeur-responsable-bug

      Il nie toute intervention de la NSA sur celle-ci (en même temps si c'était le cas il ne pourrait le dire publiquement) et sur OpenSSL en général (mais évidemment reconnaît qu'elle a pu être exploitée par l'agence), il assume son "erreur involontaire", et admet que vues les dernières révélations il est logique d'avoir des soupçons, même s'ils sont infondés dans ce cas précis selon lui.

      • [^] # Re: un effet Snowden?

        Posté par . Évalué à 3.

        en même temps si c'était le cas il ne pourrait le dire publiquement

        Il est citoyen allemand pour ce que j'ai compris… Je ne vois pas ce qui l'interdirait d'en parler.

        Please do not feed the trolls

        • [^] # Re: un effet Snowden?

          Posté par . Évalué à 6.

          Porter des chaussettes et des sandales ne protège pas des balles.

          Autrement si tu aides une agence gouvernementale à introduire une backdoor dans OpenSSL, je ne suis pas certain que ta nationalité change grand chose si tu décides de le révéler. Je penses que ta vie va bien se compliquer que tu sois citoyen US ou du Kirghizistan. Ca sera peut être un peu plus indirect c'est vrai.

          • [^] # Re: un effet Snowden?

            Posté par . Évalué à 3.

            Pas sûr : le révéler et expliquer publiquement qu'on n'envisage aucunement de se suicider ni de faire des sports dangereux jettera un doute sérieux sur le commanditaire d'un éventuel assassinat… Les services d'espionnage restent toujours dans le déni plausible (en s'abritant par exemple derrière l'incompétence du NIST en matière de sécurité pour la NSA) et refusent de signer leurs forfaits.

            • [^] # Re: un effet Snowden?

              Posté par . Évalué à 4.

              Le doute jete lui fera une belle jambe quand il sera le pensionnaire le plus connu du cimetiere…

              Linuxfr, le portail francais du logiciel libre et du neo nazisme.

            • [^] # Re: un effet Snowden?

              Posté par . Évalué à 3.

              expliquer publiquement qu'on n'envisage aucunement de se suicider ni de faire des sports dangereux jettera un doute sérieux sur le commanditaire d'un éventuel assassinat…

              Il reste encore l'accident de la circulation, l'intoxication alimentaire, …

      • [^] # Re: un effet Snowden?

        Posté par . Évalué à 3.

        Ce qui m'embête, perso, c'est que le mec en question est l'auteur principal de la RFC définissant l'extension heartbeat :
        https://tools.ietf.org/html/rfc6520
        Comme j'ai lu sur slashdot, « si même le mec qui a écrit la RFC n'est pas capable de l'implémenter correctement… ».
        (après, perso, le code a l'air tellement crade que je le crois quand il plaide l'incompétence)

        • [^] # Re: un effet Snowden?

          Posté par (page perso) . Évalué à 1.

          Une fois sortie de sa botte l'aiguille parait bien bien poitue, encore faut il la trouver dans la masse de foin…
          Quand au code crade, c'est juste pour ne pas dépareiller avec le reste de l'implémentation historique d'openssl.
          Il y a une grande différence entre établir une RFC et l'implémenter. OpenSSL est le standard de-facto pour toute nouvelle implémentation, donc souvent la première implémentation est pluôt naive et sert à valider le fonctionnement.
          ( J'aimerai bien voir du code de schneier… ) On peut être un très bon théoricien et moins porté sur le code.
          Il me parait évident qu'avant d'arriver à la communauté ce doit etre revu et corrigé - par de nombreuses personnes -. Le code est là depuis deux ans, personne d'autre que des spécialistes n'en a parlé avant…
          Je fais partie des gens qui ont sélectionné openssl avec un pleine confiance en la revue qui était faite et je m'inclus dans le fait qu'on a pas eu l'oeil assez critique sur la masse de changements arrivant avec toutes les nouvelles RFC supportées par 1.0.1.
          Avec openssl comme avec tout programme incluant de la sécurité il faut n'ajouter que le stricte nécessaire. On se demande encore qui utilise le heartbeat dans la nature… a part pour en abuser des effets indésirables…
          C'est un avertissement, il faut y réagir sereinement et être un peu plus circonspect sur les prochains ajouts.

  • # FreeBSD

    Posté par . Évalué à 6.

    FreeBSD 9.2 ne semble pas impacté, OpenSSL est en version 0.9.8y.

    • [^] # Re: FreeBSD

      Posté par . Évalué à 1.

      Trouvé sur le site on l'on peut faire le test (lien dans le premier commentaire):

      "What versions of the OpenSSL are affected?

      Status of different versions:

      OpenSSL 1.0.1 through 1.0.1f (inclusive) are vulnerable
      OpenSSL 1.0.1g is NOT vulnerable
      OpenSSL 1.0.0 branch is NOT vulnerable
      OpenSSL 0.9.8 branch is NOT vulnerable
      

      …"

    • [^] # Re: FreeBSD

      Posté par . Évalué à 2.

      C’est surtout que heartbeat est désactive dans base. FreeBSD 10.0 qui inclut OpenSSL 1.0.1e n’est pas affecté, si on n’utilise pas une autre package.

      • [^] # Re: FreeBSD

        Posté par . Évalué à 1.

        • [^] # Re: FreeBSD

          Posté par (page perso) . Évalué à 3.

          "We are already working on this but building, reviewing, etc. would take some time"
          (et pareil pour Debian Testing pas encore à jour)

          Question idiote : ça ne semble pas avoir été fait en full disclosure (Google Securité?), dans ce cas les équipes de sécurité des différentes distros n'ont-elles pas du temps avant divulgation pour préparer le patch et l'appliquer dès la publication de la faille?
          (en tous cas, RHEL/CentOS sont plus rapides, déjà patchés depuis plusieurs heures)

          • [^] # Re: FreeBSD

            Posté par . Évalué à 5. Dernière modification le 08/04/14 à 21:34.

            Bah, il faut faire des choix, soit on fait un disclosure responsable, soit on fait un site web avec des jolis logos :-)

            Sinon, 10.0-RELEASE-p1 est sorti, pour ceux qui ne voulaient pas appliquer le patch et recompiler base, ni installer openssl depuis les ports (où heartbeat était déjà une option désactivable).

          • [^] # Re: FreeBSD

            Posté par (page perso) . Évalué à 4.

            testing est à jour:
            Réception de : 1 http://ftp.be.debian.org/debian/ jessie/main libssl1.0.0 amd64 1.0.1g-1 [1.008 kB]
            Réception de : 2 http://ftp.be.debian.org/debian/ jessie/main openssl amd64 1.0.1g-1 [664 kB]

            • [^] # Re: FreeBSD

              Posté par (page perso) . Évalué à 4.

              À partir de Jessie pensez à installer le paquet "needrestart". Après la mise à jour de libssl1.0.0 il indique les deamons qui utilisent l'ancien version de la lib en mémoire et fourni une interface pour sélectionner ceux que l'on souhaite redémarrer.

              • [^] # Re: FreeBSD

                Posté par (page perso) . Évalué à 6.

                Sinon checkrestart dans le paquet debian-goodies ou juste lsof|grep ssl|grep DEL

              • [^] # Re: FreeBSD

                Posté par (page perso) . Évalué à 2.

                Très pratique ce paquet «needrestart» merci ! Du coup je l'ai backporté pour mes wheezy.

                Je le préfère à l'outil présent dans les debian-goodies, car ça m'évite de déployer curl sur toutes les machines.

                alf.life

          • [^] # Re: FreeBSD

            Posté par . Évalué à 2.

            Cela a ete fait en responsible disclosure.

            • [^] # Re: FreeBSD

              Posté par (page perso) . Évalué à 3. Dernière modification le 09/04/14 à 09:12.

              Du coup, la question est d'autant plus forte, pourquoi donc ce délai? Le passage dans SID, puis de SID à testing aurait dû être immédiat (et immediat aussi, sans couac, pour Fedora).
              Pour RHEL, ça semble avoir été très très rapide (CentOS un peu moins, peut-être pour faire "payer" le fait de ne pas avoir RHEL).

              Bref, je n'arrive pas à comprendre le pourquoi de ce délai qui n'est pas acceptable dans le cas du responsible disclosure (c'est tout l'interêt du responsible disclouse d'être protégé dès la connaissance de la faille) et ça fait planner un doute sur la capacité de réaction aux failles de sécurité de la part des distros "communautaires".

              Expert des distros Linux, vos explications? les distros communautaires n'ont pas été mises au courant avant la publication de la faille?

              • [^] # Re: FreeBSD

                Posté par . Évalué à 7.

                Pour Debian Stable, j'ai eu un mail annonçant la faille avec le paquet fixé le 7 avril à 21H36, ce qui me semble très honnête niveau timing.

                J'imagine que dans Sid ça a été tout aussi rapide (à confirmer). Pour testing, cela provient de la manière dont sont gérés les remontées de paquets comme expliqué plus haut. Si tu utilises testing en production, c'est un des risques à prévoir (des MAJ de sécurité un poil plus longues à arriver), et c'est bien expliqué dans la doc.

                L'autre distribution communautaire que j'utilise, archlinux (mais pas en serveur), était à jour également le soir du 7 avril : https://www.archlinux.org/packages/core/x86_64/openssl/ : Build Date: 2014-04-07 20:28 UTC

                Bref, sur ces deux distribs, aucune raison de se plaindre.

                • [^] # Re: FreeBSD

                  Posté par (page perso) . Évalué à 6. Dernière modification le 09/04/14 à 10:34.

                  Merci pour les détails, je n'avais pas suivi la différence de réactivité entre testing et stable.
                  Et la, du coup, c'est réactif (testing, c'est moins urgent, ce n'est pas en prod), et on voit très bien l'intérêt du responsible disclosure pour les utilisateurs (sinon les utilisateurs savent et… Ne peuvent rien faire).

                • [^] # Re: FreeBSD

                  Posté par (page perso) . Évalué à 10.

                  Pour Debian Stable, j'ai eu un mail annonçant la faille avec le paquet fixé le 7 avril à 21H36, ce qui me semble très honnête niveau timing.

                  L’annonce de la faille a été faite semble-t-il à 17h27 le 7 avril. Si c’est à ce moment-là que le mainteneur de OpenSSL pour Debian en a pris connaissance, je suis d’accord pour dire que publier le paquet corrigé à peine quelques heures plus tard est effectivement « très honnête », voire remarquable.

                  Mais la question est : est-ce que les développeurs Debian ont été prévenus avant la publication de la faille, ou bien l’ont-ils appris en même temps que le reste du monde ?

                  À voir le bugtracker de Debian, j’ai bien l’impression qu’ils ont découvert le problème le 7 avril au soir, après l’annonce par openssl.org… donc ils ne sont pas dans le cercle de ceux prévenus à l’avance dans le cadre du « responsible disclosure ».

                  • [^] # Re: FreeBSD

                    Posté par . Évalué à 5.

                    Mais la question est : est-ce que les développeurs Debian ont été prévenus avant la publication de la faille, ou bien l’ont-ils appris en même temps que le reste du monde ?
                    D'après ce que j'ai pu lire, il semblerai que non.
                    Par contre, ce que je ne trouve pas forcément normal, c'est que certains grands groupes ont été prévenu avant. Alors pourquoi, les distributions majeurs ne l'ont pas été ?
                    http://blog.cloudflare.com/staying-ahead-of-openssl-vulnerabilities

                    • [^] # Re: FreeBSD

                      Posté par (page perso) . Évalué à 1.

                      Peut-être un manque de confiance au sujet de la discrétion ?

                      Cela ne signifie pas que ce manque de confiance serait justifié, mais c’est une hypothèse.

                      ce commentaire est sous licence cc by 4 et précédentes

                    • [^] # Re: FreeBSD

                      Posté par (page perso) . Évalué à 4.

                      Hum, à ce que j’ai compris des commentaires suscité par le billet cité, OpenSSL aurait été prévenu avant, mais justement ils ont attendu qu’OpenSSL soit en mesure de publier le correctif (ce qui aurait révélé la faille) avant d’annoncer la faille. Le responsible disclosure trouve des limites dans le logiciel libre, un développeur de logiciel libre peut être mis confidentiellement au courant, mais celui qui n’installe que des logiciels présents sur un dépôt public ne peut pas installer de correctif à l’avance.

                      De ce point de vue là, Debian est un peu le perdant de l’affaire… Ils sont obligés d’attendre qu’OpenSSL publie le correctif sur son propre dépôt, ou au moins qu’ils annoncent le correctif en même temps que la faille, donc Debian a nécessairement une longueur de retard.

                      Et les utilisateurs de Debian qui ne sont pas assez gros doivent attendre que Debian repackage le correctif, donc deux longueurs de retard.

                      Le fournisseur de service propriétaire peut corriger dans le secret (avec les limites du secret qui permet de ne pas corriger ce qui n’est pas public).

                      Par contre ce billet où le gars annonce qu’il a pu corriger la faille sur ses services une semaine avant l’annonce de la faille n’honnore pas Yahoo, ils ont été parmi les derniers à mettre en place des corrections alors que vu leur poid, il serait étonnant qu’ils n’aient pas été mis au courant… Ou alors, ça soulève un autre problème majeur, comment un tel poids lourd pourrait être mit à l’écard d’un responsible disclosure.

                      ce commentaire est sous licence cc by 4 et précédentes

                      • [^] # Re: FreeBSD

                        Posté par (page perso) . Évalué à 9.

                        De ce point de vue là, Debian est un peu le perdant de l’affaire… Ils sont obligés d’attendre qu’OpenSSL publie le correctif sur son propre dépôt, ou au moins qu’ils annoncent le correctif en même temps que la faille, donc Debian a nécessairement une longueur de retard.

                        Tout est question de savoir si ils ont été prévenu avant. Si tu veux pas trop que des gens sachent de quoi il en retourne exactement (ou alors tu fais signer un NDA à un gars de l'équipe sécu avant de lui filer le patch à tester), tu peux prévenir la veille en disant "attention, que quelqu'un soit prêt à appliquer un patch demain à 17h27".

                        Quelques heures de retard est encore acceptable, mais vaux mieux 1 heure que 4 heures, et surtout c'est mieux de savoir qu'un patch va arriver (est-ce que ça a été le cas? mystère)

                        Par contre ce billet où le gars annonce qu’il a pu corriger la faille sur ses services une semaine avant l’annonce de la faille n’honnore pas Yahoo,

                        En fait, ça n'honnore personne, c'est super-limite d'avoir priorisé des gens une semaine avant (une semaine, c'est long!), et ça n'honnore surtout pas Cloudfare qui en profite pour se faire de la promo "nous on est dans le secret des dieux".

                        • [^] # Re: FreeBSD

                          Posté par (page perso) . Évalué à 5.

                          Pour cloudflare ça me donne une impression de « je voulais m’la pêter mais en fait j’ai gaffé », surtout quand on lit les commentaires qui relèvent le « pourquoi vous et pas moi/lui ? », au final, en voulant vanter son service, le gars a fuité que ça faisait au moins une semaine que la faille était connue et que les initiés se protégeaient…

                          Jusqu’à ce que je lise cette page, je n’avais aucune notion de temps dans cette affaire, maintenant oui, ce qui peut nourrir la jalousie, le doute, les théories du complot, la susceptibilité, la méfiance, justifier les ressentiments etc. Question communication, il aurait mieux fait de se taire, ou au moins de ne pas dater quoi que ce soit, parce que le temps peut être perçu comme une hiérarchisation.

                          ce commentaire est sous licence cc by 4 et précédentes

                  • [^] # Re: FreeBSD

                    Posté par . Évalué à 7.

                    Apparement il était au depart prevu de rendre la faille publique le 9, ce qui devait laiser 2 jours pour prevenir tous ceux qui devaient l'etre. Mais les developeurs d'OpenSSL on finalement décidé de publier ca immediatement le lundi, peu etre après avoir eu l'impression que trop de monde était deja au courant.

                    http://www.openwall.com/lists/oss-security/2014/04/08/10

                    • [^] # Re: FreeBSD

                      Posté par (page perso) . Évalué à 5.

                      Wow, merci pour le partage, très intéressant, on découvrirait qu’Amazon non plus ne serait pas « dans le secret des dieux ».

                      ce commentaire est sous licence cc by 4 et précédentes

                    • [^] # Re: FreeBSD

                      Posté par (page perso) . Évalué à 6. Dernière modification le 09/04/14 à 16:55.

                      Merci pour le lien (allez le lire!), où on comprend mieux l'ordre des évenements.
                      La faute à pas de chance donc si le responsible disclosure n'a pas pu aller jusqu'au bout :(.
                      (Mais reste de CloudFare prennent tout ce qu'ils peuvent pour se faire de la pub, pour moi c'est une mauvaise pub vu leur façon de se la péter mais je suis sûr que plein de monde va trouver ça bien)

                    • [^] # Re: FreeBSD

                      Posté par (page perso) . Évalué à 10.

                      C'est assez intéressant à lire. Red Hat a été au courant la première 1 et a prévenu dans le quart d'heure les autres distributions (et ces distributions la remercie au passage). Il était donc prévu d'attendre deux jours mais il semblerait que la découverte par deux équipes différentes de la faille ait fait penser que c'était trop connu et la faille a été rendue publique par OpenSSL.


                      1. Un employé de Red Hat bossant pour OpenSSL était au courant plus tôt mais n'a pas prévenu son employeur tout de suite pour ne pas le privilégier, on peut quand même apprécier la transparence de RH. 

                      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

              • [^] # Re: FreeBSD

                Posté par (page perso) . Évalué à 2.

                C’est le rôle de « testing ». C’est plus un « bassin de décantation » de Sid, dans lequel les dépendances sont toujours cohérentes qu’une véritable distribution à part entière. Pour les problèmes de sécurité, les délais sont accélérés, mais le processus reste le même, rien n’entre dans « testing » sans maturation/validation préalable. Il faut bien comprendre qu’au départ « testing » n’était qu’une étape intermédiaire entre Sid et la nouvelle « stable » pour assurer sa cohérence, dans l’espoir de gagner du temps pour la sortie (avec un succès très relatif).

                Le délai entre Sid et « testing » restera toujours, et pour du « responsible disclosure », Sid est corrigé au moment de l’annonce officielle, et donc « testing » traîne un peu.

                En pratique, ça signifie qu’il ne faut pas utiliser « testing » seule. Sur un serveur, on laisse « stable » [0] de toute façon. Sur son ordi perso, on pioche dans Sid lors des annonces de sécurité (ou on ajoute un dépôt tiers pour la sécurité, solution qui devrait être adoptée pour Debian CUT si le projet aboutit).

                [0] qui n’a été affecté ni par le bug Debian dans le générateur de nombres aléatoires, ni par celui-ci et dispose de dépôts de sécurité propres. Certaines failles surviennent évidemment en « stable » aussi, mais le niveau général de sécurité de cette distribution est incomparablement meilleur que les autres branches, voire que beaucoup de distrib’s.

                • [^] # Re: FreeBSD

                  Posté par . Évalué à 2.

                  [0] qui n’a été affecté ni par le bug Debian dans le générateur de nombres aléatoires, ni par celui-ci et dispose de dépôts de sécurité propres. Certaines failles surviennent évidemment en « stable » aussi, mais le niveau général de sécurité de cette distribution est incomparablement meilleur que les autres branches, voire que beaucoup de distrib’s.

                  Je n'ai peut être pas bien compris ce que tu voulais dire, mais en tout cas, si, Debian Stable (wheezy) a bien été impacté par ce bug OpenSSL. Oldstable (Squeeze) non par contre, car la version d'OpenSSL était plus ancienne.

                  • [^] # Re: FreeBSD

                    Posté par (page perso) . Évalué à 2.

                    Oui, par contre wheezy a reçu un correctif tout de suite, alors qu’en effet, pour jessie ça a tardé, mais celui qui met jessie en prod sait à quoi s’attendre…

                    ce commentaire est sous licence cc by 4 et précédentes

                  • [^] # Re: FreeBSD

                    Posté par (page perso) . Évalué à 4.

                    Oui, mille excuses pour la désinformation. Erreur de ma part. La machine sur laquelle j’ai fait la vérification était en « oldstable » et non « stable ».

  • # Une analyse du bug.

    Posté par . Évalué à 3. Dernière modification le 08/04/14 à 13:59.

    Pour les flemmards comme moi qui ne sont pas allés voir le patch:

    http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html

    Ça semble (un peu) moins critique que le laisse entendre la description initiale: on ne peut pas lire 64k où l'on veut. Donc récupérer le certificat doit fortement dépendre de la disposition de la mémoire…

    • [^] # Re: Une analyse du bug.

      Posté par . Évalué à 9.

      Dans le dump que j'obtient de certains serveur vulnérable j'ai des entêtes de requête HTTP avec notamment les cookies de session, en les utilisant j'ai réussi à utiliser le compte d'une personne random… C'est quand même assez critique.

      • [^] # Re: Une analyse du bug.

        Posté par . Évalué à 10. Dernière modification le 08/04/14 à 18:25.

        En exploitant la faille sur login.yahoo.com (qui est toujours vulnérable à cette heure-ci, quelle honte), une fois sur deux, tu as un login/password qui tombe.
        Donc pas critique… si, un peu quand même ;)

    • [^] # Re: Une analyse du bug.

      Posté par . Évalué à 2.

    • [^] # Re: Une analyse du bug.

      Posté par (page perso) . Évalué à 1.

      C'est vrai que la dépèche est un peu trop "ça le fait à tous les coups".

      "autorisant" --> "autorisant potentiellement (suivant le contenu du bloc aléatoirement accédé)"?

      • [^] # Re: Une analyse du bug.

        Posté par . Évalué à 10.

        Non non, autorisant.

        T'es libre d'envoyer autant de requetes que tu veux hein… et t'es aussi libre d'envoyer d'autres requetes au systeme afin d'exercer l'allocateur et lui faire mettre en memoire ce que tu veux lire.

        Il n'y a pas de 'potentiel', c'est avere, ca prend simplement plus qu'une requete pour avoir ce que tu veux.

    • [^] # Re: Une analyse du bug.

      Posté par (page perso) . Évalué à 10.

      Donc récupérer le certificat doit fortement dépendre de la disposition de la mémoire…

      Chez moi, les barrettes de ram sont à côté du CPU.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Une analyse du bug.

        Posté par . Évalué à 0.

        Avec un MMU entre les deux…

      • [^] # Re: Une analyse du bug.

        Posté par . Évalué à -2.

        Je pense qu'il voulait dire : dépendre de la disposition des données dans la mémoire.

        • [^] # Re: Une analyse du bug.

          Posté par . Évalué à 10.

          Nonon. Je parlais bien de la disposition des barrettes. Par exemple, en mode réel, si elles sont en cercle de 256k de rayon, et que tu lis 64k vers le centre, tu tombes sur du vide.

    • [^] # Re: Une analyse du bug.

      Posté par . Évalué à 4.

      L'analyse est intéressante à lire. Mais cela me rappelle trop une certaine époque en php où il n'était cesser de râbâcher que les entrées utilisateurs c'est le mal absolu et qu'il fallait s'en méfier comme de bill gates.
      Mais le fait est que s'appuyer sur la compétence des hommes, même les meilleurs de chez openssl, ne peux suffire pour se mettre à l'abri.

      Du coup, comme suggéré en fin d'article, changer de langage reste la seule option décemment concevable.

      A t'on réellement besoin de le faire en C ?
      La rapidité d'exécution est elle si nécessaire pour ce point particulier ?
      Je veux dire que la crypto par la nature même de la solution qu'elle apporte est très lente à exécuter sur un ordinateur.
      Ne peut on pas dès lors se permettre un peu plus de lenteur au prix d'une sécurité véritablement accrue ?

      Dit autrement, a quand une implémentation d'openssl en rust ?

      Bon par contre, pour un genre de raison similaire à ce cve, Java n'est pas une alternative envisageable :D /désolé/

      • [^] # Re: Une analyse du bug.

        Posté par . Évalué à 3.

        Dit autrement, a quand une implémentation d'openssl en rust ?

        Si seulement un langage sans possibilité de faille existait… il y a longtemps qu'il serait utilisé.

        • [^] # Re: Une analyse du bug.

          Posté par (page perso) . Évalué à 8.

          Pas forcément, tu as bien coq et d'autres systèmes de preuves formels dont tu peux extraire des programmes certifiés. Il y a aussi des outils pour prouver formellement des propriétés sur du code C, ou d'autres langages. Si c'est pas très utilisé (à part pour certains systèmes critiques) c'est surtout parce que ça demande beaucoup plus de travail, et que peut-être pour beaucoup même trop pour juste une grosse faille toutes les plusieurs années.

          Sinon, c'est quand même vrai que les dépassement de mémoire c'est beaucoup plus courant avec du code C qu'avec d'autres langages où tu ne gères pas la mémoire et tu dois juste faire confiance au GC, dont les bugs sont moins courants normalement, du moins il me semble.

          • [^] # Re: Une analyse du bug.

            Posté par . Évalué à 1.

            C'est un mieux, mais ça ne doit pas donner un sentiment de sécurité à toute épreuve.

            Une analyse en Coq ne va donner qu'une correction fonctionnelle ou, si tu as été jusqu'à formaliser un modèle crypto, ne va donner qu'une preuve de sécurité pour le modèle d'adversaire que tu captures.

            De même, l'utilisation d'un GC va introduire des canaux cachés difficilement contrôlables.

        • [^] # Re: Une analyse du bug.

          Posté par . Évalué à 2.

      • [^] # Re: Une analyse du bug.

        Posté par . Évalué à 8.

        Dit autrement, a quand une implémentation d'openssl en rust ?

        Tu rêve: si la sécurité était vraiment prise au sérieux, le C ne serait pas utilisé sur ce genre de projet: Ada ça existe déjà depuis longtemps..
        Certes, Ada n’empêche pas de faire des erreurs de durée de vie des variable comme Rust, mais il a le mérite d'être mature et d'exister depuis longtemps et de résoudre 99% des problèmes du C ce qui
        est déjà un net progrès!

        • [^] # Re: Une analyse du bug.

          Posté par . Évalué à 3.

          Ada ? Pfffff….

          http://www.mitls.org/wsgi

          miTLS is a verified reference implementation of the TLS protocol. Our code fully supports its wire formats, ciphersuites, sessions and connections, re-handshakes and resumptions, alerts and errors, and data fragmentation, as prescribed in the RFCs; it interoperates with mainstream web browsers and servers. At the same time, our code is carefully structured to enable its modular, automated verification, from its main API down to computational assumptions on its cryptographic algorithms.

          Oh, et c'est partenariat de MS Research et l'INRIA

          • [^] # Re: Une analyse du bug.

            Posté par (page perso) . Évalué à 5.

            Et c'est en F# pour ceux qui ne veulent pas cliquer.

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: Une analyse du bug.

            Posté par . Évalué à -3.

            Note que F# a un sacré handicap: Microsoft! Pas besoin de détailler je pense..

            • [^] # Re: Une analyse du bug.

              Posté par . Évalué à 4.

              C'est une implémentation de référence, pas une implémentation destinée à être utilisée en production. C'est pour montrer l'utilité des méthodes formelles, et leur application à des protocoles conséquents. C'est transposable à d'autres langages (et comme je l'ai dit plus, ce n'est pas à toute épreuve, le GC introduisant des canaux cachés par exemple).

              Aussi, l'implémentation de F# est sous Apache2 et testée sous Mono. C'est donc testable librement… même si encore une fois, je comprends qu'on ne puisse/veuille pas mettre un runtime mono où l'on veut !

            • [^] # Re: Une analyse du bug.

              Posté par . Évalué à -3. Dernière modification le 10/04/14 à 17:39.

              c'est surtout pas multi-OS donc ca sert a rien dans le cas present.

              • [^] # Re: Une analyse du bug.

                Posté par . Évalué à 7.

                F# tourne sous Windows, Linux, MacOSX, iOS, Android et est open-source. A priori ca devrait entrer dans la catégorie multi-OS.

          • [^] # Re: Une analyse du bug.

            Posté par (page perso) . Évalué à 3.

            Oh, et c'est partenariat de MS Research et l'INRIA

            C'est bien de mettre en exergue la qualité des labos français pour une fois :D

            • [^] # Re: Une analyse du bug.

              Posté par . Évalué à 10.

              Les francais ont toujours ete bon de ce cote la, le probleme francais c'est de tourner ca en une industrie malheureusement.

      • [^] # Remplacer l'assembleur par Ada ou Rust ?

        Posté par . Évalué à 3.

        A t'on réellement besoin de le faire en C ?
        (…)
        Dit autrement, a quand une implémentation d'openssl en rust ?

        Quand Rust sera prêt, peut-être… :-p

        Plus sérieusement, c'est un peu naïf de dire qu'OpenSSL est écrit en C. Parce que quand tu fais de la crypto tu dois faire de l'assembleur, et du coup reposer sur un langage plus évolué que C pour tester tes accès mémoire est une vaste blague, puisque ça ne concerne pas tout ton code.

        Dit autrement, explique-moi comment tu ré-écris ça en Rust ou comment Rust s'assurera qu'il n'y a pas de buffer underrun dedans:
        https://github.com/openssl/openssl/blob/master/crypto/aes/asm/aes-x86_64.pl

        Et comme aujourd'hui il y a des nouvelles opérations dédiées à la crypto directement dans le processeurs et qu'elles changent à chaque nouvelle version des processeurs, l'assembleur a de beaux jours devant lui.

        Après t'as des gens qui ont fait une lib ssl complète en Ada, t'en auras qui le feront en Rust un jour (en plus c'est cool), mais à côté des opcodes AES (ou même juste vectoriels) dans les processeurs, j'ai peur que le rapport de performance reste de 100 ou 1000…

        • [^] # Re: Remplacer l'assembleur par Ada ou Rust ?

          Posté par . Évalué à 1.

          Et encore j'ai pas linké la bonne implem, celle qui n'est vraiment pas possible d'écrire en Rust:

          https://github.com/openssl/openssl/blob/master/crypto/aes/asm/aesni-x86_64.pl

          • [^] # Re: Remplacer l'assembleur par Ada ou Rust ?

            Posté par . Évalué à 6.

            Parce que quand tu fais de la crypto tu dois faire de l'assembleur.

            Non, c'est juste pour avoir de meilleures performances que c'est fait en assembleur.

            On peut très bien implémenter AES en C, en Java, ou en OCaml. Ce que tu montres est le support d'une extension Intel pour accéléer AES, ce qui n'est absolument pas indispensable pour faire de la crypto.

            Par ailleurs, on peut mettre de l'assembleur inline dans du code Rust (dans un bloc unsafe) :

            Rust release notes

            • [^] # Re: Remplacer l'assembleur par Ada ou Rust ?

              Posté par . Évalué à 3.

              On peut très bien implémenter AES en C, en Java, ou en OCaml. Ce que tu montres est le support d'une extension Intel pour accéléer AES, ce qui n'est absolument pas indispensable pour faire de la crypto.

              Pour faire de la crypto en labo non, mais pour faire le site de vente en ligne ou d'une banque, je crains que si.

              c'est juste pour avoir de meilleures performances que c'est fait en assembleur

              Exactement. Juste, c'est le mot.

              on peut mettre de l'assembleur inline dans du code Rust

              Et l'assembleur mis en inline dedans, Rust s'assure qu'il n'y a pas de buffer overflow dedans ?
              ;-)

              • [^] # Re: Remplacer l'assembleur par Ada ou Rust ?

                Posté par . Évalué à 4.

                Ça isole un peu la partie du code à vérifier si on sait déja qu'il n'y a que là qu'il y a des risques d'en avoir.

              • [^] # Re: Remplacer l'assembleur par Ada ou Rust ?

                Posté par . Évalué à 5.

                Pour faire de la crypto en labo non, mais pour faire le site de vente en ligne ou d'une banque, je crains que si.

                Oui alors euh, certains des gens qui faisaient de la crypto dans mon labo avaient des petites phrases du genre « C est trop haut-niveau, c'est chiant, quand j'ai un overflow (que je pourrais exploiter) il me le dit pas ! ».

                Sinon, si pas mal de mes collègues cryptologues avaient effectivement commencé à bosser sur des softs de type magma pour représenter leurs courbes elliptiques etc., une fois que leurs protocoles étaient au point et testés, ils ont quand même eu à aller recoder leurs algos en C avec libgmp (à l'époque je crois que c'est ce qu'ils utilisaient). Sinon, il aurait été difficile de déterminer en combien de temps leurs attaques allaient réellement porter leurs fruits, etc. Et oui, au bout d'un moment, il y avait aussi du SSE voire du AVX qui entrait dans la danse…

            • [^] # Re: Remplacer l'assembleur par Ada ou Rust ?

              Posté par . Évalué à 2.

              Ce que tu montres est le support d'une extension Intel pour accéléer AES, ce qui n'est absolument pas indispensable pour faire de la crypto.

              Et pour éviter de se faire casser son chiffrement de disque dur en 1s.

              http://www.cs.tau.ac.il/~tromer/papers/cache.pdf

              PS: je suis un grand utilisateur de langages de haut niveau. Mais il reste du travail à faire pour avoir des implémentations efficaces et sûres des primitives cryptographiques.

              • [^] # Re: Remplacer l'assembleur par Ada ou Rust ?

                Posté par . Évalué à 2.

                Ils font quand même l'hypothèse assez forte qu'il y a un processus malveillant sur le même ordinateur, qui fonctionne en même temps que le programme de chiffrement.

                unprivileged process to attack other processes running in parallel on the same processor,
                despite partitioning methods such as memory protection, sandboxing and virtualization.

                Dans les contremesures, ils parlent aussi d'autres solutions qu'utiliser l'extension Intel pour activer un no-fill mode, ou l'implémentation bitslice.

                Il y a quelques contre mesures qui ne nécessitent pas de coder en assembleur, à première vue : section 5.2, alternative lookup tables, 5.3 (pour le dernier paragraphe), 5.4, these countermeasures […] are algorithmic en rajoutant des transformations aléatoires etc…

                Bref, comme les auteurs le rappellent, les méthodes qui n'utilisent pas l'assembleur sont :

                significantly slower in software than a bitslice implementation

                Encore une question de performance, non ?

                • [^] # Re: Remplacer l'assembleur par Ada ou Rust ?

                  Posté par . Évalué à 5.

                  Ils font quand même l'hypothèse assez forte qu'il y a un processus malveillant sur le même ordinateur, qui fonctionne en même temps que le programme de chiffrement.

                  Je ne trouve pas l'hypothèse si forte: tu peux retrouver la clé de chiffrement d'un disque dur pour une machine sur laquelle tu as un simple accès car dans ce cas tu peux forcer le programme de chiffrement à fonctionner en écrivant sur le disque dur. Ça a été fait en pratique, et c'est très efficace—bien sûr, ça ne marche plus aujourd'hui.

                  J'avais été voir une présentation de Shamir au collège de France. Il y avait présenté une attaque basée sur les variations de la tension sur les ports USB ou du bruit émis par la machine: le stepping du processeur, qui change suivant la charge demandée, provoque ces variations, au point que statistiquement tu arrives à différencier les multiplications des additions (et donc le bit de poids faible en cours d'inspection) lors du chiffrement RSA. A l'époque, c'était encore un peu fumeux, mais l'attaque s'améliore:

                  https://eprint.iacr.org/2013/857

                  Encore une question de performance, non ?

                  Par rapport à mon propos, oui et non. Oui, l'instruction Intel est là pour protéger AES contre ces attaques sans avoir une dégradation catastrophique des performances. Mais non, quitter l'assembleur ne va pas régler le problème des canaux cachés. J'aurais tendance à dire: au contraire même. Et l'analyse de ces implémentations va, avec l'état de l'art courant, être bien difficile aussi: il n'y a pas de modèle du JIT, il n'y a pas de modèle du GC. Ça ne veut pas dire que ça ne va pas arriver… et dans ce cas, avoir un langage de haut niveau permettra de mieux analyser le protocole en lui-même. Car TLS (même en 1.2) est très limite niveau crypto, et la RFC laisse certaine partie à interprétation.

                • [^] # Re: Remplacer l'assembleur par Ada ou Rust ?

                  Posté par (page perso) . Évalué à 6.

                  Ils font quand même l'hypothèse assez forte qu'il y a un processus malveillant sur le même ordinateur, qui fonctionne en même temps que le programme de chiffrement.

                  C'est potentiellement le cas de tous les serveurs web des hébergeurs par exemple.

            • [^] # Re: Remplacer l'assembleur par Ada ou Rust ?

              Posté par (page perso) . Évalué à -3.

              Ce que tu montres est le support d'une extension Intel pour accéléer AES, ce qui n'est absolument pas indispensable pour faire de la crypto.

              C'est sûr qu'en disant ce dont ont besoin les autres à leur place, c'est facile.
              Maintenant, je suis heureux de lire que quand j'achète un CPU, tu n'en offres 99 du même type (et la machine autour, et le prix de location de la baie…)

              OK, ton offre n'est pas crédible, donc il reste juste à dire : foutaises, ça c'est le discours d'une personne qui a quelques utilisateurs sur sa machine et qui pense que tout le monde est comme lui, mais ce n'est pas le cas.

              On peut très bien implémenter AES en C, en Java, ou en OCaml.

              Qui va être aussi rapide que l'ASM avec AES-NI, oui ou non?
              "pouvoir" n'est pas suffisant, je peux traverse l'atlantique en voilier mais pas foule va faire pareil et va préférer l'avion, normal.

              • [^] # Re: Remplacer l'assembleur par Ada ou Rust ?

                Posté par . Évalué à 3.

                Je ne suis pas sûr de comprendre ta remarque… je me contentais de faire une remarque théorique, et aucunement de proposer à tout le monde d'utiliser une implémentation prouvée et générée à partir de Coq d'AES.

                Oui, on peut effectivement implémenter AES avec C, Java ou Ocaml, et oui, ce sera effectivement moins rapide qu'en ASM.

                Une comparaison plus adéquate aurait été entre descendre de la tour Effel en sautant en parachute (risqué) ou par les escaliers (moins risqué mais plus lent) - et il y a un compromis… les ascenseurs- .
                Ainsi, si utiliser un langage de plus haut niveau avec des garantis statiques fortes apportait plus de confiance dans l'implémentation, personnellement, je préfèrerais utiliser utiliser cette implémentation qu'une implémentation très rapide ; peu m'importe que me loguer sur le site de ma banque prenne du temps, mais qu'on puisse faire des virements bancaires à partir de mon compte à mon insu, par contre, ça me gênerait…

                Cependant, Burps indique de façon convaincante que ce n'est pas que pour des raisons de performance qu'on utilise l'assembleur, mais aussi pour éviter des attaques, donc ça parait bien plus justifié d'utiliser l'assembleur.

                • [^] # Re: Remplacer l'assembleur par Ada ou Rust ?

                  Posté par (page perso) . Évalué à -5. Dernière modification le 10/04/14 à 13:18.

                  Une comparaison plus adéquate aurait été entre descendre de la tour Effel en sautant en parachute (risqué) ou par les escaliers (moins risqué mais plus lent) - et il y a un compromis… les ascenseurs- .

                  Oui, bon, en gros tu dis que tu veux un truc sûr même si il ne répond plus au besoin initial. Facile!

                  peu m'importe que me loguer sur le site de ma banque prenne du temps, mais qu'on puisse faire des virements bancaires à partir de mon compte à mon insu, par contre, ça me gênerait…

                  Tu viens de montrer que tu n'as absolument rien compris au problème.
                  Si toi tu es prêt à payer plus cher, d'autres ne le sont pas. (je n'ai pas parlé de latence, j'ai parlé de cout dans mon message…)
                  Oui, on parle d'argent (du cout d'un CPU, d'une baie, de la maintenance…), tu es complètement hors sujet avec ta question de temps et montre que tu ne comprends pas le besoin et en quoi AES-NI répond plus au besoin que ton language haut niveau "sécurisant".

                  Comme tu dis, c'est une question de compromis, et le compromis choisis par la majorité des gens n'est pas le tiens, ça n'empèche toutefoirs personne de te proposer (plus cher) ce que tu veux… Si il y a une réelle demande.

                  • [^] # Re: Remplacer l'assembleur par Ada ou Rust ?

                    Posté par . Évalué à 4.

                    Détrompe-toi :

                    Si toi tu es prêt à payer plus cher, d'autres ne le sont pas.

                    Si d'autres sont prêts à payer moins cher quitte à avoir une moins bonne sécurité, d'autres ne le sont pas.

                    le compromis choisis par la majorité des gens n'est pas le tien

                    Ha bon ? Celui de privilégier la sécurité ? Tu as des chiffres ?
                    J'ai comme l'impression que tu n'as pas vraiment compris ma remarque et que tu n'as pas lu ma dernière phrase :

                    Cependant, Burps indique de façon convaincante que ce n'est pas que pour des raisons de performance qu'on utilise
                    l'assembleur, mais aussi pour éviter des attaques, donc ça parait bien plus justifié d'utiliser l'assembleur.

                    A partir du moment où l'assembleur permet d'obtenir une meilleure sécurité, c'est un bon choix. Si en plus, il permet d'avoir de meilleures performances et de réduire les coûts, c'est encore mieux.

                    Il n'est pas sûr en plus qu'utiliser une implémentation avec des failles de sécurité permettent de réduire les coûts in fine, s'il faut rembourser des utilisateurs floués, mettre à jour les programmes et l'infrastructure, restaurer des sauvegardes, voir l'image de l'organisation complètement détruite devant les utilisateurs.
                    Avant d'affirmer de façon péremptoire que ça va coûter plus cher ou moins cher (tu as peut-être raison), moi, je préfère étudier la question plus en détails.

                  • [^] # Re: Remplacer l'assembleur par Ada ou Rust ?

                    Posté par . Évalué à 7.

                    Oui, bon, en gros tu dis que tu veux un truc sûr même si il ne répond plus au besoin initial. Facile!

                    D'ailleurs, je propose une solution sans Rust, sans Ada, sans Go et sans C¹:
                    Il suffit de débrancher l'électricité, de prendre une² feuille de papier et du crayon et de faire à la main, c'est possible et c'est juste moins performant. :-)

                    ¹: je n'ai pas dit "sensé", j'ai dis "sans C"
                    ²: ok, il va falloir plusieurs feuilles, et probablement une gomme également, mais ça reste juste une question de performance par rapport aux opcodes aesni

              • [^] # Re: Remplacer l'assembleur par Ada ou Rust ?

                Posté par . Évalué à 2.

                quand j'achète un CPU, tu n'en offres 99 du même type
                J'offre une implémentation bitslice qui permet de traiter le chiffrement 64 fois plus vite pour 64 clients en parallèle, ce qui est certainement plus efficace pour l'AES que les implémentations standard (l'AES n'a pas été inventé pour être spéclamement efficace pour les plate-formes logicielles 64 bits).

                Qui va être aussi rapide que l'ASM avec AES-NI, oui ou non?
                Sans aucun doute avec les intrinsics C/C++ de gcc, qui devraient être présentes dans les autres langages et permettent de faire de l'assembleur avec la rigueur d'un appel de fonction bien connue par le compilateur.

        • [^] # Re: Remplacer l'assembleur par Ada ou Rust ?

          Posté par . Évalué à 2.

          comment Rust s'assurera qu'il n'y a pas de buffer underrun dedans:
          Faire appel aux fonctions intrinsics ?

          • [^] # Re: Remplacer l'assembleur par Ada ou Rust ?

            Posté par . Évalué à 1. Dernière modification le 10/04/14 à 12:05.

            Je ne comprends pas bien ce que les les fonctions intrinsics de Rust apportent pour soit implémenter de la crypto avec les opcodes AESNI en Rust soit garantir que du code assembleur ajouté à un programme Rust ne contienne pas de buffer underrun.

            Mais je veux bien comprendre.

            • [^] # Re: Remplacer l'assembleur par Ada ou Rust ?

              Posté par . Évalué à 3.

              Je pense qu'une façon de faire serait de modéliser le comportement des fonctions utilisées et valider le fait que le code assembleur ne contient pas de buffer overflow.

              Ça ne marcherai pas avec tout les programmes assembleur, mais bon ça devrait marcher avec un nombre suffisant..

            • [^] # Re: Remplacer l'assembleur par Ada ou Rust ?

              Posté par . Évalué à 2.

              Je voulais dire qu'il y aura certainement en Rust des fonctions intrinsics qui permettent d'appeler directement les opérations assembleur d'un chiffrement AES, comme il y en a déjà en C/C++ avec gcc et d'autres compilateurs. Sinon ce serait une grosse limitation de Rust.
              L'intérêt de ces fonctions est de pouvoir faire de l'assembleur avec la rigueur sémantique d'une fonction du langage.

              • [^] # Re: Remplacer l'assembleur par Ada ou Rust ?

                Posté par . Évalué à 1. Dernière modification le 10/04/14 à 21:23.

                il y aura certainement en Rust des fonctions intrinsics qui permettent d'appeler directement les opérations assembleur d'un chiffrement AES, comme il y en a déjà en C/C++ avec gcc et d'autres compilateurs

                Eh bien figure-toi qu'il n'y en a pas non plus en C/C++ (et qu'il n'y en aura probablement jamais vu comment ces opcodes ont un usage très spécifique), c'est pour ça que quand on doit utiliser ce genre d'opcodes on le fait en assembleur.
                Ce n'est pas parce que Rust, comme d'autres langages, donne accès aux opérations atomiques qu'il donnera accès à toutes les opérations des processeurs.

                Pour illustrer, on peut prendre une opération beaucoup moins spécialisée: la rotation de bit, qui est un équivalent du décallage de bit (opérateurs << et >> en C, Java & co) mais où le bit qui disapraît à droite ou à gauche réapparait de l'autre côté. Ces opérations existent depuis plus de 30 ans dans tous les processeurs (à part peut-être certains RISC j'en sais rien), et il n'y a pas de méthode ou d'opérateur standard en C pour effectuer cette opération. Probablement parce qu'il est rare d'en avoir besoin à part dans des algos ultra optimisés. Et ça fait plus de 30 ans.

                Et la rotation de bit, elle existe sur tous les processeurs, contrairement aux spécificités comme AESNI. Donc ce serait facile de fournir un langage fortement portable avec des rotations de bits. Pour AESNI en revanche…

                • [^] # Re: Remplacer l'assembleur par Ada ou Rust ?

                  Posté par . Évalué à 7. Dernière modification le 11/04/14 à 10:25.

                  figure-toi qu'il n'y en a pas non plus en C/C++

                  Pardon ? Chez moi j'ai un joli fichier wmmintrin.h fourni par GCC, qui contient les fonctions C à appeler sur des données C, que le compilateur remplace par l'instruction AES-NI si elle est présente.
                  Idem avec la quasitotalité des fonctions vectorielles.

                  et qu'il n'y en aura probablement jamais vu comment ces opcodes ont un usage très spécifique

                  Ce n'est pas comme s'il était impossible de générer des codes path différents à l'exécution si jamais l'instruction n'était pas présente sur le CPU.

                  la rotation de bit,

                  La rotation de bits s'écrit en une macro C ou une fonction template C++ avec 2 shift et un OR, et ce n'est pas comme si les compilateurs ne détectaient pas le pattern depuis au moins 10 ans pour le remplacer par l'instruction spécifique si besoin.

                  • [^] # Re: Remplacer l'assembleur par Ada ou Rust ?

                    Posté par . Évalué à 2.

                    Pardon ? Chez moi j'ai un joli fichier wmmintrin.h fourni par GCC, qui contient les fonctions C à appeler sur des données C, que le compilateur remplace par l'instruction AES-NI si elle est présente.
                    Idem avec la quasitotalité des fonctions vectorielles.

                    Au temps pour moi, je suis confus, quand j'ai regardé les intrinsics gcc j'ai eu la bêtise de le faire sur une machine où il y avait un vieux gcc (4.1.2).

                    Cela dit je serai curieux de savoir pourquoi ni openssl ni gnutls ne les utilisent (les deux libs font directement de l'assembleur).
                    Ou (corollaire) qui utilise ces intrinsics, puisque les deux principaux utilisateurs libres potentiels qui me viennent à l'esprit ne les utilisent pas…

        • [^] # Re: Remplacer l'assembleur par Ada ou Rust ?

          Posté par . Évalué à 0. Dernière modification le 10/04/14 à 13:42.

          c'était totalement naïf comme post.

          J'ai cité rust, comme j'aurais pu/du citer Ada, ou d'autres.

          Qu'importe ! ai je envie de dire.

          L'idée étant celle-ci, à jouer avec le feu, tu finis invariablement par te faire brûler (un matheux passant par là pourrait pbblmt nous le théoriser).
          Dès lors ne peut on pas, juste, éviter de jouer avec le feu.

          C'est la gestion du risque dans toute sa splendeur. Partant du principe que cela n'arrivera que 0.0001% des cas, alors c'est acceptable de jouer avec le feu.
          Malheureusement, sans vouloir faire des comparaisons dé raisonnés, les centrales nucléaires sont conçus avec un risque de 0.000000001% et pourtant déjà elles ont explosé plusieurs fois.
          Le problème de la finance actuel est du même acabit.

          Sinon, non aucune foutre idée de comment ré implémenter cela en rust, je fuis le C comme bill gates.
          Par contre j'aimerais bien avoir du temps pour apprendre rust et voir si c'est aussi bien fichu que nodejs, outre le langage itself.

          • [^] # Re: Remplacer l'assembleur par Ada ou Rust ?

            Posté par . Évalué à 4.

            J'ai cité rust, comme j'aurais pu/du citer Ada, ou d'autres.
            (…)
            Sinon, non aucune foutre idée de comment ré implémenter cela en rust, je fuis le C comme bill gates.

            C'est bien à ça que je réponds: tu dis que le problème vient de l'utilisation du C, mais tu ne connais pas le sujet et n'a pas envie de le connaître, sauf que justement on est en plein cœur d'une des rares utilisation actuelles ou le C et l'assembleur restent incontournables. Malgré leurs défauts (et là on s'en tape un en pleine face, c'est clair).

            La crypto doit être à la fois optimisée en perfs, facile à auditer (plus le langage est de haut niveau plus il y a de comportements déclaratifs ou implicites) et disponible sur toutes les plateformes (Rust c'est 4 plateformes pour le moment, Ada je ne dis pas). C'est contraignant comme du réseau ou du noyau.

            Sachant qu'en l'occurrence le bug n'était pas un problème de lecture dans un pointeur mal alloué qui se règlerait trivialement avec un array de plus haut niveau qui ferait lui-même le bound-check comme en Rust, en C++, en Pascal ou en Visual Basic. C'était l'oubli d'un sanity check sur la valeur lue dans le message réseau qui arrive, auquel le code a malheureusement¹ fait confiance aveuglément.

            C'est bien expliqué dans le lien plus haut, en même temps c'est tellement simple que ça se voit bien dans le correctif aussi (d'autant plus qu'il a été largement commenté ligne à ligne, probablement un effet médiatique ;-)):
            https://github.com/openssl/openssl/commit/731f431497f463f3a2a97236fe0187b11c44aead

            ¹: exprès, disent les plus méfiants

            • [^] # Re: Remplacer l'assembleur par Ada ou Rust ?

              Posté par . Évalué à 2.

              Oui.

              En fait, à y réfléchir deux fois, le titre m'a trompé, car corriges moi si je me trompes, le bug survient dans la lib ssl certes, mais c'est d'abord et avant tout un problème de lecture des request/response.
              Donc plus un problème de nature réseau que crypto. (ahaalal … )

              Au moins tout cela était intéressant à lire !

              plus le langage est de haut niveau plus il y a de comportements déclaratifs ou implicites

              Je ne perçois pas bien ce que cela signifie concrètement.

              • [^] # Re: Remplacer l'assembleur par Ada ou Rust ?

                Posté par . Évalué à 0.

                plus le langage est de haut niveau plus il y a de comportements déclaratifs ou implicites

                Je ne perçois pas bien ce que cela signifie concrètement.

                Je veux dire que c'est plus simple d'auditer un switch case tout moche qu'un ensemble de méthodes surchargées (polymorphisme dynamique) qui prennent des lambda en paramètre.

                • [^] # Re: Remplacer l'assembleur par Ada ou Rust ?

                  Posté par . Évalué à 6.

                  Il y a un juste milieu entre du code indigeste et du code obfusqué, quand même…

                  "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                • [^] # Re: Remplacer l'assembleur par Ada ou Rust ?

                  Posté par . Évalué à 6.

                  Le comportement déclaratif il porte en général une sémantique qui fait que le compilateur doit nécessairement garantir des tas de propriétés qu'il font que c'est plus simple de vérifier, voire de prouver qu'il est exempt d'une certains classe de bugs. Pour l'implicite, je vois pas trop le rapport avec la hauteur du langage, les cast implicites il y en a en C et c'est pas toujours beau à voir.

          • [^] # Re: Remplacer l'assembleur par Ada ou Rust ?

            Posté par . Évalué à 6.

            Malheureusement, sans vouloir faire des comparaisons dé raisonnés, les
            centrales nucléaires sont conçus avec un risque de 0.000000001% et
            pourtant déjà elles ont explosé plusieurs fois.

            Haha.

            https://www.youtube.com/watch?v=a7dxnTNOwZE

      • [^] # Re: Une analyse du bug.

        Posté par . Évalué à 5.

        Un autre intérêt du C, c'est que de par sa rusticité, ça se compile sur un tas d'architectures différentes. Et quand tu veux porter openssl sur une nouvelle architecture ça me paraît plus simple d'adapter le programme en C que de porter le compilateur + runtime de Rust/Ada/etc.

  • # Debian Jessie

    Posté par . Évalué à 2.

    Les informations chez Debian sont incohérentes :

    D'un côté :
    http://www.debian.org/security/2014/dsa-2896.en.html
    For the testing distribution (jessie), this problem has been fixed in version 1.0.1g-1.

    De l'autre :
    https://security-tracker.debian.org/tracker/CVE-2014-0160
    jessie 1.0.1f-1 vulnerable

    Au final, l'apt-get update/upgrade ne propose pas la version 1.0.1g

    Pour moi, Jessie est toujours vulnérable, alors que les autres versions debian ne le sont pas ou plus.

    • [^] # Re: Debian Jessie

      Posté par . Évalué à 10.

      J'espère que juste que ce n'est pas une correction à la debian :

      Titre de l'image

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: Debian Jessie

      Posté par . Évalué à 3.

      Bon, pour les impatients comme moi, vous pouvez repackager openssl pour jessie en le compilant avec l'option -DOPENSSL_NO_HEARTBEATS

      bash$ apt-get source openssl
      bash$ cd openssl-1.0.1f
      bash$ vi Configure

      j'ai rajouté ligne 1519 après :
      cflags.=" -DOPENSSL_BN_ASM_GF2m" if ($bn_obj =~ /-gf2m/);

      la ligne :
      $cflags.=" -DOPENSSL_NO_HEARTBEATS";

      ensuite :

      bash$ dpkg-buildpackage -b -D

      rajoutez -j(nombre de coeur) pour aller plus vite

      bash$ cd …

      Vous trouverez 2 package .deb créés :

      bash$ dpkg -i openssl_1.0.1f-1_amd64.deb libssl1.0.0_1.0.1f-1_amd64.deb

      Redémarrez votre service apache.

      En utilisant cet outil python http://s3.jspenguin.org/ssltest.py vous pourrez valider que votre serveur n'est plus vulnérable.

      No heartbeat response received, server likely not vulnerable

      • [^] # Re: Debian Jessie

        Posté par (page perso) . Évalué à 2.

        • [^] # Re: Debian Jessie

          Posté par (page perso) . Évalué à -1. Dernière modification le 09/04/14 à 06:36.

          Méfiance, hier chez Debian ils disaient que la 1.0.1e-2+deb7u5 était corrigée, mais il semble que non.

          Hier sur https://security-tracker.debian.org/tracker/CVE-2014-0160 on lisait :

          wheezy              1.0.1e-2+deb7u4 vulnerable
          wheezy (security)   1.0.1e-2+deb7u5 fixed
          

          hors pourtant :

          root@box:~ # apt-get update
          root@box:~ # apt-get -y install openssl=1.0.1e-2+deb7u5
          root@box:~ # reboot
          luser@box:~ $ wget http://pastebin.com/download.php?i=WmxzjkXJ -O ssltest.py
          luser@box:~ $ python ssltest.py localhost | tail -n 1
          WARNING: server returned more data than it should - server is vulnerable!
          

          Alors qu’on devrait obtenir quelque chose comme :

          luser@box:~ $ python ssltest.py linuxfr.org | tail -n 1
          No heartbeat response received, server likely not vulnerable
          

          Aujourd’hui sur https://security-tracker.debian.org/tracker/CVE-2014-0160 on lit :

          wheezy              1.0.1e-2+deb7u4 vulnerable
          wheezy (security)   1.0.1e-2+deb7u6 fixed
          

          Une version 1.0.1e-2+deb7u6 serait sortie, mais là-encore…

          root@box:~ # apt-get update
          root@box:~ # apt-get -y install openssl=1.0.1e-2+deb7u6
          root@box:~ # reboot
          luser@box:~ $ python ssltest.py localhost | tail -n 1
          WARNING: server returned more data than it should - server is vulnerable!
          

          Qui croire ?

          ce commentaire est sous licence cc by 4 et précédentes

          • [^] # Re: Debian Jessie

            Posté par (page perso) . Évalué à 4.

            A priori le bug est bien corrigé par 1.0.1e-2+deb7u5, 1.0.1e-2+deb7u6 rajoute un test au moment de la mise à jour pour détecter quels services sont vulnérables (et les relancer, histoire que tu n'aies pas à le faire manuellement).
            Question bête : tu as bien mis à jour libssl1.0.0 ?

            • [^] # Re: Debian Jessie

              Posté par (page perso) . Évalué à 2.

              Ouch, merci, c’était très bête…

              En installant libssl1.0.0=1.0.1e-2+deb7u6, automatiquement dkg-reconfigure me propose de redémarrer :

              ssh ntp nginx exim4 bind9

              Et sans même rebooter :

              $ python ssltest.py localhost | tail -n 1
              No heartbeat response received, server likely not vulnerable
              

              Hum, il aurait été plus prudent que Debian déclare le paquet openssl comme dépendant du paquet libssl avec une dépendance = ou >= à la version du paquet d’openssl.

              ce commentaire est sous licence cc by 4 et précédentes

              • [^] # Re: Debian Jessie

                Posté par (page perso) . Évalué à 2.

                Attention, le paquet ne détecte pas tous les cas. Par exemple stud, mysql/mariadb et pure-ftpd ne sont pas détectés comme services à relancer, à tort.

                alf.life

                • [^] # Re: Debian Jessie

                  Posté par . Évalué à 1.

                  perso quand j'ai fait la MAJ j'avais que le patch u5 du coup mon apache n'a pas été redémarré, je m'en suis rendu compte en testant le soir….
                  mais du coup ça a été réactif avec le u6 pour ceux qui n'auraient pas pensé à relancer ou tester leurs services.

                  • [^] # Re: Debian Jessie

                    Posté par (page perso) . Évalué à 3.

                    Un outil bien pratique pour tester les process qui tournent sur d'anciennes libs après une mise à jour, c'est checkrestart :

                    # apt-get install debian-goodies
                    # checkrestart

                    Tant qu'il le peut il listera les services concernés, sinon il est parfois utile de le lancer avec -v pour obtenir plus de détails.

                  • [^] # Re: Debian Jessie

                    Posté par . Évalué à 2.

                    A noter qu'un reload semble suffir pour apache.

                    • [^] # Re: Debian Jessie

                      Posté par (page perso) . Évalué à 8.

                      Un reload suffit peut-être pour qu’Apache utilise la version mise à jour de la bibliothèque, mais ça ne corrigera pas le fait que les clefs privées des certificats SSL ont peut être déjà fuité…

                      Donc non, on ne peut pas simplement mettre à jour libssl, recharger les serveurs et se croire tranquille. Il faut aussi renouveller les certificats.

          • [^] # Re: Debian Jessie

            Posté par . Évalué à 4.

            Ton serveur apache doit encore utiliser les anciennes libs.

            Tente un "lsof -n | grep ssl | grep DEL".

            Si tu vois des trucs, il faut que tu redémarres apache (et tout autre process que tu verrais dans le lot). Ceci dit, Debian a sorti en fin de journée un autre patch qui se charge de redémarrer tous les services nécessaires (le u6 que tu vois sûrement), mais j'ai pas testé.

      • [^] # Re: Debian Jessie

        Posté par . Évalué à 1.

        -DOPENSSL_

        D'oh !!!!
        Bon désolé c'était facile.

        Pour revenir aux choses sérieuses, il fut un temps où j'utilisais debian testing, et je me suis toujours demandé comment étaient gérées les failles de sécurité de ce type. Vu que c'est du testing est-ce sécurisé à 100 % ? Pas sûr…

    • [^] # Re: Debian Jessie

      Posté par . Évalué à 3.

      C'est un défaut (ou une qualité?) de testing (jessie): tout ses paquets proviennent de sid, y compris les corrections de sécurité. Il faudra donc un passage des paquets ssl dans sid (plus ou moins long, cela dépend de la température du fut du canon) avant de les voir débarquer dans jessie…

      • [^] # Re: Debian Jessie

        Posté par . Évalué à 4.

        D'après la FAQ :

        La sécurité pour testing bénéficie des efforts sur la sécurité réalisés par tout le projet pour unstable. Cependant, un délai minimal de deux jours existe pour la migration, et les correctifs de sécurité peuvent parfois être retenus par les transitions. L’équipe chargée de la sécurité aide à faire avancer ces transitions qui retiennent les envois de sécurité importants, mais ce n’est pas toujours possible et des contretemps peuvent survenir. En particulier, les mois qui suivent une nouvelle publication de stable, quand de nombreuses nouvelles versions sont envoyées dans unstable, les correctifs de sécurité pourraient être mis en attente. Si vous souhaitez un serveur sûr (et stable), vous devriez garder la distribution stable.

        http://www.debian.org/security/faq#testing

  • # Correctif pour FreeBSD

    Posté par (page perso) . Évalué à 0.

    Someone please correct me if I'm wrong, but I think simply adding
    -DOPENSSL_NO_HEARTBEATS to crypto/openssl/Makefile (and recompiling!) is
    sufficient to remove the vulnerability from the base system.
    
    -nd.
    

    http://lists.freebsd.org/pipermail/freebsd-security/2014-April/007417.html

    Love – bépo

    • [^] # Re: Correctif pour FreeBSD

      Posté par (page perso) . Évalué à 7.

      Correctif?
      Hum… un correctif n'enlève pas de fonctionnalités.
      c'est plutôt un hot-fix avec regressions en attendant un meilleur patch (qui n'enlèvera pas de fonctionnalité).

      • [^] # Re: Correctif pour FreeBSD

        Posté par (page perso) . Évalué à 1. Dernière modification le 08/04/14 à 20:44.

        Heu oui en effet… trop tard pour éditer.

        En plus il ne suffit pas de relancer un make. Bref, FreeBSD, quand ça touche le système de base, c’est chiant, y’a pas à dire.

        Love – bépo

    • [^] # Re: Correctif pour FreeBSD

      Posté par (page perso) . Évalué à 2. Dernière modification le 08/04/14 à 20:49.

      Ah, un correctif (un vrai cette fois) est passé sur -releng et -stable. Plus qu’à attendre les builds.

      Sinon il y a aussi WITH_OPENSSL_PORT=yes dans /etc/make.conf, et à utiliser avec poudriere également quand on l’utilise. Le port a été corrigé bien plus vite.

      Love – bépo

  • # et les "Application Serveur" ?

    Posté par . Évalué à 2.

    la faille a un impact sur Apache (utilise les librairies de openssl) mais est-ce que JBoss et Tomcat sont impactés ?

    Je veux dire par là, est-ce que un Tomcat avec SSL activé à besoin d'une nouvelle version de la librairie de OpenSSL (LD_LIBARY_PATH) et redemarrage ?

    Java utilise le package "java.security" mais est-ce une reimplmentation ssl ou la lib openssl est utilisé ?

    merci pour vos lumières
    Gilles

  • # La crypto des Unix libre owned par la nsa

    Posté par . Évalué à 2. Dernière modification le 09/04/14 à 22:36.

    Et vous avez lue ça http://igurublog.wordpress.com/2014/04/08/julian-assange-debian-is-owned-by-the-nsa/ ?

    De ce que j'ai compris, et vous pouvez me reprendre, mon anglais lue est assez limite, tout les Unix libre sont nivelé par le bas par la nsa au niveau cryptographique.

    Il est dis que la faille dont on parle dans cette news est inadmissible, presque une erreur de débutant d'avoir ce genre de probléme, donc voulue.

    Une note d'espoir quand même, avoir un niveau cryptographique robustre est possible, mais faut être gouru niveau 6 (sans blague!).

    Si des gens sont motivé pour faire le sous titrage de la vidéo d'Assange et publier ça histoire de nous faire découvrir ce qu'il a à dire, nous leur serions reconnaissant.

    Allez tous vous faire spéculer.

  • # redémarrage des services sur Debian testing

    Posté par . Évalué à 5.

    à noter que debian testing vient d'ajouter la détection des services dépendant de openssl pour les relancer lors de l'installation du paquet: une initiative très appréciable qui rendra les futures mises à jours beaucoup plus aisées

  • # Debian compromis par la NSA ?

    Posté par . Évalué à 4. Dernière modification le 09/04/14 à 22:48.

    Je ne vais pas ouvrir un journal juste pour ça, d'autant que l'info est connexe à celle-ci (Elie vient de poster au-dessus le même lien pendant que je rédigeais ma réponse), et que sans preuve formelle on est pour le moment plutôt dans le domaine du troll ultime que de la démonstration, mais cette accumulation de failles critiques peut rendre parano et ouvrir la porte à la théorie du complot.

    En effet, outre Heartbleed (avec les polémiques sur sa découverte, la date de diffusion publique…) et les deux autres listées en fin de dépêche (Gnu TLS, Apple), celle plus ancienne touchant déjà OpenSSL sur les alertes Valgrind, voilà maintenant que ressort la rumeur du "contrôle" de Debian et autres distributions Linux par la NSA, conférence donnée par le fondateur de Wikileaks Julian Assange :

    http://igurublog.wordpress.com/2014/04/08/julian-assange-debian-is-owned-by-the-nsa/
    http://cyrille-borne.com/post/2014/04/09/assange-est-il-un-trolleur-debian-est-elle-compromise

    En l'état bien sûr, impossible d'affirmer quoi que ce soit, à moins que le Guardian ne publie prochainement un slide issu des documents sourcés par Snowden - là je devrais être bon question mots clés sensibles !

    De plus, nul besoin d'une taupe gouvernementale pour introduire un bug, nulle nécessité non plus de croire que c'est forcément volontaire, au contraire.

    Le code évoluant constamment, à tout moment il peut y avoir des régressions, la sécurité devenant de plus en plus vitale les programmes open-source sont régulièrement audités attentivement, d'où la découverte des failles majeures. Toujours est-il que cela fait beaucoup en peu de temps et que cela alimente les suspicions.

    Mais espérons que cela fasse progresser la sécurisation globale des serveurs et outils informatiques, tout comme la prise de conscience des usagers et entreprises de veiller à leur intégrité (surveillance, mise à jour, sauvegardes).

    • [^] # Re: Debian compromis par la NSA ?

      Posté par (page perso) . Évalué à 10.

      Il est pratiquement certains que la NSA a tenté de réduire la sécurité logicielle que ce soit dans le code mais aussi dans les normes eux mêmes. Et il est tout aussi possible que d'autres États soient dans le coup.

      Si cela peut paraître très inquiétant, il y a aussi des avantages à cela :

      • S'ils se donnent du mal à réduire la sécurité à la source, c'est que les algorithmes et les mathématiques derrière la sécurité sont sûres et que a factorisation des nombre premiers très grands n'a pas été résolu chez eux (si solution il existe). Donc il y a moyen de revenir à une sécurité optimale.
      • En baissant la sécurité de tout le monde, ils abaissent la sécurité de leur propre pays. Je suis sûr que les États ennemis des États-Unis profiteront de cela un jour contre eux. Les politiques américains commencent à réaliser ce problème, ce qui pourrait garantir l'arrêt de ces techniques.

      Bref, il y a de l'espoir, même si la situation est sensible.

      • [^] # Re: Debian compromis par la NSA ?

        Posté par . Évalué à 4.

        que a factorisation des nombre premiers très grands n'a pas été résolu chez eux (si solution il existe).
        Pourtant ils ont recommandé de passer aux courbes elliptiques et de ne plus utiliser RSA…
        En même temps il est vrai qu'ils ont poussé des courbes particulières sans dire comment elles ont été choisies (plutôt que d'utiliser un processus déterministe et vérifiable à la brainpool afin d'obtenir des paramètres non choisis tels que http://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number ).

      • [^] # Re: Debian compromis par la NSA ?

        Posté par . Évalué à 10.

        la factorisation des nombre premiers très grands n'a pas été résolu chez eux

        Factoriser un nombre premier grand ou petit est effectivement un problème qui ne sera jamais résolu, par définition.
        C'est un peu comme tracer 7 lignes rouges perpendiculaires entre elles

        ;-)

        (désolé c'était un peu facile de profiter de ton raccourci)

      • [^] # Re: Debian compromis par la NSA ?

        Posté par . Évalué à 5.

        S'ils se donnent du mal à réduire la sécurité à la source, c'est que les algorithmes et les mathématiques derrière la sécurité sont sûres et que a factorisation des nombre premiers très grands n'a pas été résolu chez eux

        moi je dis ils bluffent

        splash!

      • [^] # Re: Debian compromis par la NSA ?

        Posté par . Évalué à 1.

        J'ai pas l'impression que la NSA agit dans l'interet national, plutot dans leur interet a eux.

        En clair, la security du pays, ils s'en foutent, ce qui les interesse c'est d'espionner tout ce qui se dit, americain ou pas. Dans cette perspective, t'as interet a baisser la securite de tout le monde.

        Linuxfr, le portail francais du logiciel libre et du neo nazisme.

        • [^] # Re: Debian compromis par la NSA ?

          Posté par (page perso) . Évalué à 1.

          Leur but est d'avoir plus d'informations que l'ennemi. En abaissant la sécurité de tous, l'ennemi peut avoir autant voire plus d'informations qu'eux.

          • [^] # Re: Debian compromis par la NSA ?

            Posté par . Évalué à 4.

            Oui mais vu les informations recentes l'ennemi c'est tout le monde y compris les americains. Parceque ne nous leurrons pas, certains americains et en particulier dans les spheres politiques veulent mettre des limites sur la capacites de la NSA d'espionner les americains des USA le reste ils ne veulent surtout pas changer.

            Cela apporte des informations militaires mais aussi (surtout?) economique et ils s'en servent. L'ennemi economique etant bien different de l'ennemi militaire.

            • [^] # Re: Debian compromis par la NSA ?

              Posté par . Évalué à 6.

              certains américains et en particulier dans les sphères politiques veulent mettre des limites sur la capacités de la NSA d'espionner les américains des USA le reste ils ne veulent surtout pas changer.

              Ça va même plus loin que ça. Les membres du congres US ont commencé à s’inquiéter quand ils ont appris que leurs conversations (via email ou téléphone) étaient susceptibles d’être espionnées. Avant ça, ils n'en avaient rien à foutre, citoyens US ou pas.

          • [^] # Re: Debian compromis par la NSA ?

            Posté par . Évalué à 2. Dernière modification le 13/04/14 à 22:13.

            En abaissant la sécurité de tous, l'ennemi peut avoir autant voire plus d'informations qu'eux.

            La NSA est plus maligne que ça : pour le générateur d'aléa troué, seule la NSA peut profiter de la vulnérabilité (en connaissant la clef privée, c'est un système quasi à clef publique). Les autres peuvent se brosser.
            Dans l'affaiblissement de Notes il y a quelques années, c'était la même chose : les clefs 128 bits étaient séparées en 40 bits d'un côté, 88 autres qui étaient chiffrés sous une clef publique NSA. Seule la NSA pouvait déchiffrer, la sécurité du bousin restait de 128 bits pour le reste du monde.

            • [^] # Re: Debian compromis par la NSA ?

              Posté par (page perso) . Évalué à 2.

              La NSA est plus maligne que ça : pour le générateur d'aléa troué, seule la NSA peut profiter de la vulnérabilité

              Non, n'importe qui qui fait des recherches sur ce générateur peut tomber sur la solution qui l'affaiblit. Et rien ne dit qu'il va l'utiliser à bon escient.

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

              • [^] # Re: Debian compromis par la NSA ?

                Posté par . Évalué à 6.

                Non. L'affaiblissement du générateur d'aléa (EC_DRBG) est lié à un problème similaire à une clef publique : n'importe qui peut comprendre le problème, mais récupérer la solution qui l'affaiblit sans avoir l'info secrète de la NSA revient à résoudre un problème de logarithme discret sur courbe elliptique, c'est-à-dire à savoir péter à peu près tous les systèmes actuellement en cours de déploiement.
                Cf les slides http://www.wired.com/images_blogs/threatlevel/2013/09/15-shumow.pdf (slide 8, deuxième point).

                Dans ce cas, la NSA a affaibli le standard pour elle seule.

    • [^] # Re: Debian compromis par la NSA ?

      Posté par (page perso) . Évalué à 2.

      Attention la NSA doit à la fois protéger les institutions Américaine des intrusions et s'introduire dans les institutions étrangères, sauf que le marché informatique est mondial et donc ces institutions utilisent les mêmes logiciels. En affaiblissant les logiciels libres, elles risques d'affaiblir la sécurité des institutions Américaine.

      • [^] # Re: Debian compromis par la NSA ?

        Posté par (page perso) . Évalué à 10.

        C'est amusant cette hypothèse qui implique que la NSA n'a pas d'intérêt à s'infiltrer dans les systèmes de sociétés états-uniennes.

        pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

  • # Et les systèmes embarqués ?

    Posté par (page perso) . Évalué à 10.

    On parle beaucoup du web en lui même, mais peu des périphériques embarqués qui peuvent être aussi touchés mais dont les mises à jour sont plus délicates : téléphones, télévisions, boxs Internet, NAS, autres… Ces périphériques peuvent contenir cette bibliothèque et sont des éléments contenant potentiellement de nombreuses données personnes voire 'accès intégral à d'autres périphériques.

    Pourtant les gens semblent se concentrer uniquement sur des services web, alors qu'ils ont (normalement) tous corriger leur infrastructure, ces périphériques ce serait une autre paire de manche…

    • [^] # Re: Et les clients ?

      Posté par . Évalué à 5.

      Et on parle aussi beaucoup des serveurs, mais moins des clients vulnérables :
      what-clients-are-proven-to-be-vulnerable-to-heartbleed

      Personnellement j'avais bien pensé à patcher mon serveur mais pas mes ordinateurs personnels (wget, git…).

      • [^] # Re: Et les clients ?

        Posté par . Évalué à 6.

        En me servant de pacemaker, je me suis aperçu par exemple que le navigateur "samsung" de ma tablette android était vulnérable. Et hop, l'historique de navigation et les cookies qui fuitent vers le serveur.

        Ça fait peur…

  • # Tester sa clé privée

    Posté par . Évalué à 10.

    Enfin un service utile. On peut au moins tester si notre clé privée a fuité grace à ce site http://privatekeycheck.com/. '-_-

    • [^] # Re: Tester sa clé privée

      Posté par (page perso) . Évalué à 6.

      Bonne initiative, mais j'aurais préféré une version pour tester le code bancaire et le mot de passe…

    • [^] # Re: Tester sa clé privée

      Posté par (page perso) . Évalué à 4.

      Alice et Bob me chargent de te dire qu'ils sont très très fâchés avec tout ça…

    • [^] # Re: Tester sa clé privée

      Posté par (page perso) . Évalué à 4.

      Rhoo, c'est pas gentil pour les naïfs ! Ne me dite pas qu'il n'y en a pas, on voit bien des développeurs faire des commit de leurs clefs privées.

      C'est presque du phishing là !

      • [^] # Re: Tester sa clé privée

        Posté par (page perso) . Évalué à 3.

        Rhoo, c'est pas gentil pour les naïfs ! Ne me dite pas qu'il n'y en a pas, on voit bien des développeurs faire des commit de leurs clefs privées.

        Ouais enfin, je ne sais pas si "naifs" est le juste terme pour qualifier des personnes pareilles.

  • # Debian stable wheezy à jour mais version 1.0.1e

    Posté par . Évalué à 0.

    Je viens de mettre à jour debian stable wheezy, qui me propose une mise a jour d'openssl. Sauf qu'en regardant la version :

    openssl version
    OpenSSL 1.0.1e 11 Feb 2013

    Etrange, alors que la 1.0.1e fait partie des version vulnérable.. chez vous c'est pareil ?

    • [^] # Re: Debian stable wheezy à jour mais version 1.0.1e

      Posté par (page perso) . Évalué à 6.

      Si tu regarde mieux, c'est la version 1.0.1e+ deb7u6 qui inclut le patch de correction.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Debian stable wheezy à jour mais version 1.0.1e

        Posté par . Évalué à -1.

        Ah… et comment peut-on savoir qu'il s'agissait d'un patch ? en recherchant l'occurence "deb7u6" sur le web pour en obtenir des infos, ou il y a t'il une signification spécifique derrière ça ?

        On a pu me faire remarquer qu'avec un openssl version -b :
        *built on: Tue Apr 8 10:05:11 UTC 2014

        Du coup d'après la date, ça corrige bien le bug.

        • [^] # Re: Debian stable wheezy à jour mais version 1.0.1e

          Posté par (page perso) . Évalué à 7.

          apt-listchanges -a /var/cache/apt/archives/openssl_1.0.1e-2+deb7u6_amd64.deb

          ou

          zless /usr/share/doc/openssl/changelog.Debian.gz

          openssl (1.0.1e-2+deb7u6) wheezy-security; urgency=high

          • Non-maintainer upload by the Security Team.
          • Enable checking for services that may need to be restarted
          • Update list of services to possibly restart

          -- Salvatore Bonaccorso carnil@debian.org Tue, 08 Apr 2014 10:44:53 +0200

          openssl (1.0.1e-2+deb7u5) wheezy-security; urgency=high

          • Non-maintainer upload by the Security Team.
          • Add CVE-2014-0160.patch patch.
            CVE-2014-0160: Fix TLS/DTLS hearbeat information disclosure.
            A missing bounds check in the handling of the TLS heartbeat extension
            can be used to reveal up to 64k of memory to a connected client or
            server.

          -- Salvatore Bonaccorso carnil@debian.org Mon, 07 Apr 2014 22:26:55 +0200
          ```

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: Debian stable wheezy à jour mais version 1.0.1e

          Posté par (page perso) . Évalué à 3.

          "deb7u6" […] il y a t'il une signification spécifique derrière ça

          "deb7u6" = Debian 7 (Wheezy) update 6.

          Les mises à jour 5 et 6 (deb7u5, deb7u6) de l’équipe de sécurité servent justement à corriger la faille Heartbleed (cf. l’autre réponse de Xavier Claude pour le vérifier).

Suivre le flux des commentaires

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