• # Debian et dérivées

    Posté par . Évalué à  4 .

    Ça ne concerne pas que Debian, mais aussi les distributions dérivées de Debian (Ubuntu, MEPIS, etc).

    "Heureusement", c'est spécifique Debian.
    Mais notons bien que Debian n'a pas proposé le patch en upstream...
    En upstream on lui aurait : "- malheureux, ne fais pas ça !"
    • [^] # Re: Debian et dérivées

      Posté par . Évalué à  2 .

      Pour ubuntu, ça concerne les versions 7.04, 7.10 et 8.04.

      http://www.ubuntu.com/usn/usn-612-1
      http://www.ubuntu.com/usn/usn-612-2
      • [^] # Re: Debian et dérivées

        Posté par . Évalué à  3 .

        #apt-get dist-upgrade
        ...
        ATTENTION : les paquets suivants n'ont pas été authentifiés.
        ... libssl-dev libssl0.9.8 openssh-client openssh-server openssl ...

        Ils les ont signés avec le nouveau openssl? (loup qui se mord la queue toussa?)
        • [^] # Re: Debian et dérivées

          Posté par . Évalué à  5 .

          Ça n'affecte pas les clées générées avec gpg.
          • [^] # Re: Debian et dérivées

            Posté par . Évalué à  1 .

            ok, je savais pas.
            Mais c'est quand même bizarre de pas signer des paquets aussi cruciaux.
            • [^] # Re: Debian et dérivées

              Posté par . Évalué à  4 .

              > Mais c'est quand même bizarre de pas signer des paquets aussi cruciaux.

              C'est clair.

              C'est simple, chez moi je n'installe jamais un paquet non-signé. Ou alors après une vérification, ou pour une bécane de test, etc.
              Si c'est pour ma bécane ou une bécane en production, alors ça doit être signé.

              Bref => n'installes pas.
              • [^] # Re: Debian et dérivées

                Posté par . Évalué à  3 .

                t'inquiètes pas, j'attends la version signée. Je n'installe jamais de paquets pas signés.
                IMHO, la conf par défaut de apt-get devrait forcer à passer une option en ligne de commande (genre --oui-je-suis-sur-j-assume ) avant de proposer de contourner la signature. Là c'est trop facile d'accepter, et ceux qui n'ont jamais entendu parler d'openssl (la cible ubuntu) penseront à une question "are you sure?" de plus, et accepteront. D'ailleurs la mise à jour est noyée au milieu de trucs classiques (bash cpp libgcj-bc libgphoto2-2... ).
              • [^] # Re: Debian et dérivées

                Posté par . Évalué à  10 .

                C'est simple, chez moi je n'installe jamais un paquet non-signé.

                Et dire que tu me traitais de parano parce que j'utilise https quand c'est disponible... hôpital, charité, tout ça... ;)

                (oui oui, c'est hors-sujet, -1)
                • [^] # Re: Debian et dérivées

                  Posté par . Évalué à  1 .

                  C'est ma bécane !
                  Tu vois la nuance ?
                  L'installation d'un paquet rpm peux exécuter n'importe quelque script ou programme sous root.
                  • [^] # Re: Debian et dérivées

                    Posté par . Évalué à  8 .

                    Tu vois la nuance ?
                    Non. Mais je ne voulais pas relancer le débat, juste te taquiner un peu.
    • [^] # Re: Debian et dérivées

      Posté par . Évalué à  1 .

      Là il est clair que c'est une énorme bourde des mainteneurs du paquet OpenSSL de Debian.
      Plusieurs personnes parlent de retirer le paquet des mains du ou des coupables...
      • [^] # Re: Debian et dérivées

        Posté par . Évalué à  6 .

        On va peut-être éviter les expéditions punitives ?

        Il a certainement très bien retenu la leçon maintenant.

        Par contre, faudrait qu'Ubuntu qui fait des distributions "entreprise" audite mieux ce qui est fait pour les paquets critiques. Ça fait depuis 1 an que ça traine chez Ubuntu.

        Espérons qu'aucune bécane ne va être crackée, sinon Ubuntu va se prendre une volée de bois vert.
    • [^] # Re: Debian et dérivées

      Posté par . Évalué à  2 .

      > En upstream on lui aurait : "- malheureux, ne fais pas ça !"

      En fait :
      http://www.links.org/?p=327
      we (the OpenSSL Team) would have fallen about laughing, and once we had got our breath back, told them what a terrible idea this was.
      • [^] # Re: Debian et dérivées

        Posté par . Évalué à  6 .

        et si on lit les commentaires , on 'est renvoyé vers :
        http://marc.info/?t=114651088900003&r=1&w=2
        où on voit que
        1°) le dvp debian a demandé upstream
        2°) la team openssl a dis "Si c'est pour le debug, je suis d'avis qu'on puisse le virer".

        Comme quoi, rien n'est simple, et, une chose est sur, les gens qui se moquent après ne valent guère.

        Comme disait dans un manga "J'ai vu personne me faire chier pendant, alors venait pas pas me faire chier après".
        • [^] # Re: Debian et dérivées

          Posté par . Évalué à  2 .

          > 2°) la team openssl a dis "Si c'est pour le debug, je suis d'avis qu'on puisse le virer".

          Ben oui. Mais Debian ne l'a pas fait que pour la version debug.
          Le patch qui corrige :
          http://svn.debian.org/wsvn/pkg-openssl/openssl/trunk/crypto/(...)

          Où tu vois le "#ifdef ..." ?
          • [^] # Re: Debian et dérivées

            Posté par . Évalué à  7 .

            pas dis que debian était au dessus de tout reproche, mais quand je vois quelqu'un dire "si ils étaient venu nous dire ca on lui aurai ri a la gueule" (alors que c'était loin d'etre trivial comme probleme), je trouve ca plutot naze...
            • [^] # Re: Debian et dérivées

              Posté par . Évalué à  2 .

              > mais quand je vois quelqu'un dire "si ils étaient venu nous dire ca on lui aurai ri a la gueule"

              Mais ce n'est pas grave !
              C'est le rire, ce n'est pas controlable.
              Ils auraient bien rigolé, puis lui aurait dit de ne pas faire cette connerie.

              Mais clairement ils préfèrent être informé (et si en plus c'est l'occasion de se marrer :-)).

              Avec cette faille diffusé à des millions d'exemplaires, c'est beaucoup moins drole.
              • [^] # Re: Debian et dérivées

                Posté par . Évalué à  9 .

                ben qu'un gars qui n'a pas fait la moindre recherche (vu que le probleme a été évoqué sur la liste de diffusion d'openssl), s'impose comme "expert" sur un sujet déja traité, alors que les "experts" a ce moment, avait dit que ce n'était pas forcément critique.(sous certaines conditions je suis d'accord).
                Que cette personne donne des leçon, alors que les problèmes avaient déja été soulevé par le dvp debian en personne avant même de lancer le patch.

                Bref, en gros que la personne du billet traite tout le monde de haut sans prendre la peine de se renseigner un minimum, et essaie de se faire mousser comme ça, pour moi ca reste bien naze.
            • [^] # Re: Debian et dérivées

              Posté par . Évalué à  5 .

              pas dis que debian était au dessus de tout reproche, mais quand je vois quelqu'un dire "si ils étaient venu nous dire ca on lui aurai ri a la gueule" (alors que c'était loin d'etre trivial comme probleme), je trouve ca plutot naze...


              Attention il y a deux choses :
              - Premièrement les mainteneurs Debian ont demandés si c'était normal que le pool d'entropie ne soit pas initialisé à la création. Ce à quoi l'équipe OpenSSL a répondu que pour le debug ils pouvaient initialiser le pool.
              - Deuxièmement les mainteneurs Debian ont ont retirés toute possibilité d'ajouter de l'entropie à ce pool (c'est à dire qu'il ne se sont pas contenter de l'initialiser, maisqu'ils l'ont vérouillé à une valeur connue), enlevant ainsi 99% de l'aléatoire dans la génération de clefs.

              Autant le premièrement n'est pas trivial, autant le deuxièmement montre qu'ils sont complètement à coté de la plaque.
              • [^] # Re: Debian et dérivées

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

                - Premièrement les mainteneurs Debian ont demandés si c'était normal que le pool d'entropie ne soit pas initialisé à la création. Ce à quoi l'équipe OpenSSL a répondu que pour le debug ils pouvaient initialiser le pool.
                - Deuxièmement les mainteneurs Debian ont ont retirés toute possibilité d'ajouter de l'entropie à ce pool (c'est à dire qu'il ne se sont pas contenter de l'initialiser, maisqu'ils l'ont vérouillé à une valeur connue), enlevant ainsi 99% de l'aléatoire dans la génération de clefs.


                Je ne suis pas d'accord avec ton interprétation de la réponse et du patch. Relis bien tout le thread en question : le mainteneur Debian quote les deux lignes qu'il souhaite supprimer, et il est même très prudent : « But I have no idea what effect this
                really has on the RNG ». Un des mecs de l'équipe de développement d'OpenSSL répond : « If it helps with debugging, I'm in favor of removing them. ». Il répond à la demande de suppression des deux lignes (ce qui deviendra exactement le patch), pas à la question en rapport avec la non initialisation du buffer. Donc à l'erreur consistant à supprimer toute entropie au pool. Il n'a pas vu l'erreur lui non plus !

                Pour moi, le mainteneur Debian n'a rien à se reprocher quant à son comportement. Il a fait une énorme boulette, mais il l'a faite dans les règles de l'art : avec des doutes, et en demandant upstream. Si upstream dit que c'est bon, eh bien voilà, les torts sont largement partagés.
                • [^] # Re: Debian et dérivées

                  Posté par . Évalué à  1 .

                  Sauf erreur de ma part (j'ai pas de quoi aller ouvrir les vieux .deb et vérifier par moi même) le problème ne vient pas tant du patch que du fait que tous les packages debian ont étés compilé avec l'option purify.
                  • [^] # Re: Debian et dérivées

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

                    Non, le problème vient bien de la suppression des deux lignes MD_Update. Je t'ai mis le diff de etch "d'origine" ici si tu veux voir, il n'y a aucune activation particulière de purify.

                    http://zarb.org/~gc/t/openssl_0.9.8c-4etch1.diff.gz
                    • [^] # Re: Debian et dérivées

                      Posté par . Évalué à  4 .

                      La pratique d'avoir une branche Debian est très très discutable.
                      Chez Fedora ce sont les patchs individuels qui sont stockés. Il est alors facile de savoir qui fait quoi et pourquoi. Il est plus facile d'envoyer des patchs en upstream, de faire auditer ses patchs, etc.
                      Cette pratique de Debian a aussi agacé Mozilla...
                      J'espère que tous les paquets Debian ne sont pas géré comme ça. Parce qu'en gros Debian fait un fork.
                      • [^] # Re: Debian et dérivées

                        Posté par . Évalué à  3 .

                        La pratique d'avoir une branche Debian est très très discutable.

                        Oui et non, parfois c'est même à peu près obligatoire. par exemple pour FFMpeg, vu le nombre de logiciels qui utilisent des versions légèrement différentes de cette lib c'est très vite la pagaille. Le plus simple est d'avoir une seule lib pour toutes les applis quitte à modifier les applis pour qu'elles fonctionnent avec cette lib là.

                        En plus en cas de faille sur une dépendance c'est nettement plus simple de répercuter la correction juste sur la lib que sur tous les logiciels un par un quand ils inclus chacun leurs lib.
          • [^] # Re: Debian et dérivées

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

            C'est pas exactement "Si c'est pour le debug, je suis d'avis qu'on puisse le virer" qui a ete dit.:

            http://marc.info/?l=openssl-dev&m=114652287210110&w=(...)
            "If it helps with debugging, I'm in favor of removing them. "

            Dans la phrase en anglais, je comprends qu'il est favorable a la proposition de l'enlever definitivement si ca aide pour le debuggage sans parler de condition a la #ifdef DEBUG. Du moins c'est comme ca que je le comprends.
            • [^] # Re: Debian et dérivées

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

              Oui, complètement. D'autant plus que le contexte est le problème à debugger des programmes utilisant openssl avec valgrind à cause de cela. Donc il répond bien que pour faciliter le debug "des applications utilisant openssl", ce patch ne devrait pas faire de mal. Le tort est vraiment partagé.
        • [^] # Re: Debian et dérivées

          Posté par . Évalué à  1 .

          Plus loin dans les commentaires on peut lire :

          It seems that the Debian maintainer did, indeed, mention his plan on openssl-dev. Openssl-dev is a list for people developing OpenSSL based software, not a list for discussing the development of OpenSSL itself. I don’t have the bandwidth to read it myself. If you want to communicate with the OpenSSL developers you need to use openssl-team@openssl.org. At no time, as people have suggested, was a patch offered to OpenSSL, and the discussion on openssl-dev was misleading.

          Donc le dvp debian ne s'est visiblement pas adressé à la bonne personne !
          • [^] # Re: Debian et dérivées

            Posté par . Évalué à  10 .

            et si on regarde openssl-dev on voit des questions comme
            http://groups.google.com/group/mailing.openssl.dev/browse_th(...)

            ou il est question de
            "When doing BIO_pop(), OpenSSL increases the reference counter of the
            remaining BIO chain instead of decreasing it. This leads to memory and
            fd leaks if you use BIO_pop(). Here is a patch: "

            Visiblement c'est loin d'etre le seul a prendre openssl-dev pour la liste de developpement.

            Mais le plus beau c'est pas ca; c'est que si on se renseigne UN MINIMUM : on trouve cette page :
            http://www.openssl.org/support/
            ou il y a marqué :
            openssl-dev open subscribers Discussions on development of the OpenSSL library. Not for application development questions!

            Alors, a ton avis, qui a raison, le site web d'open ssl, ou un commentaire sur un blog qui essaie de se faire mousser ?
            • [^] # Re: Debian et dérivées

              Posté par . Évalué à  2 .

              Le site bien sûr. Mais bloggeur fait partit de la core team d'openssl, si il ne sait pas ou se font les remontés d'info c'est quand même grave !!
              • [^] # Re: Debian et dérivées

                Posté par . Évalué à  2 .

                ben en même temps si ils mettent pas a jour le site, et attendent un truc sur une mailing list, alors que
                1°) la mailing list (openssl-team) en question n'est pas mentionné sur le site, donc peu de "nouvelles" personnes devraient y accéder
                2°) la mailing list des applications (openssl-dev) soit considéré par ce dvpeur comme exactement contraire à sa défintion sur le site
                3°) qu'il existe déja une mailing list pour les applications, mais que bizarrement ils auraient changé

                et que ces 3 fois, il n'a strictement rien remarqué et explique le contraire du site web, faut qu'il arrête la sécurité.
                Quand on voit un truc comme "probleme dans la librairie openssl" sur openssl-dev (et y'a pas franchement qu'un message comme ça) et qu'on se dise pas "bizarre que tout le monde la prenne pour celle de dvp quand meme", pour qu'il arrive a trouver un quelconque bug, je lui souhaite bonne chance.

                Allez, google test :
                "openssl-team@openssl.org" 63 réponses
                "openssl-dev@openssl.org" 19700 réponses.


                pour un projet aussi connu que openssl, pour avoir que 63 réponses sur google dans mailing list de developemment, j'émet quand même certains doutes.


                Bref il me fait furieusement penser à theo : "C'est forcément de la faute des autres.
                Le problème ne peut pas être chez nous/moi".
                Tu remarquera qu'il a pas relevé que le dvp a dis "j'avais bien vu le probleme" mais "il a bien dis ce qu'il voulait faire."
                Il a pas relevé que des gens de la team openssl lui disait "ca semble ok", mais "il c'est gouré de mailing list".
                etc...

                Et comble de l'excuse "je n'ai pas la bande passante nécessaire pour lire openssl-dev" ...
                (sachant qu'il y a des interfaces graphiques avec recherche pour cette liste, ca peut difficilement être une excuse valable, d'autant plus qu'il peut recharger son blog qui prend bien plus en bp ...)
        • [^] # Re: Debian et dérivées

          Posté par . Évalué à  4 .

          > les gens qui se moquent après ne valent guère.

          Je n'ai pas reproché à Debian de faire des patchs, mais de ne pas les remonter upstream.
          Sinon rigolons un peu :
          http://www.br0kenhalo.com/?p=49

          int getRandomNumber() {
              return 4 ;
          }
    • [^] # Re: Debian et dérivées

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

      «En upstream on lui aurait : "- malheureux, ne fais pas ça !"»

      Non, sérieusement, tu veux dire que chez OpenBSD ils utilsent un langage aussi chatié? Rhaa tout fout le camp, je vous le dis ma bonne dame, tout fout le camp...
    • [^] # Re: Debian et dérivées

      Posté par . Évalué à  2 .

      les clefs qui ont été genéré par ce programme et donc pas toutes les debians
      certaines ont des clef généré par une version plus ancienne
  • # Les certifs SSL achetés une fortune...

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

    ... faut les jeter ? (ouf, pas mon cas)
  • # L'image du logiciel libre en prend un coup !

    Posté par . Évalué à  -7 .

    Après une telle bourde, on comprend le refus de la Mozilla Foundation de laisser Debian packager une version de Firefox en laissant croire qu'elle est officielle, alors qu'elle contient des "correctifs" spécifiques à Debian que la MoFo n'a pas envie de devoir assumer...
  • # Pas seulement les cles generees sur Debian

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

    Les cles à considérer comme compromises ne sont seulement celles générées sur les machines Debian/Ubuntu mais aussi celles qui ont étés utilisées sur une machine Debian/Ubuntu:

    Furthermore, all DSA keys ever used on affected Debian systems for signing or authentication purposes should be considered compromised; the Digital Signature Algorithm relies on a secret random value used during signature generation.

    (Dans ce cas là le "bug" ne permet pas de trouver la clé mais de se logger sans avoir besoin de la clé initiale.)

    Pas de chance pour moi, ma clé a été généré sur AIX mais je l'utilise couramment sur Debian :-(
    • [^] # Re: Pas seulement les cles generees sur Debian

      Posté par . Évalué à  2 .


      Dans ce cas là le "bug" ne permet pas de trouver la clé mais de se logger sans avoir besoin de la clé initiale.


      Je trouve le passage que tu cites très très flou et des précisions sont bienvenues mais je ne mettrais pas ma main a coupé que ce bug ne permette pas de trouver la clé privé (à partir de la clé publique + de signatures faibles faites par la machine ayant le bug et permettant de remonter à la clé privé).

      Si quelqu'un peut m'éclairer ...
    • [^] # Re: Pas seulement les cles generees sur Debian

      Posté par . Évalué à  5 .

      C'est un "défaut" bien connu du DSA. Si on connaît la valeur du paramètre aléatoire utilisé pour une signature, on peut retrouver la clef secrète.

      Plus loin que ça, si pour deux signatures, les deux valeurs du paramètre aléatoire sont identiques, alors on peut retrouver la clef secrète.
  • # Wishlist

    Posté par . Évalué à  2 .

    Et là, je me dis que c'est dommage que le support d'opensc ne semble pas présent dans les paquets d'openssh de Debian... ça fait un moment que ça traîne dans la wishlist, avec patch disponible, du paquet ( http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=pkg&d(...) )...

    ... bon, le problème semble plutôt être que ça créerait trop de dépendances, et que ça pourrait gêner les petits systèmes... m'enfin, à la limite, ce serait bien d'avoir un autre .deb en plus, ie openssl-opensc...



    Mais a priori, les clés privées n'étant pas censées quitter un token pour êtres exposées au système, et le couple clés privée/publique y étant généré, le problème ne se poserait pas, en ce cas, pour openssh, qui est, pour ce qui me concerne, le plus pénible...

    ... enfin, si probablement : pour ce qui est de la clé chiffrant la communication, une fois la transaction établie : mais ça ne supposerait que d'attendre la mise à jour d'openssl, et pas de régénérer toutes ses clés.



    Voilà que la paranoia recommence à me démanger...Ce serait bien, quand même, une petite smartcard...
    • [^] # Re: Wishlist

      Posté par . Évalué à  3 .

      Euh, comme dit dans le commentaire plus haut, ca depend du protocole, les clés DSA ont toutes été compromises si elles ont été utilisées sur un client debian.
      • [^] # Re: Wishlist

        Posté par . Évalué à  2 .

        Certes, mais on dispose justement de plusieurs types de clés : personnellement, j'utilise essentiellement du RSA, qui ne semble pas avoir été gêné par ce problème, si j'en crois l'alerte sur la liste Debian, pour openssh...

        Je ne dis pas que c'eût été la solution à tout... je me demande juste si ça n'aurait pas limité la casse d'avoir la possibilité d'utiliser du token dans le cas d'openssh, avec de la RSA dedans... le token devrait s'occuper tout seul de générer les clés si on lui demande, et sans devoir demander à openssl de les générer, non ?

        Et, je peux me tromper, mais comme il ne semble pas que RSA ait besoin d'une valeur aléatoire via openssl pour athentifier/signer, le problème devrait se limiter à celui de la génération des clés, justement confiée au token, contrairement aux clés DSA dont la simple utilisation avec la version incriminée d'openssl suffit pour être dans la panade...



        Lorsqu'il m'est arrivé de faire du lego tortueux pour ne pas exposer mes clés SSH (en les mettant sur une clé USB dont je me sers vaguement comme d'un token du pauvre... avant tout pour que n'importe qui ne puisse pas avoir accès à des clés privées que je laisserais traîner dans mon /home, plus qu'autre chose), on m'a souvent suggéré d'utiliser un token (donc, pour des raisons différentes de celles qui me turlupinent dans ce bug)... mais ça a quand même l'air assez peu répandu et cher (d'autant que la plupart des offres que j'ai vues demandaient à commander des quantités conséquentes... orienté entreprise probablement)...

        D'ailleurs, quand j'ai demandé des précisions sur le sujet à ceux qui m'en parlaient : silence radio... je n'ai jamais trop vu de retours sur ce genre de choses ; j'ai beau être passionné par ce qu'on peut faire avec un réseau et les OS libres, je reste un profane autoditacte, non-professionnel, en la matière... je ne crache pas non plus sur des retours argumentés sur ces tokens : sont-ils vraiment si surfaits que ça, pour qu'ils aient l'air si peu répandus et que leur gestion soit si peu implémentée dans des choses comme openssh, notamment, pour la distro dont il est question dans ce journal (et que j'utilise au quotidien), par Debian ? Bref, pourquoi, monde cruel !?
      • [^] # Re: Wishlist

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

        Non, ce n'est pas exactement ce qui est dit. D'après le commentaire plus haut, ce qui est compromis dans le cas de DSA c'est les fichiers ou connections signés à l'aide de cette clef et un mauvais openssl, mais pas la clef en elle meme.
        • [^] # Re: Wishlist

          Posté par . Évalué à  2 .

          Non c'est la clé si tu regardes l'algo de signature, si la fonction de random est mauvaise on peut inverser facilement la fonction et avoir la clé privée.
      • [^] # Re: Wishlist

        Posté par . Évalué à  2 .

        Que veux dire exactement "utilisées sur un client debian", j'ai une clé ssh DSA que j'ai généré sur ma mandriva, mais j'utilise l'agent ssh avec transition de l'agent (ForwardAgent, je sais qu'en elle-même cette fonctionnalité peut poser problème si on n'a pas confiance au root de la machine distante). Dois-je générer une nouvelle clé?
  • # tests

    Posté par . Évalué à  2 .

    Ce que je trouve fou c'est que le bug est mis autant de temps à être découvert et qu'il n'y a pas de débat sur comment le bug aurait pu être éviter.

    On pourrait imaginer une suite de test qui testerait l'aléatoire des clefs, a la sorti du générateur aléatoire avoir un filtre/test de l'aléatoire (un peu comme ce que fait le démon de rng-tools pour les générateurs aléatoire hardware pas forcement géniaux).
    • [^] # Re: tests

      Posté par . Évalué à  3 .

      Ce que je trouve fou c'est que le bug est mis autant de temps à être découvert et qu'il n'y a pas de débat sur comment le bug aurait pu être éviter.

      Le débat viendra dans un second temps, je pense. L'urgence, c'est de communiquer pour éviter le pire.

      On pourrait imaginer une suite de test qui testerait l'aléatoire des clefs, a la sorti du générateur aléatoire avoir un filtre/test de l'aléatoire (un peu comme ce que fait le démon de rng-tools pour les générateurs aléatoire hardware pas forcement géniaux).

      C'est possible ça? Pourquoi le script perl fourni par debian pour vérifier les clés (dowkd.pl) ne l'utilise pas?
    • [^] # Re: tests

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

      On pourrait imaginer une suite de test qui testerait l'aléatoire des clefs

      C'est trop tard pour les clefs pas assez aleatoires, c'est deja fait. La prochaine fois ca sera un autre truc :)
  • # Ubuntu 8.04 : Attention

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

    - Si vous utilisez ubuntu 8.04 sur votre serveur
    - Que l'access ssh avec mot de passe est désactivé (Options PasswordAuthentication no et UsePAM no)

    Si vous faites un apt-dist-upgrade, vos clefs sont apparament désactivées, et vous ne pourez plus vous logger.

    Pas très intelligent comme mise à jour.
    • [^] # Re: Ubuntu 8.04 : Attention

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

      Pas très intelligent de mettre dans le serveur ssh un détecteur de clés pourries, pour désactiver les serveurs potentiellement compromis ? Ça pourra au contraire potentiellement sauver la vie de nombreux admins..
      • [^] # Re: Ubuntu 8.04 : Attention

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

        Disons alors qu'il eut été préférable de prévenir avant de désactiver les clefs.
        Si ssh est le seul access disponible à son serveur, ça veut dire retour d'urgence au datacenter.
        • [^] # Re: Ubuntu 8.04 : Attention

          Posté par . Évalué à  3 .

          ça veut dire retour d'urgence au datacenter

          Il risque d'y avoir des embouteillages, au datacenter :)
        • [^] # Re: Ubuntu 8.04 : Attention

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

          Si ssh est le seul access disponible à son serveur, ça veut dire retour d'urgence au datacenter.

          Euh... Perso j'ai un accès par la console de mon hébergeur, reboot sur noyau réseau avec accès aux disques, réparation du probleme par accès SSH du noyau réseau, reboot.
          C'est un peu "chaud" de n'avoir que SSH de ta machine, que le noyau de ta machine pour accéder à la machine... Il y a des warriors ici :)
          • [^] # Re: Ubuntu 8.04 : Attention

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

            Heureusement il y a kvm over IP...
          • [^] # Re: Ubuntu 8.04 : Attention

            Posté par . Évalué à  2 .

            Tout le monde n'a pas les moyens de se payer ce genre de service (la bande passante est déjà assez chère)
            • [^] # Re: Ubuntu 8.04 : Attention

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

              Tout le monde n'a pas les moyens de se payer ce genre de service (la bande passante est déjà assez chère)

              De quoi tu parles?
              D'avoir un noyau réseau de secours? C'est payant chez toi? Mais quitte ton hébergeur!
              Perso, j'ai 1 serveur chez Dedibox à 30€/mois et j'ai ce service, j'ai 1 serveur Kimsufi à 20€/mois aussi et j'ai ce service aussi (il me semble, pas testé encore par contre).

              Si tu n'as pas les moyens de mettre le prix d'un serveur dédié, ben tu n'as pas de problème SSH...

              Ou alors j'ai rien compris.
              • [^] # Re: Ubuntu 8.04 : Attention

                Posté par . Évalué à  2 .

                Non, je parle d'avoir une console directe sur le serveur, il faut avoir du matériel et une connection réseau en plus pour gérer ça.
                • [^] # Re: Ubuntu 8.04 : Attention

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

                  Il me semble que Dedibox tout autant qu'OVH ont cette fonctionnalité dans le cadre de toutes leurs offres.
                  • [^] # Re: Ubuntu 8.04 : Attention

                    Posté par . Évalué à  2 .

                    Je parle d'hébergement d'entreprise, où on loue un rack avec de la bande passante pour aller mettre nos propres serveurs. On aurait pu prendre des serveurs avec ce genre d'interface, mais c'est plus cher (PME inside) e tça demande deux fois plus d'IP par machine.
                    • [^] # Re: Ubuntu 8.04 : Attention

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

                      En même temps, si lors d'incidents tu dois te déplacer sur place pour avoir un accès physique rien que parce que tu as un ssh qui ne te permet plus de te connecter ou suite à un ifdown malencontreux ou reboot foiré, il faut ajouter dans les coûts :
                      - le déplacement sur place
                      - intervention sur site d'une personne
                      - l'indisponibilité (temps déplacement + intervention)
                      À la fin, ce n'est pas forcément des économies de bouts de chandelle qui valent le coup ni le coût :/
                      • [^] # Re: Ubuntu 8.04 : Attention

                        Posté par . Évalué à  2 .

                        Tout à fait d'accord avec toi.
                        Mais moi je suis développeur (et accessoirement administrateur de serveurs par la force des choses (PME bis)) et on ne me consulte pas pour les évaluations de budget (au-delà de simplement me demander combien de temps prendrait tel développement).
  • # Pour info

    Posté par . Évalué à  10 .

    Le(s) mainteneur(s) d'OpenSSL chez Debian demandent de l'aide constamment depuis fin 2005 (jusqu'à fin 2007 au moins).

    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=332498

    Ce n'est pas défendre les debian maintainers (si un peu quand même), étant moi même utilisateur de Debian à titre particulier et professionnel. Toutes les machines que j'utilise sont donc sous debian (excepté les quelques redhats (pour les certifs) et sun (raisons historiques) et un hpux (plus utilisé)).
    Donc je me trouve bien embêté pour les certificats que je génère en moyenne hebdomadairement pour le parc de machines et les utilisateurs dont j'ai la charge. À titre personnel, ouf, mes clés ssh et certificats sont suffisamment anciens.

    Maintenant on peut avoir deux attitudes :
    * Jeter le bébé avec l'eau du bain, adopter une attitude à la OpenBSD/De Raadt "tous des cons ils ne pensent pas comme nous".
    * Tenter de voir ce qui n'a pas fonctionné dans la chaîne et tenter de l'améliorer, histoire que ça n'arrive plus (le moins souvent possible).


    Cela fait un certain temps que je me suis fait la réflexion que le logiciel libre est une chaine dont les maillons les plus faibles sont :
    * La compétence des divers acteurs.
    * La confiance que l'on peut accorder à ces différents acteurs.

    Je comptais faire un journal là dessus pour partager cette réflexion avec des personnes qui pourront peut être m'apporter des éclairages nouveaux et d'autre points de vue sur ma façon de voir les choses. Je vais me contenter d'un post ici (à moins qu'on plébiscite ce post et que la foule en délire me demande genoux à terre d'en faire un journal, auquel cas, je serais magnanime et accèderai à un telle requête).

    Le mythe veut que le logiciel libre prévienne contre les codes malintentionnés (spywares ou pas). C'est certainement vrai pour les logiciels les plus populaires. Cependant, pour les logiciels plus confidentiels, trouvés sur une page obscure sur le net, je serais moins catégorique.
    Pour peu que le code soit assez conséquent, je doute que le mainteneur prenne le temps de lire tout le code avant de packager le soft.
    Et encore là on a un référent. Si le logiciel n'est pas packagé, il faut le compiler soi même. Autant je peut concevoir qu'une personne prenne le temps de relire ce qu'il package. Autant une personne quia un besoin (potentiellement urgent) va, selon moi, compiler le logiciel et l'utiliser le plus vite possible pour répondre à son besoin.

    Les limites d'un tel système sont que le logiciel doit être innovant/performant pour attirer des mainteneurs.
    Ou alors il faut qu'il package lui même son logiciel. Mais pour ça, il faut montrer patte blanche auprès de la distrib. Ce qui n'est pas facile, mais une proposition d'aide n'est jamais refusée, car, malheureusement, ce n'est pas du luxe.

    Donc les logiciels libres sont sûr si :
    * Le développeur est clean et compétant (ou que le mainteneur regarde ce que fait le développeur).
    * Le mainteneur est clean également.
    Et
    * Tous les miroirs proposant une iso de la distrib sont proposés par des personnes qui ne sont pas malintentionnées.
    * Tous ces miroirs sont sécure (et n'ont pas été rootés).

    Aussi quelque chose qui est amusant. De nombreux espaces de téléchargement proposent des logiciels, et, pour vérifier que l'archive a bien été téléchargée, un md5sum ou un sha1sum. Pourquoi pas. Parfois on trouve également une signature (un .asc en général), histoire d'être sûr de la provenance de l'archive. Mais bon si le miroir est corrompu tu as beau avoir 15 signatures, ça ne te dis pas que le source signé est bien celui que tu cherches. À moins de connaitre la personne qui développe le soft, d'être sûr que c'est toujours lui qui signe les releases et d'avoir sa clé dans ta chaine de confiance.


    Après cette (trop) longue disgression (toutes mes excuses, je n'ai pas réussi à condenser plus), revenons en à notre exemple Debian/OpenSSL.

    Dans ce cas, ce n'est pas la chaine de confiance qui a été brisée, mais la chaine de compétence. Il ne suffit de pas grande chose. Une personne dans une team (dev ou mainteneur) peut à elle seule compromettre un paquet. C'est peut être différent pour openssl qui est une pierre angulaire de la sécurité, mais dans les devs que j'ai suivit, officiellement, toutes les modifications étaient validés par au moins un autre membre de l'équipe (normalement deux).
    Or avec le temps et l'habitude, lorsque les patchs venaient d'une personne en particulier, qui est connue pour faire du code propre et bien maitriser son sujet, les codes étaient regardés de plus en plus vite, plus au niveau de l'indentation et des commentaires que l'algorithme autour du patch (comprendre le patch en profondeur et le code qui appelle la fonction modifiée et comment ça peut l'impacter). Or notre dev compétant s'est retrouvé limite sur une sous partie (infime) du projet qu'il maitrisait super bien (euphémisme). Ça a toujours passé jusqu'au jour où ça ne passait plus. Heureusement dans ce cas, pas trop de casse.

    Je déborde beaucoup bien sûr. C'était juste pour faire partager mes réflexions. Dans notre cas, il aurait simplement fallu une meilleure communication entre la team de dev et la team de mainteneurs.
    Peut être faut-il rapprocher un peu plus les team de mainteneurs des teams de devs . (ce qui semble-t-il a été tenté par les devs de debian, mais sur la mauvaise mailing list).

    Pour une erreur mise en lumière, combien passeront inaperçues ?
    • [^] # Re: Pour info

      Posté par . Évalué à  3 .

      Parfois on trouve également une signature (un .asc en général), histoire d'être sûr de la provenance de l'archive. Mais bon si le miroir est corrompu tu as beau avoir 15 signatures, ça ne te dis pas que le source signé est bien celui que tu cherches.

      Si je ne m'abuse, l'idée c'est que le .asc te sert à vérifier que le source a bien été signé par la clé privée du mainteneur, clé qui n'est pas disponible sur le site (manquerait plus qu'çà). Ou alors je nourris des illusions cruelles sur la nature des .asc, mais bon...
      • [^] # Re: Pour info

        Posté par . Évalué à  2 .

        Nous sommes d'accord. Mais ce n'était pas là mon propos.


        À moins de connaitre la personne qui développe le soft, d'être sûr que c'est toujours lui qui signe les releases et d'avoir sa clé dans ta chaine de confiance.

        Je n'ai jamais dit qu'il était facile de casser ou falsifier une signature. J'ai juste dit qu'il était facile de faire une signature différente.

        Prenons un exemple, ce sera plus clair.

        Si demain je me rends sur cairographics et je télécharge la dernière release de cairo. Je peux très bien patcher le code et signer mon nouveau paquet avec ma clé à moi. Ensuite si je mets ça à disposition sur un miroir (car c'était de ça qu'il s'agissait dans mon propos), alors qui pourra dire que le paquet n'est pas sûr ? Surtout que ma clé est dans un ring de confiance très important vu que j'ai rencontré plein de dev internationaux avec beaucoup de contacts.

        Alors ok, ce n'est pas suffisant car il suffit de savoir que Carl Worth est la personne qui signe les paquets sur cairographics. Mais combien de personnes le savent ? Carl Worth n'est pas si connu que ça. Et quand bien même beaucoup de monde le saurait, faut-il connaitre tous les développeurs susceptible de signer les paquets de tous les logiciels qu'on package ?

        Peut être, mais ça fait beaucoup de boulot.


        Pour le commentaire plus bas :
        C'est certain, le logiciel libre ne garantit pas une «chaîne» parfaite de production. Elle fournie juste AMHA une des meilleurs chaînes possible.
        Nous somme bien d'accord.
    • [^] # Re: Pour info

      Posté par . Évalué à  2 .

      Je ne reviens pas sur tout.

      > * Jeter le bébé avec l'eau du bain

      Non. Une connerie a été faite. Faut arrêter de chercher des excuses.
      Mais ça arrive ! C'est comme ça, ça arrive. Personne n'est à l'abris.
      • [^] # Re: Pour info

        Posté par . Évalué à  3 .

        Clair, c'est pas Red Hat qui en ferait une pareille.

        (désolé, c'est tout à fait infondé, mais c'était trop tentant)
        • [^] # Re: Pour info

          Posté par . Évalué à  1 .

          > Clair, c'est pas Red Hat qui en ferait une pareille.

          Si ils peuvent le faire.
          Mais j'ai la faiblesse de croire que c'est moins probable :-)
    • [^] # Le logiciel libre ne garantit pas une «chaîne» parfaite

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

      C'est certain, le logiciel libre ne garantit pas une «chaîne» parfaite de production. Elle fournie juste AMHA une des meilleurs chaînes possible.
  • # détails techniques et exploits

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

    http://it.slashdot.org/comments.pl?sid=551636&cid=233926(...)
    Donc apparemment ça viendrait du fait que le mainteneur qui voulait faire taire Valgrind a « corrigé anticipativement » un peu trop large. « Oh tiens, ça ressemble à la ligne qui génère un warning, on va la supprimer aussi. »

    Et pour les kiddies, il y a de quoi s'amuser par là (entre autres) : http://metasploit.com/users/hdm/tools/debian-openssl/

    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question. | Free Softwares Users Group Arlon, Belgique : http://fsugar.be/

    • [^] # Re: détails techniques et exploits

      Posté par . Évalué à  3 .

      Perso je trouves que c'est surtout un tres bon exemple du risque des forks et de la difficulte de maintenir un soft dont on ne comprend pas le code.

      Si ca se trouve le gars est un developpeur cale, mais quand tu ne maitrise pas le code sur lequel tu bosses(techno peu connue / complexe / grosse base de code...) t'as beau etre cale les catastrophes sont possibles et probables.
      • [^] # Re: détails techniques et exploits

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

        Heu non, faut pas exagerer, c'est pas par ce qu'il se trouve que ce bug a été introduit par un mainteneur de package qu'il faut en conclure des trucs sur le risque des forks. C'est une erreur, ca arrive, et ca aurait très bien pu arriver à un developpeur d'openssl aussi.

        Si on regarde les alertes de sécurité, 99% proviennent de bugs dans les logiciels upstream, c'est par par ce qu'il y a un problème une fois avec un patch ajouté par le mainteneur du package qu'il faut en conclure n'importe quoi.
      • [^] # Re: détails techniques et exploits

        Posté par . Évalué à  1 .

        enfin la même ceux qui maitrisait le code (les dvp d'openssl) on dis que pour eux c'était ok comme modif.
        Comme quoi ...
        Des fois , meme si tu es calé, tu connais le code, tu as las doc, des catastrophes sont possibles et probables.
        • [^] # Re: détails techniques et exploits

          Posté par . Évalué à  0 .

          > enfin la même ceux qui maitrisait le code (les dvp d'openssl) on dis que pour eux c'était ok comme modif.

          Arrêtes de répéter ça, ce n'est pas vrai.
          Et si c'est vrai, c'est uniquement pour une version de debug.
          Hors le mainteneur n'a pas fait sa bourde uniquement sur la version de debug.

          Enfin, si c'était pertinant à faire, l'upstream l'aurait fait.
          • [^] # Re: détails techniques et exploits

            Posté par . Évalué à  3 .

            Arrêtes de répéter ça, ce n'est pas vrai.
            Certainement plus que dire (répeter jusqu'a plus soif devrais je dire)
            "il savait absolument pas ce qu'il faisait", vu qu'il a pointé du doigt le problème d'entropie du code.

            Et si c'est vrai, c'est uniquement pour une version de debug.
            pas totalement vrai ce que tu dis, il acceptait pour le debugging AUSSI des applications contenants openssl.
            Regardons donc les liens que j'ai donné, on voit :
            Not much. If it helps with debugging, I'm in favor of removing them.
            > (However the last time I checked, valgrind reported thousands of bogus
            > error messages. Has that situation gotten better?)

            I recently compiled vanilla OpenSSL 0.9.8a with -DPURIFY=1 and on Debian
            GNU/Linux 'sid' with valgrind version 3.1.1 was able to debug some
            application using both TLS/SSL as S/MIME
            without any warning or error
            about the OpenSSL code. Without -DPURIFY you're indeed flooded with
            warnings.

            So yes I think not using the uninitialized memory (it's only a single
            line, the other occurrence is already commented out) helps valgrind.

            Oh tiens ca alors, ca parle pas que du debugage interne à openssl mais aussi de tous les autres codes qui utilisent openssl (et qui donc ne travaillent pas sur une version d'openssl de debug. Quand tu debug ton code, tu travaille pas sur une version de debug de libc6 , si ?)

            alors je suis d'accord que le dvp debian a fait des merdouilles, que les dev d'openssl ont pas forcément vu tous les problèmes, mais un moment faut arrêter de dire "Il sait absolument pas ce qu'il faisait", et "il a tout fait tout seul dans son coin".


            Enfin, si c'était pertinant à faire, l'upstream l'aurait fait.
            Pas forcément : il n'y a pas de bug a proprement parlé. La criticité de l'opération est très faible. Donc on voit passer sa sur la mailing list, on se dis "a pas con", et finalement on oublie de reporter ça. Comme ça ne corrige pas de bugs à proprement parler, on oublie relativement facilement, et on se précipite pas pour pousser tout upstream.

            La ou les dvp de debian ont merdé, c'est lors du push des patchs vers l'upstream, et ca je suis bien d'accord.
            • [^] # Re: détails techniques et exploits

              Posté par . Évalué à  1 .

              > "il savait absolument pas ce qu'il faisait"

              QU'IL NE LE FASSE PAS !

              > il acceptait pour le debugging AUSSI des applications contenants openssl.

              Il a dit "I'm in favor of removing them". Il n'a pas dit "OK, ça roule ma poule".

              Il y a un autre développeur OpenSSL qui répond :
              On May 1, 2006 03:14 pm, Kurt Roeckx wrote:
              > The code in question that has the problem are the following 2
              > pieces of code in crypto/rand/md_rand.c:
              >
              > 247:
              > MD_Update(&m,buf,j);
              >
              > 467:
              > #ifndef PURIFY
              > MD_Update(&m,buf,j); /* purify complains */
              > #endif

              There's your first clue, build with -DPURIFY :-)

              Cheers,
              Geoff


              Mais le "247: MD_Update(&m,buf,j);" est devenu "/* MD_Update(&m,buf,j); */" sans que le développeur OpenSSL le savent.

              Regarde la version 199 :
              http://svn.debian.org/wsvn/pkg-openssl/openssl/trunk/crypto/(...)
              C'est :
              /*
              * Don't add uninitialised data.
              MD_Update(&m,buf,j); MD_Update(&m,buf,j);
              */

              Ceci n'a jamais été validé. Et c'est ça qui pose problème.

              > I recently compiled vanilla OpenSSL 0.9.8a with -DPURIFY=1 and on Debian
              > etc

              Il n'est pas développeur OpenSSL.


              Le mainteneur Debian a fait une connerie. Je ne demande pas une "lapidation". Mais il a fait une connerie et ça peut arriver à toi ou à moi.
              Il faut reconnaitre qu'il a fait une connerie. Je ne demande pas qu'il arrête d'être mainteneur !
              Si tu ne reconnais pas qu'il y a connerie, tu ne remets pas en cause. Si tu reconnais qu'il y a une connerie, ben tu ne mets pas en place une solution. Par exemple il ne faut plus toucher au "noyau" OpenSSL sans que le patch soit approuvé en upstream (donc il doit être upstream). Etc.

              Quand MS fait une connerie, on ne lui cherche pas d'excuses bidons. MS a fait une connerie, point barre. (Ici il faut évidemment distinguer "connerie" de manoeuvre volontairement mal intentionnée).


              Parce qu'en gros tu nous dis "tout va bien, tout c'est passé normalement, et ça va recommencer car il n'y a pas de raison qu'on revoir notre façon de faire".
              C'est inacceptable.
              • [^] # Re: détails techniques et exploits

                Posté par . Évalué à  1 .

                > "il savait absolument pas ce qu'il faisait"

                QU'IL NE LE FASSE PAS !


                euh .. tu sais voir l'ironie ?
                Visiblement pas.

                bon pour le reste tu es de mauvaise foi
                (- prendre la toute premiere réponse , ou c'est meme marqué "first clue" , et dire "tu vois que c'est que pour le debug", sans prendre en compte les reste du messages
                - dire "les dvp d'openssl savait pas ce qu'il fasait alors qu'il avait expliqué , ...
                - ne pas savoir lire (inverser celui qui dis "pour moi pas de blem" et celui qui dis "j'ai fait des test")

                et je ne perdrais pas plus de temps sur ce sujet avec toi.

                Parce qu'en gros tu nous dis "tout va bien, tout c'est passé normalement, et ça va recommencer car il n'y a pas de raison qu'on revoir notre façon de faire".
                Arrête de fumer pépé, et apprend à lire.
                Ce que je dis c'est que le problème est partagé, et pas seulement celui du "bouh méchant dvp debian qui sait pas faire son boulot".

                C'est inacceptable.
                Et tu vas faire quoi ? Prendre la tapette a mouche et taper sur les méchants dvp de debian que tu aime pas , parce qu'ils sont pas de fedora ?
                Taper sur les gens dont tu arrive pas à comprendre les commentaires ?
                • [^] # Re: détails techniques et exploits

                  Posté par . Évalué à  2 .

                  > euh .. tu sais voir l'ironie ?

                  Désolé :-)
                  J'avais vu que j'avais écrit une connerie, mais j'ai oublié de corriger.

                  > bon pour le reste tu es de mauvaise foi

                  Non.

                  > Et tu vas faire quoi ? Prendre la tapette a mouche et taper sur les méchants dvp de debian

                  L'erreur de Debian n'est pas innaccèptable. Ne pas la reconnaitre l'est.
          • [^] # Re: détails techniques et exploits

            Posté par . Évalué à  4 .

            Et si c'est vrai, c'est uniquement pour une version de debug.

            Ce n'est pas ce que signifie "If it helps with debugging, I'm in favor of removing them. " que je traduit par "si ça aide au débuggage, je suis d'accord pour les supprimer". Et non pas "je suis d'accord pour les supprimer en version debug".
            • [^] # Re: détails techniques et exploits

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

              Sauf que dans son message :
              - il parle de retirer des erreurs valgrind pour aider à debugger
              - il ne precise pas qu'il est mainteneur debian, ou que ces modifications sont destinées à etre redistribuées à beaucoup de monde
              - il ne montre pas un vrai patch, il cite juste 2 lignes identiques avec numeros de lignes, en précisant que ces lignes posent probleme avec valgrind, ce qui est faux, seule une des 2 lignes pose probleme (celle qui peut etre retirée sans problème, l'autre non)

              Compte tenu de tout ca :
              - il est facile de croire que la personne souhaite simplement se recompiler un openssl pour debugger quelquechose
              - il est facile de croire qu'il parlait uniquement de la ligne utilisant de la memoire non initialisée (la réponse est parfaitement correcte dans ce cas la)
              - n'ayant pas précisé que cette modification était critique (déstinée à etre redistribuée à beaucoup de monde), la personne qui répond ne prend pas forcement le temps de verifier que toutes les affirmations sont exactes
              • [^] # Re: détails techniques et exploits

                Posté par . Évalué à  2 .

                C'est tout à fait exact et je ne prétends pas dire qu'il n'y a pas eu d'erreur, néanmoins, je pense que le mainteneur Debian n'est pas le seul en cause, sans doute que le code n'était pas aussi clair qu'il aurait dû l'être pour cette partie sensible (voir à ce propos cette réaction : http://www.aigarius.com/blog/2008/05/14/too-similar-to-be-di(...) ).
                Comme dans tous les problème de sécurité, c'est une ensemble de déficiences qui sont à la source du problème :
                - Au départ, le code n'est pas suffisamment explicite et utilise entre autre une variable non initialisée comme source d'aléa
                - Le mainteneur veut supprimer les erreurs remontées
                - Il demande conseil sans expliquer suffisamment ce qu'il veut faire
                - Sur la mailing-list openssl-dev on ne lui explique pas suffisamment le fonctionnement
                - Il corrige et supprime un peu trop de code (le mieux est l'ennemi du bien)
                - Il est tout seul comme mainteneur d'openssl (en fait ils sont 2 mais il semble que le deuxième soit trop occupé) alors que ça fait 2 ans qu'il demande de l'aide ( http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=332498 )
                - Il n'y a pas de revue de la security team pour les packages sensible (manque de moyens et de bonnes volontés sans doute).


                C'est clair qu'il a fait une grosse boulette, mais le processus a certainement manqué de quelques fusibles.

                PS: la liste des erreurs n'est pas exhaustive, on pourrait noter un manque de remontée upstream comme il a déjà été dit
    • [^] # Re: détails techniques et exploits

      Posté par . Évalué à  1 .

      a « corrigé anticipativement » un peu trop large. « Oh tiens, ça ressemble à la ligne qui génère un warning, on va la supprimer aussi. »
      C'est pas comme si a pas demandé d'avis aux dvp openssl, et c'est pas comme si ils ont pas dis "si ca peut faciliter le debug, pour nous c'est OK".

      De plus j'ai quand même du mal à ce qu'on considère la mémoire non initialisé comme du "bon" aléas. Que ca rajoute un peu d'aléas je peux comprendre(et encore, suffit de mettre toute la mémoire dispo a zero (programme utilisateur) avant de lancer openssl!, et hop on a une jolie faille.
      ex : je sais que le serveur X génère des clés le soir à 22h. J'ai un compte utilisateur sur ce serveur.
      juste avant 22h, je lance un programme qui va écrire des zéro sur toute la mémoire qu'il peut initialiser, puis ensuite la rend.
      La probabilité qu'openssl va demander de la mémoire que j'ai initialiser peut etre assez grande (suivant la mémoire dispo, ce qui tourne, ...))
      , mais que tout l'aléa dépende de ça, j'avoue que j'ai plus de mal. C'est pas comme si il y avait /dev/random si on veut de l'aléa un peu plus correct ...
      Enfin je suis pas un expert, loin de la, et j'ai pas regardé ce que fait openssl mais ca m'a fait tiquer quand meme.
  • # Debian est coupable mais pas responsable !

    Posté par . Évalué à  -6 .

    Les mécanismes de contrôle de Debian ont failli. C'est un fait. Un Mainteneur modifie un paquet essentiel pour la sécurité du système et visiblement personne ne contrôle son travail.

    Franchement cela n'est pas très pro mais excusable après tout Debian est une distribution gérée par des bénévoles donc dans un certain sens amateurs.

    Ce qui est beaucoup plus gênant c'est le manque évident de contrôle des distributions commerciales dérivée de Debian. Elles cherchent à s'adresser aux professionnels mais visiblement ne contrôlent pas la qualité des composants essentiels pour la sécurité….
    • [^] # Re: Debian est coupable mais pas responsable !

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

      Il n'y a rien d'excusable.
      Un packageur décide de modifier un paquet de la plus haute importance sans comprendre ce qu'il fait ne mérite plus de maintenir de paquets. Dans le cas présent l'erreur a des répercussions inadmissibles.


      Maintenant les debian user se cherche des excuses et au lieu d'assumer vont chercher les responsabilités ailleurs ou jetent des écrans de fumée et le discrédit sur les autres distribs. C'est inadmissible !

      En vrac.
      * C'est pas nous, c'est la faute aux dev upstream... sauf que les devs upstream n'ont jamais intégré ce patch !!
      * Debian, on est les meilleurs, dés qu'on a vu le bug on a fait un paquet corrigé. Réussir a dire ça sans mourrir de honte, faut franchement n'avoir aucune fierté :(
      * Debian est plus secure que les autres distribs car on a une blacklist des clés pourraves. Là encore oser pourrir nommément les autres distribs à cause de sa propre incurie, faut oser.


      Ce genre de bug serait arrivé chez Microsoft, je raconte pas comment il se fairait incendier à raison. c'est arrivé à Debian et ses dérivés, il faut que les devs debian assument.
      • [^] # Re: Debian est coupable mais pas responsable !

        Posté par . Évalué à  -5 .

        La réactions des Debian's boys est effectivement toujours la même et essentiellemnt du à la structure communautaire et bénévole de Debian. Personne n'est responsable.

        Il ne faut pas oublier que l'on utilise Debian à ses risques et périls. Personne ne garantit quoique ce soit .....

        Il est certain que certaines distributions commerciales dévivées voulant se lancer dans le marché professionnel sont touchées. Mais c'est en parti de leur faute. Le temps ou Debian était une référence en terme de sécurité appartient au lointain passé. Reprendre le code sans le vérifier est autrement coupable.....

Suivre le flux des commentaires

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