Journal Backdoor dans OpenBSD ?

Posté par  .
Étiquettes :
38
15
déc.
2010
Une bombe est sortie ce 14 Décembre : un développeur de la couche IPsec d'OpenBSD indique que le FBI a payé des développeurs libres pour mettre des backdoor qui permettent de regarder ce qui passe dans les échanges par VPN.

Les faits remonteraient à 2000/2001, et la couche IPsec a depuis été reprise dans d'autres systèmes d'exploitation...

Ceci vient d'être divulgué par Theo de Raadt qui a reçu un courriel d'un de ces développeurs, qui avait signé un NDA de 10 ans avec le FBI. Il n'a pas du tout vérifié la véracité de ce message, mais invite les développeurs à jeter un œil neuf à leur code pour s'en assurer.

Le site où j'ai pêché l'information :
http://www.phoronix.com/scan.php?page=news_item&px=ODkxM(...)

Le courriel publié par Theo :
http://permalink.gmane.org/gmane.os.openbsd.tech/22557
  • # Show us the code ?

    Posté par  . Évalué à 5.

    Ça serait bien d'avoir un lien vers une révision des dépôts montrant une telle vulnérabilité. Quel désaveu pour OpenBSD !

    Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.

    • [^] # Re: Show us the code ?

      Posté par  . Évalué à 10.

      Pourquoi est-ce un désaveu ? il ne sont pas responsables de cette affaire, c'est clairement un complot perpétré par les services de l'État américain. De plus j'imagine que notre pingouin favori pourrait avoir subit le même sort, d'autant plus que SELinux est l'oeuvre ... de la NSA.
      • [^] # Re: Show us the code ?

        Posté par  . Évalué à 10.

        Depuis le temps que j'y pense. Mais clairement, openBSD est un système conçu pour être le parangon de la sécurité. Si une backdoor a pu y être volontairement introduite, et propagée au cours des révisions et versions, c'est clairement un désaveu vis à vis de l'objectif initial de ce système d'exploitation.

        Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.

        • [^] # Re: Show us the code ?

          Posté par  . Évalué à 6.

          et propagée au cours des révisions et versions

          Et même propagée dans d'autres systèmes, sûrement très nombreux vu le code en BSD.

          DLFP >> PCInpact > Numerama >> LinuxFr.org

          • [^] # Re: Show us the code ?

            Posté par  . Évalué à 0.

            Oui mais pour eux, ce n'est pas un désaveu voyons. Surtout si c'est un linux. On n'est pas vraiment sur un site fait pour être objectif, vois tu.

            Quel désaveu !!!
        • [^] # Re: Show us the code ?

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

          Pas une seule backdoor, mais plusieurs, à priori. Reste à confirmer.

          Et vu le nombres de boites fourguant des applicances sous (ou dérivé de OpenBSD), sans même que les clients ne soient au courant, je connais quelques ingénieurs réseaux qui doivent chier dans leur froc actuellement.

          Mais perso je ne le prends pas pour un désaveu à l'égard d'OpenBSD, plutot une publicité formidable pour le FBI. Car arriver à coller des bouts de code qui ont l'air de rien lors des relectures, qui ne sont pas obfusqués, mais qui supportent donc un certain type "d'appel" permettant de mettre en route des fonctionnalités cachées, ce n'est plus que du code, c'est du grand art.
          • [^] # Re: Show us the code ?

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

            > arriver à coller des bouts de code qui ont l'air de rien lors des relectures,
            > qui ne sont pas obfusqués, mais qui supportent donc un certain type
            > "d'appel" permettant de mettre en route des fonctionnalités cachées,
            > ce n'est plus que du code, c'est du grand art.

            C'est effectivement très joli à voir : http://underhanded.xcott.com/

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

          • [^] # Re: Show us the code ?

            Posté par  . Évalué à 4.

            >> Car arriver à coller des bouts de code qui ont l'air de rien lors des relectures, qui ne sont pas obfusqués, mais qui supportent donc un certain type "d'appel" permettant de mettre en route des fonctionnalités cachées, ce n'est plus que du code, c'est du grand art. <<

            Du grand art, oui, mais ce n'est pas impossible: il y a même un concour basé sur ce sujet: codé en C quelque-chose qui semble correct mais ne l'est pas.
            La sémantique du C étant assez pourrie (variables non-itialisées par défaut, non-détection des débordements entier, des débordements de tableaux), les meilleures entrées dans le concours sont excellentes!

            En Ada, ce serait déjà plus difficile..
  • # Les chinois du FBI...

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

    Et dire qu'on est pas encore vendredi ;-)
    Bon pour l'instant c'est juste des mails donc il faut bien se garder de conclure quoi que ce soit. Je me doute que les devs OpenBSd vont soigneusement regarder leur code pour tout passer au peigne fin.
    Si il s'avère qu'il y a bien une ou des backdoors ("a number of backdoors and side channel key leaking mechanisms") il faudra s'interroger sur le fait que ce soit resté présent dans le code depuis l'an 2000 sans que personne ne remarque quoi que ce soit.

    Affaire potentiellement passionnante et trollifère !
    • [^] # Re: Les chinois du FBI...

      Posté par  . Évalué à 10.

      Ca peut aussi remettre pas mal en cause la confiance que l'on peut donner à un audit. Si les dev "OpenBSD regarde soigneusement leur code" mais qu'ils sont aussi soumis à un NDA pas encore expiré, ils peuvent simplement dire "le code est clean" alors que ce n'est pas le cas.
      • [^] # Re: Les chinois du FBI...

        Posté par  . Évalué à -10.

        Si ca se confirme, ca va surtout remettre enormement en cause ce gros mythe pourri disant qu'avoir le code ouvert donne un code plus sur...

        Mais bon, il faut encore attendre confirmation, pour l'instant ce n'est qu'un e-mail.
        • [^] # Re: Les chinois du FBI...

          Posté par  . Évalué à 10.

          Tant il est vrai que si le FBI avait réussi à insérer une backdoor dans Windows, elle aurait été détectée instantanément et immédiatement corrigée... ou alors elle y est encore et aucune fin de NDA n'y changera quoi que ce soit?
          (et oui, le FUD, ça peut se faire dans tous les sens...)

          Ici, il y a au moins une bonne chose à retenir: Theo de Raadt, malgré tout ce qu'on peut dire sur son caractère, continue à jouer la carte de l'ouverture et informe publiquement qu'il y a un souci potentiel.
          C'est très respectable.

          Microsoft en aurait-il fait autant ou aurait-on vu passer un patch corrigeant plusieurs vulnérabilités dont certaines non mentionnées?

          Bref, le "mythe", comme tu dis, ce n'est pas que le code est sûr parce qu'il est ouvert, c'est il est plus sûr parce qu'il est ouvert. Un petit mot qui change tout!
          • [^] # Re: Les chinois du FBI...

            Posté par  . Évalué à -8.

            Tant il est vrai que si le FBI avait réussi à insérer une backdoor dans Windows, elle aurait été détectée instantanément et immédiatement corrigée... ou alors elle y est encore et aucune fin de NDA n'y changera quoi que ce soit?
            (et oui, le FUD, ça peut se faire dans tous les sens...)


            Ben ca aurait ete la meme chose, au final ici cela n'a ete decouvert que parce qu'une des personnes ayant participe a decide de parler.

            Ici, il y a au moins une bonne chose à retenir: Theo de Raadt, malgré tout ce qu'on peut dire sur son caractère, continue à jouer la carte de l'ouverture et informe publiquement qu'il y a un souci potentiel.
            C'est très respectable.


            Tout a fait

            Microsoft en aurait-il fait autant ou aurait-on vu passer un patch corrigeant plusieurs vulnérabilités dont certaines non mentionnées?

            Ben c'est simple tu sais, quand on sort un patch, dans les 48h des centaines de gens l'ont desassemble et ont compris chaque ligne du code qui a change (c'est la raison pour laquelle on essaie de trouver les variantes de la faille originelle avant de sortir le patch, sinon les gens voient ce qui s'est passe, et vont a la peche dans la zone alentour), bref, cacher un changement dans un patch est chose impossible.

            Bref, le "mythe", comme tu dis, ce n'est pas que le code est sûr parce qu'il est ouvert, c'est il est plus sûr parce qu'il est ouvert. Un petit mot qui change tout!

            Tout a fait, mais ca reste un mythe.
            • [^] # Re: Les chinois du FBI...

              Posté par  . Évalué à 10.

              >> ce n'est pas que le code est sûr parce qu'il est ouvert, c'est il
              >> est plus sûr parce qu'il est ouvert.
              > Tout a fait, mais ca reste un mythe.

              Bof. Comme tu as constaté dans cette affaire, quand l'informateur envoie un mail à un chef de projet qui se trouve être une figure du libre, il se produit le suivant : « full-disclosure – we believe in it » ; ça fait partie du mode de pensée de ces gens.

              Par comparaison, si l'informateur envoyait le mail à un chef de projet qui est un employé d'une boite proprio, cette personne a le choix d'ignorer le problème, ou de mentir à son informateur en disant qu'ils regardent attentivement, puis d'étouffer l'affaire. En admettant que l'information passe au manager, l'information étant « un type nous a dit qu'il y a 10 ans il a existé une vulnérabilité dans notre stack de sécurité IP, mais on ne sait pas ce que sait », il y a des chances pour que le manager dise d'oublier, ça a dû être découvert entre-temps, personne ne s'est plaint, personne d'autre n'est au courant, on ne veut pas donner mauvaise image du service ou autre raison du genre.

              Je ne dis pas que tous les employés des boites proprio réagiraient comme ça, mais c'est une possibilité que je crois nettement moins probable chez les gens qui sont devenus leader de projets connus du libre. En conséquence de cette observation, le mode de développement ouvert ne peut conduire qu'à une meilleure prise en compte des failles.
              • [^] # Re: Les chinois du FBI...

                Posté par  . Évalué à 1.

                Bof. Comme tu as constaté dans cette affaire, quand l'informateur envoie un mail à un chef de projet qui se trouve être une figure du libre, il se produit le suivant : « full-disclosure – we believe in it » ; ça fait partie du mode de pensée de ces gens.

                Par comparaison, si l'informateur envoyait le mail à un chef de projet qui est un employé d'une boite proprio, cette personne a le choix d'ignorer le problème, ou de mentir à son informateur en disant qu'ils regardent attentivement, puis d'étouffer l'affaire


                Ha, dans les 2 cas la personne qui est alertee a le choix d'etouffer ou pas la chose. Dans les 2 cas la personne qui alerte a le choix d'alerter d'autres personnes parties au projet ou pas.

                Il n'y a aucune difference la dessus
                • [^] # Re: Les chinois du FBI...

                  Posté par  . Évalué à 5.

                  > Ha, dans les 2 cas la personne qui est alertee a le choix d'etouffer
                  > ou pas la chose. Dans les 2 cas la personne qui alerte a le choix
                  > d'alerter d'autres personnes parties au projet ou pas.
                  > Il n'y a aucune difference la dessus

                  Tu as raison, mais les personnes qui travaillent un bon moment dans le libre, en particulier les leaders connus, sont sélectionnés pour penser que la publication est une bonne chose. Je ne pense pas avoir besoin de te pointer les pages utiles chez OpenBSD ou Debian. La philosophie généralement partagée, c'est qu'il faut communiquer les problèmes, au moins dans un premier temps sur une mailing-list interne. C'est une obligation éthique retenue sur plusieurs projets. Or les gens qui contribuent sur de longues périodes à de tels projets, voire les créent ou en gravissent les échelons, s'engagent de la sorte parce qu'ils sont plus ou moins en accord avec a philosophie du projet. Quand ils ne sont pas en accord avec la philosophie du libre ou les règles du projet, ils vont ailleurs ou se font éjecter.

                  Au contraire, les gens qui posent candidature chez Microsoft ne sont pas sélectionnés sur le critère de compatibilité avec l'état d'esprit de vouloir communiquer le plus possible et publier ouvertement le plus possible. Or si les gens ne sont pas sélectionnés sur ce critère, il est probable qu'un nombre non négligeable aura d'autres priorité.
                  • [^] # Re: Les chinois du FBI...

                    Posté par  . Évalué à 2.

                    Il faut voir la chose dans sa globalite hein, le libre cela ne s'arrete pas a OpenBSD, Debian et Redhat.

                    Il y a des dizaines de milliers de projets libre, c'est cet ensemble qu'il faut voir

                    Au contraire, les gens qui posent candidature chez Microsoft ne sont pas sélectionnés sur le critère de compatibilité avec l'état d'esprit de vouloir communiquer le plus possible et publier ouvertement le plus possible. Or si les gens ne sont pas sélectionnés sur ce critère, il est probable qu'un nombre non négligeable aura d'autres priorité.

                    Publier ouvertement non, etre honnete et strict au niveau de l'ingeniere par contre certainement, sans oublier qu'au final on a tous notre fierte en tant qu'ingenieurs, de la meme maniere que les devs qui font du libre.
                    Croire que juste parce que tu fais du proprio alors tu passes tous les trucs sous le tapis est completement faux et legerement insultant hein...
                    • [^] # Re: Les chinois du FBI...

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

                      Croire que juste parce que tu fais du proprio alors tu passes tous les trucs sous le tapis est completement faux

                      Dans le monde de l'informatique "marchande", tu as trop souvent un directeur marketing (qui a promis le machin au client) qui commande un directeur technique (qui voudrait bien faire de la technique propre) qui commande un chef de projet (qui veut garder sa place, parce qu'il fait chaud au bureau) qui impose au c0d4z de ne pas se focaliser sur les tests unitaires parce que "ça prend du temps, et faut livrer, là, de suite, laisse tomber !".

                      C'est la vraie vie des PME, ça.
            • [^] # Re: Les chinois du FBI...

              Posté par  . Évalué à 8.


              Ben c'est simple tu sais, quand on sort un patch, dans les 48h des centaines de gens l'ont desassemble et ont compris chaque ligne du code qui a change (c'est la raison pour laquelle on essaie de trouver les variantes de la faille originelle avant de sortir le patch, sinon les gens voient ce qui s'est passe, et vont a la peche dans la zone alentour), bref, cacher un changement dans un patch est chose impossible.

              Mais pourquoi cacher le code alors ?
              Des bonnes volontés vous aident et vous faites tout pour leur mettre des bâtons dans les roues.

              Quel hypocrisie !
              Justifier la sécurité par la revue de code d'autrui et dans le même temps en faire des délinquants.
              • [^] # Re: Les chinois du FBI...

                Posté par  . Évalué à 1.

                Le cacher ? Il est ouvert a plein de gens le code, si t'as 1500 licences tu peux le voir.

                Justifier la sécurité par la revue de code d'autrui et dans le même temps en faire des délinquants.

                J'ai justifie ca par la revue de code d'autrui par desassemblage ? Non j'ai dit que cela arrive.

                On a des milliers et des milliers de gens dans et hors de MS qui ont permission de lire le code qui le lisent aussi, notamment une grande partie des gouvernements de cette planete.
                • [^] # Re: Les chinois du FBI...

                  Posté par  . Évalué à 2.


                  J'ai justifie ca par la revue de code d'autrui par desassemblage ? Non j'ai dit que cela arrive.


                  1 commentaire plus haut:

                  Ben c'est simple tu sais, quand on sort un patch, dans les 48h des centaines de gens l'ont desassemble et ont compris chaque ligne du code qui a change

                  Laisse tomber, tu t'es foiré sur ce coup là !
        • [^] # Re: Les chinois du FBI...

          Posté par  . Évalué à 8.

          Au moins n'importe qui peut regarder et vérifier le code s'il a un doute, c'est clairement pas le cas pour des OS dont le code est fermé (on ne citera personne hein).
          • [^] # Re: Les chinois du FBI...

            Posté par  . Évalué à -3.

            Tout a fait, et force est de constater qu'en 10 ans (si c'est avere) personne n'a rien vu, ou personne n'a regarde.

            Quand a une histoire de doute, c'est pas tres important au final que le code soit ouvert ou pas, quand t'as des jouets genre IDA Pro, le code binaire desassemble devient incroyablement facile a lire.
            • [^] # Re: Les chinois du FBI...

              Posté par  . Évalué à 8.

              Comme tu dis, si c'est avéré ... L'histoire date de 2000-2001, le code a certainement évolué depuis et en cherchant à améliorer le code, c'est possible aussi que ces backdoors aient été supprimées par effet de bord, voir par exemple http://marc.info/?l=openbsd-tech&m=129237675106730&w(...)

              Pour le désassemblage, j'utiliserais pas le terme "incroyablement facile" (surtout si tu n'as pas de table de symboles). Avoir le code source facilite quand même largement le travail d'audit.
              En tout cas, je souligne aussi l'attitude de Theo de Raadt, qui si il est parfois un peu brut de décoffrage, a joué la transparence totale.
            • [^] # Re: Les chinois du FBI...

              Posté par  . Évalué à 2.

              Même si ton truc de désassemblage est une merveille, il ne découvrira pas les commentaires et les noms des variables. C'est une autre paire de manches de rentrer dans ce code, en plus il faut être motivé pour auditer auquel tu ne peux pas faire grand-chose contrairement au libre (et par exemple j'ai déjà trouvé des bugs en lisant le code alors que c'était pas mon objectif).

              DLFP >> PCInpact > Numerama >> LinuxFr.org

              • [^] # Re: Les chinois du FBI...

                Posté par  . Évalué à -1.

                Oh ne t'inquietes pas, il y a plein de gens qui auditent la sortie desassemblee de notre code, ils le font pour plusieurs raisons :

                a) Se faire de l'argent avec des societes genre TippingPoint
                b) Se faire de la pub car ils sont consultants securite
                c) Ils bossent au KGB/NSA/Chinois/... et ont un boss qui veut savoir ce que Mme Clinton a fait au lit avec Bill (c'est a dire rien)
                d) Ils bossent pour la mafia ou autres criminels
                e) Rarement, ils font ca pour se marrer
                • [^] # Re: Les chinois du FBI...

                  Posté par  . Évalué à 5.

                  Je ne m' «inquiète » pas vu que je ne fais évidemment pas confiance à du code fermé pour quoi que ce soit d'important.

                  Ta diversion est gentille, ça ne change pas le fait que c'est dix fois plus dur.

                  DLFP >> PCInpact > Numerama >> LinuxFr.org

                  • [^] # Re: Les chinois du FBI...

                    Posté par  . Évalué à -1.

                    Oh c'est plus dur oui, mais dans notre cas c'est fortement compense par le fait qu'on est ultra-majoritaire, l'attrait est enorme vu notres presence partout.
                    • [^] # Re: Les chinois du FBI...

                      Posté par  . Évalué à 7.

                      Vous êtes tellement majoritaires qu'apparemment, c'est pas chez vous que le FBI place des backdoors.

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

                    • [^] # Re: Les chinois du FBI...

                      Posté par  . Évalué à 10.

                      Ce qui est amusant c'est que souvent ton argument c'est pas « on est
                      majoritaires parce qu'on est mieux » mais « on est mieux parce qu'on est
                      majoritaires ».
                      • [^] # Re: Les chinois du FBI...

                        Posté par  . Évalué à 1.

                        Tu as vu ou "on ext mieux parce qu'on est majoritaire" ? Ici je dis qu'on est plus ausculte parce qu'on est majoritaire, je vois pas en quoi c'est "mieux"
                  • [^] # Re: Les chinois du FBI...

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

                    > je ne fais évidemment pas confiance à du code fermé pour quoi que ce soit d'important

                    Tu utilises quoi comme BIOS libre ?

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

                    • [^] # Re: Les chinois du FBI...

                      Posté par  . Évalué à 9.

                      Oui, je sais, on peut mettre des backdoor partout, dans le compilateur, dans le matériel même.

                      Ce n'est pas parce que ton système n'est pas assurément 100% sécurisé qu'il ne faut pas essayer. Sinon autant laisser la porte de mon appartement grande ouverte parce que de toute façon des gens savent crocheter la serrure.

                      DLFP >> PCInpact > Numerama >> LinuxFr.org

                • [^] # Re: Les chinois du FBI...

                  Posté par  . Évalué à 8.

                  savoir ce que Mme Clinton a fait au lit avec Bill

                  Mme Clinton coucherait avec Bill Gates? Ça c'est de l'info de première importance! Même wikileaks n'a pas fait mieux.
                • [^] # Re: Les chinois du FBI...

                  Posté par  . Évalué à 2.

                  Apparemment il y a une backdoor dans windows connue de MS. Même qu'ils s'en servent pour regarder la webcam de Bill et Hillary.

                  Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

            • [^] # Re: Les chinois du FBI...

              Posté par  . Évalué à 0.

              force est de constater qu'en 10 ans (si c'est avere) personne n'a rien vu, ou personne n'a regarde.

              Tu ce que tu peux en déduire c'est qu'aucune personne qui l'aurait publié n'a rien vu. Il est tout à fait possible des des organisations/gouvernement s'en soient rendu compte et qu'ils utilisent en interne une version corrigée et n'aient rien annoncé pour pouvoir se servir eux aussi de la faille.

              PS: t'es fâché avec les accent? ou t'as un problème de configuration de clavier qui crée des caractères illisible à la place des accents?
            • [^] # Re: Les chinois du FBI...

              Posté par  . Évalué à 6.

              >le code binaire desassemble devient incroyablement facile a lire.

              Mais c'est illégale ... Alors comment faire pour ne pas se retrouver complètement en dehors de la loi ?

              J'imagine le tableau :
              - y a un problème dans votre code : y un une faille
              - super merci ... mais comment vous le savez ?
              - Bein j'ai desassemblé.
              - Mais c'est illégale ! On vous envoie la police et on va vous demander des sous pour violation de licence. Mais merci pour votre contribution.

              :D
              • [^] # Re: Les chinois du FBI...

                Posté par  . Évalué à -1.

                C'est illegal selon ce que tu veux faire avec et ou tu vis hein...

                Quand a ton scenario, ca fait plus de dix ans qu'on nous rapporte de temps en temps des failles comme ca, j'ai encore vu personne aller en prison pour ca, au contraire ils finissent tous avec un acknowledgement dans le bulletin ce qui aide leur carriere.
                • [^] # Re: Les chinois du FBI...

                  Posté par  . Évalué à 5.

                  Elles sont à quel paragraphe du CLUF ces conditions permettant de désassembler les binaires ?
                • [^] # Re: Les chinois du FBI...

                  Posté par  . Évalué à 3.

                  >C'est illegal selon ce que tu veux faire avec et ou tu vis

                  J'ai peut etre mal compris ce qui est marqué dans le cluff mais moi j'avais compris que non. C'est interdit un point c'est tout. Maintenant il faudrait que je le relise, j'ai peut etre effectivement loupé un point important. Cela dit n'ayant aucune envie d'aider un système que je n'utilise plus, je ne vais pas perdre mon temps à ca. (et de toutes facons, encore faudrait il que j'en ai les compétences. Ce qui est loin d'être le cas.)

                  >J'ai encore vu personne aller en prison pour ca,

                  Encore heureux. :D Mon sénario est une caricature. Mais je trouve qu'il montre bien l'absurdité de la situation : les gens voulant aider doivent se mettre dans l'illégalité pour le faire ... ( si, comme je le dit juste au dessus, c'est bien moi qui ai raison concernant le cluff)
                  • [^] # Re: Les chinois du FBI...

                    Posté par  . Évalué à 2.

                    En europe notamment le reverse engineering est permis pour plusieurs raisons. Aux USA il y a tout un bordel sur le "fair use" : ce qu'il est permis de faire selon la loi, peut importe ce que la licence dit.
                    • [^] # Re: Les chinois du FBI...

                      Posté par  . Évalué à 10.

                      Et donc, l’intérêt de mettre des clauses limitatives qui sont légalement nulles, c’est de ?…
                      • [^] # Re: Les chinois du FBI...

                        Posté par  . Évalué à 6.

                        Laisser planer un doute.
                        Comme ca, celui qui fait chier, s'il est asser petit, on agite le drapeau du procès et il s'écrase en se disant : "j'ai raison mais j'ai pas moyen de payer un procès et si en plus je le perd, je suis mort"
                      • [^] # Re: Les chinois du FBI...

                        Posté par  . Évalué à 2.

                        D'avoir des licences identiques pour plein de pays, avec une clause qui dit simplement "tout ce qui n'est pas legal est caduque" plutot qu'avoir une licence par pays.
                        • [^] # Re: Les chinois du FBI...

                          Posté par  . Évalué à 2.

                          Si c'est pas légal, c'est quoi l'intérêt de le préciser dans la licence du logiciel ? Dans tous les cas c'est pas légal.
                          • [^] # Re: Les chinois du FBI...

                            Posté par  . Évalué à 0.

                            Parce que ca pourrait l'etre dans certains pays, cette licence n'est pas utilisee que dans l'UE hein...
                            • [^] # Re: Les chinois du FBI...

                              Posté par  . Évalué à 4.

                              Donc si je veux utiliser un logiciel Microsoft, je dois acheter un droit d'utilisation pour quelques dizaines/centaines d'euros puis acheter une prestation à un cabinet d'avocats pour quelques dizaines/centaines de milliers d'euros pour savoir ce qui est valide ou pas dans le contrat de licence que Microsoft m'impose pour utiliser ses logiciels ?

                              N'eut-il pas été plus avantageux que Microsoft mutualise ce second coût pour fournir à tous ses clients en France des contrats conformes au droit français ?

                              BeOS le faisait il y a 20 ans !

                              • [^] # Re: Les chinois du FBI...

                                Posté par  . Évalué à -1.

                                On va dire que l'experience de ces 20 dernieres annees et quelque dizaines de millions de licences vendues en France a montre qu'il n'y avait pas vraiment de problemes de ce cote la hein.
                                • [^] # Re: Les chinois du FBI...

                                  Posté par  . Évalué à 4.

                                  Que dire par exemple du CLUF de Frontpage qui à la fin des années 90 interdisait d'utiliser ce logiciel pour publier des pages web "pour dire du mal de Microsoft" ?

                                  BeOS le faisait il y a 20 ans !

                                • [^] # Re: Les chinois du FBI...

                                  Posté par  . Évalué à 6.

                                  oh tu sais il arrive qu'on retire des médicaments du marché après 15 ou 30 ans, ou encore qu'on fasse des rappels de divers produits (voitures, tapis en mousse...) bien après leur lancement sur le marché.


                                  donc euh "ça s'est pas vu pendant 20 ans c'est que tout va bien" en gros non.
                                • [^] # Re: Les chinois du FBI...

                                  Posté par  . Évalué à 3.

                                  Ben tiens... On va remplacer "vendues" par "piratées" et je commencerai à te croire...

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

                                  • [^] # Re: Les chinois du FBI...

                                    Posté par  . Évalué à 1.

                                    Windows 7 : plus de 250 millions de licences vendues deja
                                    XP au cours de sa carriere : probablement 400-500 millions au moins
                                    Tu ajoutes a ca Office, Exchange, SQL Server, Win95, etc...

                                    La part de la France la-dedans ? Certainement au moins 5% je dirais --> 400 millions de licences de par le monde = 20 millions en France hein, et MS en a vendu largement plus de 400 millions...
                                    • [^] # Re: Les chinois du FBI...

                                      Posté par  . Évalué à 3.

                                      vendues, ou imposée de force ?

                                      Microsoft se vantait d'avoir vendues plein de licence "vista", pourtant une tonnes de personnes étaient sous XP.

                                      En imposant de force leur licence sur les nouveaux pcs, ils vendaient une licence vista. Et pas grave si le gars derrière foutait son os.


                                      Plus marrant encore: dans de grand groupes, ils achètent des pcs avec une licence OEM valide (dernièrement j'ai vu passer des portables avec un seven pré installé itou itou).
                                      Ok ca fait une licence...
                                      Sauf que derrière, la dsi fout leur souche windows ... XP \o/
                                      • [^] # Re: Les chinois du FBI...

                                        Posté par  . Évalué à 1.

                                        MS n'impose rien a personne. Si tu veux parler de vente liee, va te plaindre aux constructeurs.

                                        Le nombre de licences Vista etait de loin inferieur aux licences XP, regardes meme aujourd'hui, avec 250 millions vendues pour 7, il est a 20% , et il a deja depasse Vista pourtant.

                                        Plus marrant encore: dans de grand groupes, ils achètent des pcs avec une licence OEM valide (dernièrement j'ai vu passer des portables avec un seven pré installé itou itou).
                                        Ok ca fait une licence...
                                        Sauf que derrière, la dsi fout leur souche windows ... XP \o/


                                        Ah ca, des idiots il y en a partout hein...
                                        • [^] # Re: Les chinois du FBI...

                                          Posté par  . Évalué à 1.

                                          donc ms ne fait pas de cluf ni de contrat avec les constructeurs.

                                          Il met tout dans le domaine public maintenant ?

                                          (oui je te taquine là ;) )
                                          • [^] # Re: Les chinois du FBI...

                                            Posté par  . Évalué à 2.

                                            Oh si, mais ceux-ci sont revus par le DoJ donc pas de risque la dessus
                                            • [^] # Re: Les chinois du FBI...

                                              Posté par  . Évalué à 2.

                                              le Doj ?

                                              Pour ma culture, c'est quoi ce truc la ?
                                              • [^] # Re: Les chinois du FBI...

                                                Posté par  . Évalué à 2.

                                                Department Of Justice , les gars qui ont tape sur la tete de MS il y a 10 ans ,et l'accord a l'amiable force MS a avoir un comite independant qui revoit tous ses contrats avec les constructeurs notamment
                                                • [^] # Re: Les chinois du FBI...

                                                  Posté par  . Évalué à 3.

                                                  je croyais que c'était seulement avec les 10 plus gros constructeurs ?

                                                  Et ce n'est pas comme si des doubles compatibilités n'existaient pas, alors des doubles contrats , voir des clauses non écrites, ca peut exister aussi...
        • [^] # Re: Les chinois du FBI...

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

          >>> ca va surtout remettre enormement en cause ce gros mythe pourri disant qu'avoir le code ouvert donne un code plus sur...

          Bah non. Même si ça se confirme ça ne pourra pas remettre en cause le fait qu'avoir un code ouvert donne un code plus sûr puisque qu'on ne pourra toujours pas comparer avec le code non ouvert. On se saura pas si, même avec cette backdoor, le code est "plus" ou "moins" sûr que celui de Windows par exemple.
          Cela remettra juste en cause le fait que ça donne un code complètement sûr (mais personne n'avais jamais prétendu ça de toute façon).
          • [^] # Re: Les chinois du FBI...

            Posté par  . Évalué à 4.

            La theorie : C'est plus sur car tout un chacun peut relire le code et trouver des failles

            La pratique : Des failles ont ete (si c'est avere) inserees dans le code il y a 10 ans, et en 10 ans personne n'a rien vu

            Bref, on va dire que la theorie est tres tres loin de la pratique hein. Ce qui est possible ne vaut rien si cela n'est jamais applique et prouve.

            Et on ne va pas me dire que c'etait un bout de code anodin, on parle d'IPSEC, un composant de securite, il y a pas grand chose de plus important a auditer qu'un composant de ce type dans un OS.
            • [^] # Re: Les chinois du FBI...

              Posté par  . Évalué à 10.

              Exemple pratique: http://it.slashdot.org/story/10/12/14/2032209/Hidden-Backdoo(...)

              Code proprio, backdoor énorme (username: admin, password: !admin). Est-ce que ça pourrait arriver dans un OS libre ? Peut-être, mais avec une probabilité largement moindre je pense.
              • [^] # Re: Les chinois du FBI...

                Posté par  . Évalué à -1.

                Est-ce que c'etait dans un OS largement distribue ? Non, c'etait dans une appliance obscure.

                Tu paries que cela est possible dans un soft libre obscur ?
                • [^] # Re: Les chinois du FBI...

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

                  dans une appliance obscure.

                  Laquelle appliance permettrait quand même d'être très près de nombreuses données potentiellement de grande valeur.
                  • [^] # Re: Les chinois du FBI...

                    Posté par  . Évalué à -1.

                    Tout a fait, ca ne change rien au fait que c'etait un truc obscur, il aurait ete libre, personne n'y aurait jete un oeil.
                    • [^] # Re: Les chinois du FBI...

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

                      Mais arrête de raconter n'importe quoi, tu te fais des films...

                      Du code sans importance, j'en écrit souvent, et tu t'imagines même pas le nombre de personne qui lisent mon code, le nombre de mail avec patch ou proposition de faire le patch...

                      Donc, bref, le code source ne permet pas de rendre un soft sans faille/backdoor/... Mais ca aide, c'est sur...
                      • [^] # Re: Les chinois du FBI...

                        Posté par  . Évalué à 10.

                        > Mais arrête de raconter n'importe quoi, tu te fais des films...

                        t'es nouveau, ici, toi, non ?
                      • [^] # Re: Les chinois du FBI...

                        Posté par  . Évalué à 1.

                        Ca aide en theorie, le probleme est quand la pratique est differente de la theorie.

                        Insere une backdoor dans ton code (de maniere discrete donc, pas avec un gros BACKDOOR ecrit au dessus), regarde combien de temps cela prend avant que quelqu'un s'en rende compte.
                • [^] # Re: Les chinois du FBI...

                  Posté par  . Évalué à 4.

                  Appliance obscure, je n'irais pas jusque là, sauf erreur de ma part ces baies de disques sont assez répandues.
                  • [^] # Re: Les chinois du FBI...

                    Posté par  . Évalué à 1.

                    Faut voir ce que t'entends par repandues hein... Dans le monde des baies de disques oui, en nombre absolu c'est absolument minuscule compare aux OS traditionels.
                    • [^] # Re: Les chinois du FBI...

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

                      Oui, mais les données numériques des grands groupes, des banques, des gouvernements, tu crois qu'elles sont stockées / sauvegardées / archivées où ?

                      """
                      Et je n'me suis pas rendu compte que la seule chose qui compte
                      C'est l'endroit où c'qu'elle tombe
                      """

                      Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

                      • [^] # Re: Les chinois du FBI...

                        Posté par  . Évalué à 2.

                        > """
                        >
                        > Et je n'me suis pas rendu compte que la seule chose qui compte
                        >
                        > C'est l'endroit où c'qu'elle tombe
                        >
                        > """

                        Boris Vian <3 (pour ma confiture).
              • [^] # Re: Les chinois du FBI...

                Posté par  . Évalué à 1.

                Probabilité moindre je suis d'accord, mais moindre n'est pas nul: souvient-toi du bug de l'installeur Ubuntu, c'est du même niveau:
                https://launchpad.net/ubuntu/+bug/34606
            • [^] # Re: Les chinois du FBI...

              Posté par  . Évalué à 10.

              La différence entre la théorie et la pratique c'est qu'en théorie il n'y a pas de différence.
              • [^] # Re: Les chinois du FBI...

                Posté par  . Évalué à 6.

                Elle est pas tres pratique ta theorie
              • [^] # Re: Les chinois du FBI...

                Posté par  . Évalué à 2.

                Loi de Murphy:
                La Théorie c’est quand ça ne marche pas mais que l’on sait pourquoi.
                La Pratique c’est quand ça marche mais qu’on ne sait pas pourquoi.
                Quand la théorie rejoint la pratique ça ne marche pas et on ne sait pas pourquoi.
            • [^] # Re: Les chinois du FBI...

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

              Je complète ce que dis patrick-g:

              Avec du code fermé, en théorie je dois faire confiance à Microsoft pour corriger le code quand la porte dérobée est découverte.
              Avec du code ouvert, en pratique je peux vérifier qu'ils ont bien corrigé le code.

              Même si tu n'as pas tout à fait tort: il est évident qu'il faut un bon niveau de code pour vérifier ou auditer un code source et qu'en pratique on fait confiance aux développeurs et à la communauté. Effectivement se pose un problème de confiance (si ça se trouve Théo est payé par les russes pour déstabiliser.. :-). Mais je pense que cet incident va permettre de changer nos pratiques.

              "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

              • [^] # Re: Les chinois du FBI...

                Posté par  . Évalué à -2.

                [http://linuxfr.org/comments/1191521.html#1191521]

                Et si la faille/backdoor était ailleurs que dans le code concerné ?

                Dans le compilateur C ? Dans une ligne de sed planquée au fin-fond d'un Makefile ?

                Comment savoir si une backdoor ne peut pas être intégrée au code source, entre la phase de linkage, compilation, et non directement dans le code source.

                De plus, je me dis que le fonctionnement un peu opaque du développement des BSD n'est pas pour facilité la confiance des utilisateurs.

                Clairement, je préfère le modèle du Bazar où tout le monde peut contribuer, que celui où quelques développeurs, fussent-ils développeurs de logiciels libre sous licence BSD, ont la mainmise sur tout le système.

                Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.

            • [^] # Re: Les chinois du FBI...

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

              à quoi sert ce message tant que ce n'est pas avéré ? FUD...

              si c'est avéré je serai le premier à être d'accord avec toi, sinon c'est comme dire "hypothèse : selon les informations de untel, windows enverrait vos mots de passe et codes de CB à un tiers. cela reste à confirmer. conclusion : c'est incroyable que microsoft fasse des trucs comme ça, ils sont trop nuls, et les éditeurs d'antivirus aussi, etc.".

              bref, tu ne peux pas construire une conclusion sur un chateau de sable...
        • [^] # Re: Les chinois du FBI...

          Posté par  . Évalué à 4.

          Personne ne dit que le code ouvert est un code sûr (à part les libristes intégristes qui n'existe que dans tes rêves). Au mieux, il a de fortes chances d'être plus sûr.

          En revanche, tu n'as aucun moyen de voir si un code fermé est sûr.

          DLFP >> PCInpact > Numerama >> LinuxFr.org

          • [^] # Re: Les chinois du FBI...

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

            + 1

            Il s'agit (il me semble ?) d'une translation sémantique : utiliser le verbe "donner" à la place du verbe "permettre", dans la phrase : >(...) avoir le code ouvert donne un code plus sur...

            Avoir le code ouvert ne donne pas un code plus sûr. Il permet d'avoir un code plus sûr. C'est indiscutable, ça. Maintenant vient se greffer dessus forcément la problématique de l'organisation du travail sur un code ouvert. L'exemple ssl dans Debian, et celui ci dans OpenBSD, s'ils ne sont pas comparables en termes d'impacts ni de techniques, le sont sur ce point là : celui de l'organisation.

            limite troll, mais pas d'intention ici :
            Il est bien plus difficile de travailler sur un code ouvert que sur un code fermé. Mais c'est une difficulté indispensable aujourd'hui, dans les relations entre partenaires. Et c'est, ou cale devrait être, la plue-value indispensable d'une distribution à vocation commerciale : une relecture totale et complète du code. (donc pour faciliter la tache, un énorme travail directement en amont, avec et pour les projets). Ce que fait Redhat.

            Enfin, là ça va être du moinssage sévère : c'est une backdoor du FBI, donc perso je m'en fiche comme de ma première chemise tant qu'elle n'est exploitable que par eux. Tout comme je me fiche d'une backdoor de la DST dans une box d'un fai par le biais d'un firmware sur une puce sagem. RAB. Ce sont pas des ennemis ces gens là, hein !
            • [^] # Re: Les chinois du FBI...

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

              >>> Ce sont pas des ennemis ces gens là, hein !

              Si tu t'appelles EADS je doute que tu puisses considérer le FBI comme des copains et une backdoor créée par eux comme inoffensive.
              C'est un coup à se faire piquer des infos sur les propositions commerciales sur le contrat des ravitailleurs de l'US Air Force ça ;-)
            • [^] # Re: Les chinois du FBI...

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

              Une porte dérobée utilisable par une seule entité, ça n'existe pas. Y a qu'à voir que le gars qui a pondu le code qui nous intéresse ici ne fait visiblement pas parti du FBI. Après la porte elle est là, bien cachée, mais grande ouverte pour tout ceux qui la trouve.
        • [^] # Re: Les chinois du FBI...

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

          Euh, plutôt que de spéculer sur une affaire récente dont on ne connait pas encore les détails, regardons plutôt les affaires connues :
          http://fr.wikipedia.org/wiki/Porte_d%C3%A9rob%C3%A9e#Affaire(...)
          (je viens de modifier l'article pour ajouter HP MSA2000 et Cisco Unified Videoconferencing et ajouter des détails sur la tentative de backdoor Linux)

          On voit par exemple qu'une backdoor a existé dans le logiciel propriétaire Interbase durant 7 ans, et la backdoor a été trouvée lors de l'ouverture du code source par son éditeur.

          Au contraire, il y a eu la backdoir introduite dans le noyau Linux a été détectée en un jour à peine ! Pourtant la faille est très difficile à remarquer, même pour un programmeur C entrainé. Si j'ai bien compris, ce n'est pas les 2 lignes ajoutées à kernel/exit.c qui ont mis la puce à l'oreille, mais une incohérence entre le dépôt officiel (BitKeeper) et le miroir CVS. La faille a été introduite sur le serveur CVS en se faisant passer par David S. Miller (davem) et non pas dans le dépôt officiel (qui offrait une meilleur sécurité).

          Ahem, ça contredit complètement que tu racontes pasBill pasGates.
          • [^] # Re: Les chinois du FBI...

            Posté par  . Évalué à 1.

            je viens de modifier l'article pour ajouter HP MSA2000

            Il faudrait peut-être vérifier l'info. J'ai lu que certaines personnes ayant un MSA2000 expliquent que c'est le login/pass par défaut, et qu'il est parfaitement possible de le changer...
            • [^] # Re: Les chinois du FBI...

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

              Mise à jour de l'article SecurityWeek :

              « Update 11:23AM EST 12/15/2010 - SecurityWeek has received a statement from HP on the issue: "HP identified a potential security issue with the HP StorageWorks P2000 G3 only. This does not impact HP’s MSA line of storage solutions. HP has identified an immediate fix for this issue and is rapidly informing customers of the solution." »

              http://www.securityweek.com/backdoor-vulnerability-discovere(...)

              T'es sûr qu'on peut le modifier ? Pourquoi HP considère ça comme une faille de sécurité et va proposer un correctif dans ce cas ?
              • [^] # Re: Les chinois du FBI...

                Posté par  . Évalué à 1.

                T'es sûr qu'on peut le modifier ?

                Je ne suis sur de rien, je n'ai pas de MSA sous la main. Mais j'ai lu ici et là des infos contradictoires sur le sujet, c'est pour ça que je suggérais de vérifier l'info. Ça me paraissait un peu tôt pour le mettre comme un fait avéré dans wikipedia, surtout compte tenu de la gravité du truc. D'ailleurs ce n'est toujours pas très clair : on parlait de MSA2000 au début, et maintenant HP part sur les P2000. Et je n'ai toujours pas vu de communiqué officiel de la part d'HP (bon j'ai pas trop cherché), que des infos de seconde main.
          • [^] # Re: Les chinois du FBI...

            Posté par  . Évalué à 1.

            Au contraire, il y a eu la backdoir introduite dans le noyau Linux a été détectée en un jour à peine ! Pourtant la faille est très difficile à remarquer, même pour un programmeur C entrainé.

            Faut pas deconner quand meme, le code etait du genre :

            if (blabla->uid = 0)
            {
            }

            C'est un bug evident, et il n'a pas ete trouve par revue de code, mais du fait qu'il y avait une difference entre CVS.

            Ahem, ça contredit complètement que tu racontes pasBill pasGates.

            Du tout non, ca montre simplement que :
            a) Tout le monde est capable de trouver une modification non attendue au code (devine quoi, si quelqu'un change mon composant ici, au prochain sync je le verrai a coup sur)
            b) Tout le monde est capable de cacher des backdoors, meme le proprio
            • [^] # Re: Les chinois du FBI...

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

              if (blabla->uid = 0)
              {
              }


              Un vrai codeur paranoïaque écrit toujours

              if (0 == blabla->uid)
              • [^] # Re: Les chinois du FBI...

                Posté par  . Évalué à 2.

                Je n'aime pas du tout cette écriture, je trouve que ça "inverse" la logique du test (on teste si 0 est égal à blabla->uid). De plus, tout compilateur décent génèrera un warning lorsqu'il rencontrera une affectation au lieu d'une égalité dans un test (gcc le fait en tout cas).
                • [^] # Re: Les chinois du FBI...

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

                  Donc, d'après Tonton Th tu n'est pas un vrai codeur paranoïaque.

                  Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

              • [^] # Re: Les chinois du FBI...

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

                Ce n'est pas « if (current->uid = 0) » qui a été introduit, cette syntaxe produisant un avertissement avec les compilateurs C pas trop bêtes. C'est « if ((options == (__WCLONE|__WALL)) && (current->uid = 0)) » qui ne produit pas d'avertissement car l'assignation est entourée par des parenthèses.

                Il arrive tellement souvent qu'on se trompe (écrire a=b au lieu de a==b dans un if), que les compilateurs devraient générer une erreur. Sauf que beaucoup de programmes utilisent une assignation dans un if pour économiser une ligne ... Je trouve ça malsain d'économiser une ligne, ça rend le code plus difficile à relire et donc à maintenir.

                La grammaire de Python interdit une assignation dans un test : « if a=b: ... » génère une SyntaxError.
                • [^] # Re: Les chinois du FBI...

                  Posté par  . Évalué à 1.

                  dans un if() t'economises juste une ligne, mais quand c'est un while c'est tout de suite plus interessant :

                  while(item=getNextItem())
                  {

                  }

                  tu proposes quoi ?
                  • [^] # Re: Les chinois du FBI...

                    Posté par  . Évalué à 1.

                    Ben, une boucle for :


                    for(item = getNextItem(); item; item = getNextItem()) {
                    }
                    • [^] # Re: Les chinois du FBI...

                      Posté par  . Évalué à 3.

                      La répétition ne te gêne pas ?
                      • [^] # Re: Les chinois du FBI...

                        Posté par  . Évalué à 3.

                        Non. Quand j’en suis à me dire que la répétition de "item = getNextElement()" est chiante, je prend un langage un peu plus expressif que le C/C++ :)
                        Ben oui : en C, ce genre de répétition est courant, et pas toujours évitable (dans cet exemple du while oui). Si je suis en C, c’est que je me suis préparé à avoir ce genre de répétitions très légèrement irritantes parce que dans le contexte les avantages du C surpassent ce léger inconvénient.
                        • [^] # Re: Les chinois du FBI...

                          Posté par  . Évalué à 2.

                          Donne moi un exemple où une répétition en C n'est pas évitable ?
                          • [^] # Re: Les chinois du FBI...

                            Posté par  . Évalué à 2.

                            Allez, au pif, remplacer chaque pixel d’une image par sa distance avec la moyenne de la matrice :


                            float *data;
                            int width, height;

                            float avg = 0;
                            int pos, x, y;
                            for(y = 0, pos = 0; y < height; ++y, pos += pitch) {
                                for(x = 0; x < width; ++x, ++pos) {
                                    moy += data[pos];
                                }
                            }
                            avg /= width * height;
                            for(y = 0, pos = 0; y < height; ++y, pos += pitch) {
                                for(x = 0; x < width; ++x, ++pos) {
                                    data[pos] -= avg;
                                }
                            }


                            (oui, je sais, tu peux faire une macro, mais c’est encore plus moche)
                            • [^] # Re: Les chinois du FBI...

                              Posté par  . Évalué à 2.

                              Tu peux faire une fonction qui s'occupe de boucler et qui prend en paramètre un
                              pointeur de fonction qui va faire l'opération souhaitée pour chaque pixel !
                              • [^] # Re: Les chinois du FBI...

                                Posté par  . Évalué à 2.

                                Si pour chaque opération d’une ligne tu dois définir une fonction, je te raconte pas le plat de spaghettis résultant si ta chaîne de traitement est un poil plus longue que ce que je t’ai montré. Je préfère encore la solution de la macro.
                                • [^] # Re: Les chinois du FBI...

                                  Posté par  . Évalué à 2.

                                  Bah, après ça dépend effectivement du code dans son ensemble, tu ne vas pas
                                  utiliser les mêmes techniques de factorisation suivant la fréquence de
                                  répétition, ce qui est répété, etc.

                                  Et après effectivement, l'utilisation du point d'exclamation dans mon précédent
                                  commentaire montrait que c'était dit avec un peu d'ironie, dans le sens où c'est
                                  un peu overkill. Il y a effectivement des moments où ça complexifie plus
                                  qu'autre chose de chercher à tout prix à éviter de réécrire deux fois le même
                                  bout de code.
                    • [^] # Re: Les chinois du FBI...

                      Posté par  . Évalué à 1.

                      La répétition de "getNextItem()" ne génèrerait-elle pas un double appel, ce qui ferait donc sauter un élément de la liste ?!?
                      • [^] # Re: Les chinois du FBI...

                        Posté par  . Évalué à 2.

                        Bah le premier pour l'initialisation ensuite roulayzz...
                        Comme dans for (i = 0; ; ++i) {...} hein, tu n'initialises pas a -1.
                      • [^] # Re: Les chinois du FBI...

                        Posté par  . Évalué à 2.

                        Bah non, le code est équivalent à while((item = getNextItem())), juste que ça
                        implique d'écrire deux fois cette assignation, c'est laid.
            • [^] # Re: Les chinois du FBI...

              Posté par  . Évalué à 3.

              il n'a pas ete trouve par revue de code, mais du fait qu'il y avait une difference entre CVS.

              C'est bien la preuve que l'open source c'est mieux, ça n'aurait pas été possible avec du propriétaire.

              CQFD.

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

              • [^] # Re: Les chinois du FBI...

                Posté par  . Évalué à 2.

                Qui l'a trouve ? Un developpeur du logiciel.

                La meme chose se serait produite chez nous.
                • [^] # Re: Les chinois du FBI...

                  Posté par  . Évalué à 4.

                  ce qui est de toute façon complètement impossible a vérifier car on a ni accès au sources, ni au système de versionnement, ni même au fonctionnement interne de MS.
                  D'ici là que le type qui c'est occupé de cette partie dans le temps a été muté/viré/démissionné... au bout de 10 ans.

                  Là, un type* un peu à cheval sur la sécu peut aller tout seul faire sa propre idée, retrouver les modifs etc...

                  Et on peu savoir ce qui a été fait (pas de mise à jour "obscure" qui corrige des bugs mais on sait pas lesquels), et donc ensuite vérifier quel a pu etre notre risque passé, quels infos ont pu fuiter etc...




                  *personne physique ou morale
                  • [^] # Re: Les chinois du FBI...

                    Posté par  . Évalué à 5.

                    D'ailleurs TdR parle de ça dans le fil de discussion qui suit l'annonce.

                    If anything, the collaborative model we use should _decrease_ trust,
                    except, well, unless you compare it to the other model -- corporate
                    software -- where they don't even start from any position of trust.
        • [^] # Re: Les chinois du FBI...

          Posté par  . Évalué à 2.

          > Si ca se confirme, ca va surtout remettre enormement en cause ce gros mythe pourri disant qu'avoir le code ouvert donne un code plus sur...

          Un mythe ? revenons au faits avérés alors.

          L'attitude permise par la nature libre et non lucrative du projet est pourtant ici plutot responsable, et plus "securisante" que ce que pourrait se permettre une boite commerciale faisant du proprio. TdR envoie un mail pour faire part d'une incertitude, et suggère indirectement au grand public d'auditer. Il peux réagire ainsi parce que, entre autres :

          o Il n'a pas de comptes à rendre à des actionnaires fachés par les rumeurs.
          o Alerter le public : parce que le source étant dispo, les gens peuvent participer à l'audit.
          o L'interet d'OpenBSD reste d'inciter les gens a auditer le code. Trojan ou pas, ça fera peut-être des contributions.

          Dans la même situation, Bill Gates aurait-il caché le mail sous son tapis de souris (au risque de laisser les failles non corrigées) ou alerté le grand public ?

          C'est tout ce qu'on peux dire à partir des seuls éléments factuels dont nous dispons (le mail de TdR),

          PS: celà étant, je ne suis pas optimiste :
          o OpenBSD restera entaché par le doute. On ne pourra pas prouver qu'il n'y a pas, ou plus de trojan, même si on ne trouve rien.
          o Il est à craindre que pendant quelques temps, à chaque bug corrigé, le soupçon pèse sur auteur du bug.
          o Si l'accusation était vérifiée, le plus attristant et choquant ne serait pas l'impureté du code d'OpenBSD (osef un peu au fond), mais d'avoir la preuve tangible qu'une grande institution américaine se serait permis ce genre d'intrusions (et supposer les utilisations que l'institution aurait pu faire d'une telle faille... super pour les libertés individuelles).
          • [^] # Re: Les chinois du FBI...

            Posté par  . Évalué à 6.

            suggère indirectement au grand public d'auditer
            Un backdoor.
            Dans IPSec.
            Tu t'es vu quand t'as bu?
            Le grand public va prendre un bouquin sur le C, puis coder pendant une petite dizaine d’années histoire de ce construire les skills qui vont bien, et au passage se taper quelques textes bien chiants sur les réseaux, la crypto, et ensuite il va peut être pouvoir envisage d’auditer le code.
            Faudrais voir a revenir sur terre, le logiciel libre garanti les libertés du codeur, pas de l’utilisateur lambda qui veut juste faire coucou a sa famille qui ce trouve a l’autre bout du monde, envoyer un mail de rupture, faire coucou sur facebook, et mater un film de boule.

            Depending on the time of day, the French go either way.

            • [^] # Re: Les chinois du FBI...

              Posté par  . Évalué à 0.

              - passer en revue le code
              - vérifier les entêtes et les retours des fonctions
              - vérifier les headlers
              tout en cherchant les incohérences.

              ouaip en gros, facile.
              le plus compliqué est de récupérer le code source.

              le " grand public " , s'il voulait s'atteler à la tâche, finirait ptet moins con que les sempiternelles remarques sur " Mme Michu " qui justifient tout et n'importe quoi de la part de commerciaux ras-la-paquerette .

              Sans rire, des codeurs qui sont capables de faire une revue de code C, il en existe des dizaines de milliers dans le monde, et :
              - regarder le source d'IPSec
              ou plutôt ( pas le chien ) :
              - regarder les diffs de certaines dates

              c'est vraiment pas la mer à boire.
              et effectivement, le fait qu'un grand nombre de dév regardent le code permet de vérifier, même si, aux vues des mails en réponse, je suis de plus en plus certain que cette affaire n'est là que pour empêcher l'enquête sur les atteintes à la liberté d'expression lorsque TDR a clairement pris position contre la guerre en Irak.
              Ces individus, en sortant ces conneries, veulent masquer toute enquête sur les raisons du retrait de la subvention d'OpenBSD pour la prise de partie de TDR à l'époque.

              Sedullus dux et princeps Lemovicum occiditur

              • [^] # Re: Les chinois du FBI...

                Posté par  . Évalué à 3.

                > Sans rire, des codeurs qui sont capables de faire une revue de code C, il en existe des dizaines de milliers dans le monde, et
                Une faille réseau, ça peut être quelque chose de bien plus subtil qu’un code évidemment faux, ça peut être un algorithme correctement implémenté mais mathématiquement faible. La faille DNS qui a fait du bruit il y a quelques temps en est un excellent exemple : le code fait ce qu’on lui demande (pas de bug ni de faille dans le bug lui-même), mais c’est ce qu’on lui demande qui peut être problématique.
                • [^] # Re: Les chinois du FBI...

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

                  La faille DNS était une faille de spec. Les failles openbsd, c'est des trucs introduit. C'est pas le genre de choses qui se voit en revue facilement.

                  C'est plutôt des "tests unitaires" avec un bon taux de couverture qu'il faudrait.

                  "La première sécurité est la liberté"

                  • [^] # Re: Les chinois du FBI...

                    Posté par  . Évalué à 6.

                    Les protocoles réseaux, à fortiori avec sécurité renforcée genre IPsec, ont souvent une part d’aléatoire, qui te rend impossible des tests unitaires exacts bit-à-bit. Enfin, si, tu peux tester

                    > La faille DNS était une faille de spec.
                    C’est bien ce que je dis : un code correct au regard de la spec peut très bien introduire une vulnérabilité.
                    Il faut voir que tu as souvent plusieurs algorithmes pour implémenter une spec. Quand la spec te dit « prenez un nombre aléatoire », tu as plusieurs manières de faire.
                    Mais certains algorithmes qui respectent la spec peuvent introduire des failles. L’exemple de debian et OpenSSL. En gros, la spec elle dit, « générez un nombre aléatoire. ». La version de debian a fait comme ça (c’est imagé hein) :
                    srand(getpid()); rand()
                    Ça respecte la spec. Un relecteur qui connaît le C, qui a la spec sous les yeux, il dira : OK, pas de faille introduite. Mais il y en a une : l’entropie de getpid() n’est pas assez grande.
                    On est encore là dans un cas simple, mais c’est juste pour dire que sans compétences en sécurité des réseaux et des chiffrements, non, un programmeur C lambda n’est pas forcément capable de reconnaître une faille ou une backdoor en regardant le code. Et même quelqu’un ayant de telles compétences risque d’avoir du mal si c’est plus évolué que srand(getpid()), sauf à faire une analyse en profondeur du code (ce qui prend du temps et/ou de l’argent).
                    • [^] # Re: Les chinois du FBI...

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

                      Quand la spec te dit « prenez un nombre aléatoire », tu as plusieurs manières de faire.

                      C'est très facile de faire un test pour prouver que ton générateur est suffisant.

                      Ce n'est pas parce que tu as un nombre aléatoire que tu ne peux pas faire de tests. De plus, la plus part des nombres sont pseudo-aléatoires donc tu peux tout à fait reproduire un test en fixant la graine.

                      "La première sécurité est la liberté"

              • [^] # Re: Les chinois du FBI...

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

                On croit rêver.
                Tu crois qu'analyser le code d'une stack IPSec, d'un générateur de nombres aléatoires devant garantir un certain taux d'entropie, que tout ça "n'est pas la mer" à boire pour des codeurs C ?
                T'es développeur pro ?
                • [^] # Re: Les chinois du FBI...

                  Posté par  . Évalué à 0.

                  t'en as jamais rencontré, ou bien ?
                • [^] # Re: Les chinois du FBI...

                  Posté par  . Évalué à 5.

                  Il est trolleur pro sur LinuxFR, c'est pas la meme chose?
                • [^] # Re: Les chinois du FBI...

                  Posté par  . Évalué à 2.

                  non, je crois que l'obscurantisme consiste à faire croire qu'il est impossible pour un individu d'acquérir les compétences permettant de réfléchir à la question.

                  T'es développeur contre ?

                  Sedullus dux et princeps Lemovicum occiditur

                  • [^] # Re: Les chinois du FBI...

                    Posté par  . Évalué à 3.

                    j'ai les connaissances nécessaires du langage pour le faire.
                    Mais je sais que je ne peux pas le faire, je n'ai pas assez d'expérience (et ca m'intéresse pas trop).

                    Je sais conduire une voiture (mais si mais si), pourtant je battrais jamais sébastien loeb.

                    Il ne suffit pas d'avoir une légère connaissance technique pour réussir à faire.
                    • [^] # Re: Les chinois du FBI...

                      Posté par  . Évalué à 1.

                      si 50 000 jeunes sportifs se mettent à concourir sportivement dans le monde, combien arriveront au niveau de Loeb ? quelques dizaines ? On n'en sait rien.
                      Si personne ne court , combien ?
                      Zéro.

                      Sedullus dux et princeps Lemovicum occiditur

                  • [^] # Re: Les chinois du FBI...

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

                    Théorie de l'homme de paille, toussa...
              • [^] # Re: Les chinois du FBI...

                Posté par  . Évalué à 2.

                C’est quand la dernière fois que tu es allé ramasser de la caillasse pour en extraire le fer, pour ensuite en forger un couteau à beurre pour te préparer une tartine pour ton petit dej?

                Depending on the time of day, the French go either way.

                • [^] # Re: Les chinois du FBI...

                  Posté par  . Évalué à 6.

                  on dirait du Minecraft
                • [^] # Re: Les chinois du FBI...

                  Posté par  . Évalué à 3.

                  T'as oublié le plus important: la réalisation du charbon de bois pour la forge.

                  Sedullus dux et princeps Lemovicum occiditur

      • [^] # Re: Les chinois du FBI...

        Posté par  . Évalué à 5.

        Pour celles et ceux qui comme moi n'ont pas compris immédiatement ce que NDA veut dire : Accord de non-divulgation.
    • [^] # Re: Les chinois du FBI...

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

      À mon humble avis, le problème avec un langage comme le C, c'est que tu as vite fait de passer à coté d'une déclaration tout à fait valide, mais qui ne fait pas exactement ce que tu penses au premier regard.

      Cela est du aux symboles identiques utilisés pour des sens différents, quelques exemples :
      * a = b et a == b
      * a & b, a && b, a = &b
      * int *a, a = *b, a = b * c

      C'est surtout un problème de perception visuel, sauf à sciemment se concentrer, on ne lie pas en déchiffrant symbole par symbole, mais par groupe, comme on lit des mots et pas une succession de lettres. Si en plus un commentaire à coté vient renforcer ce biais cognitif en te confortant dans l'idée que l'incantation de C que tu vois là fait bien ce que tu imagines, t'as encore moins de chance de la détecter.

      Je doute que Dennis Ritchie avait ces problématiques cognitives en tête quand il à conçu C. À moins qu'il ait été payé par la NSA pour pondre un langage qui permettrait justement d'introduire facilement des backdoors grâce à sa syntaxe ambiguë (pour l'humain, s'entend).

      Une syntaxe moins susceptible d'entraîner l'erreur pourrait être, par exemple à la place des usages du &:
      * a and b (et logique)
      * a & b (et logique bit à bit)
      * a = @b (adresse de b)

      Mais bon, maintenant c'est trop tard. :)
      • [^] # Re: Les chinois du FBI...

        Posté par  . Évalué à 4.

        Mouais pour moi les problèmes du C (qui sont plutôt originaires de ce qu'il y a entre la chaise et le clavier) qui peuvent conduire à des backdoors, c'est plus :

        - La manipulation de buffers et de chaines de caractères (avec les erreurs de calcul sur
        des longueurs de buffers, l'utilisation de fonctions dangereuses comme strcpy et autres...)
        - La gestion du signed/unsigned
        - Le traitement des erreurs

        Pas tellement des problèmes de syntaxe.
        • [^] # Re: Les chinois du FBI...

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

          Bien sûr qu'au final c'est toujours le gars qui code qui fait des erreurs. Cela dit si le langage n'est pas conçu pour éviter les biais cognitifs dans lesquels le pékin moyen s'engouffre allégrement, il ne faut pas s'étonner que ces erreurs soient commises et qu'elles ne soient repérés que difficilement.
        • [^] # Re: Les chinois du FBI...

          Posté par  . Évalué à 3.

          Bof, c'est un cas ou le langage facilite la tâche à l'interface chaise/clavier pour faire des erreurs. Ou masquer des comportements pas du tout triviaux dans du code.

          C'est particulièrement bête quand la machine est potentiellement capable de limiter ces problèmes, ou le langage par construction ou une sémantique adaptée.
      • [^] # Re: Les chinois du FBI...

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

        * a = b et a == b

        Est-ce unique à C?
        En PHP, on a le droit a:
        a = b et a == b et a === b

        Et c'est un langage très utilisé...
    • [^] # Re: Les chinois du FBI...

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

      > il faudra s'interroger sur le fait que ce soit resté présent dans le code depuis l'an 2000 sans que personne ne remarque quoi que ce soit.

      Parce qu'après avoir audité ton code (ou l'avoir fait audité par quelqu'un en qui tu as confiance), tu crois vraiment que tu vas recommencer un audit tous les ans à Noël ?

      Si tu ne détectes rien de louche après audit, ben, tu assumes que ça marche comme il faut…
  • # Dites moi...

    Posté par  . Évalué à 10.

    Personne aurait vu un truc nomme FBI_KEY dans le code d'OpenBSD par hasard ?

    Sur ce, je -->[]
    • [^] # Re: Dites moi...

      Posté par  . Évalué à 10.

      Pourquoi, vous l'avez aussi dans Windows et vous ne savez pas d'où ca vient ?
    • [^] # Re: Dites moi...

      Posté par  . Évalué à 4.

      Puisque tu as accès au code de Windows, tu peux nous faire un "grep FBI_KEY" ? (ou plutôt un "grep (FBI|NSA|USA|WTF|CHINA)_KEY"

      « En fait, le monde du libre, c’est souvent un peu comme le parti socialiste en France » Troll

      • [^] # Re: Dites moi...

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

        Il existe une affaire de clé de chiffrement asymétrique dont une clé publique appellée « _NSAKEY » s'est retrouvée dans Windows NT4 : http://fr.wikipedia.org/wiki/NSAKEY

        Je suppose que pasBill pasGates fait référence à ça.
      • [^] # Re: Dites moi...

        Posté par  . Évalué à 4.

        Il est sous Windows, la bonne commande est findstr.

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

  • # Légalité du procédé?

    Posté par  . Évalué à 5.

    Y-a-t-il des recours juridiques possibles?
    Après tout, il s'agit d'un sabotage en bonne et due forme, mais comment le caractériser?

    -Il faut d'abord prouver que la faille a été introduite volontairement. Ceci est admis puisque le dév responsable s'est dénoncé.
    -Ensuite, il faut prouver que le FBI a bien "commandé" ces failles. Probablement déjà plus difficile...
    -Enfin, quand un développeur est autorisé à commiter sur un projet libre, est-il lié par un contrat moral ou assimilé ou est-il accepté aux risques et périls du projet?

    En tant qu'employé d'une entreprise, il y aurait certainement des suites, mais pour un bénévole?
    • [^] # Re: Légalité du procédé?

      Posté par  . Évalué à -1.

      Ben je vois mal de quoi tu vas les accuser, la licence du soft dit comme toutes les licences soft que t'utilises le truc a tes risques et perils apres tout...
      • [^] # Re: Légalité du procédé?

        Posté par  . Évalué à 2.

        Je ne parle pas de recours juridique contre OpenBSD, mais par le projet OpenBSD contre le FBI, ou à la limite contre les dévs concernés.
      • [^] # Re: Légalité du procédé?

        Posté par  . Évalué à 4.

        Un disclaimer ne te défausse pas de ta responsabilité quand tu agis intentionnellement.

        Autant tu peux très bien dire que tout logiciel est probablement sujet à des bugs et que tu ne garantis pas les conséquences d'un tel bug (mais il y a quand même des limites du genre négligence ou best effort par rapport à ce qu'on est en droit d'espérer).

        Mais de là se protéger derrière ce genre de licence pour espérer ne pas être rendu responsable d'actes délictueux voire criminels perpétrés en toute connaissance de cause, il y a un monde.
        • [^] # Re: Légalité du procédé?

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

          Avec un raisonnement comme ça on ne pourrait pas publier de code source de programme mallicieux dans le but honnête de montrer comment peut faire un attaquant et donc comment s'en prémunir.

          Et que devrait-on dire aussi des gens qui vendent des armes ? Que je sache ils ne sont pas responsable des usages qui en sont fait.
          • [^] # Re: Légalité du procédé?

            Posté par  . Évalué à 2.

            Alors déjà, si tu dis dans les clauses de distribution « si on fait frire ton disque dur tu peux pas nous poursuivre », en droit français, cette clause ne sera pas validée.

            Si tu dis « je ne suis pas responsable de ce que mon programme peut faire à ton ordinateur » (et qu'il fait frire ton disque dur), ben tu peux demander réparations, parce que (par exemple hein) le programme était censé être un simple driver de carte son (et dans ce cas, pourquoi le driver touche-t-il au DD ?). Ça ne veut pas forcément dire que tu seras indemnisé/que tu auras gain de cause, parce que l'erreur peut se trouver plus « bas » dans la chaîne. Par exemple,j'ai souvenir d'une version de Mandrake/Mandriva qui rendait certains modèles de lecteurs CD-ROM inutilisables. Mandrake utilisait un bit pour demander au lecteur de se préparer à écrire quelque chose, et si le lecteur ne faisait pas graveur, alors une erreur se produisait, sinon la distrib savait qu'elle avait affaire à un graveur. C'était une exploitation astucieuse des standards. Sauf qu'un des fabricants de lecteurs-pas-graveurs de CD-ROM a eu l'idée géniale d'utiliser ledit bit pour activer la réécriture du firmware (mise à jour etc). Et du coup, paf le lecteur.

            Dans ce cas, Mandrake n'est pas en cause, c'est le constructeur qui n'a pas respecté les standards (ou peut-être même les normes). Donc il y a bien un responsable, et ce n'est pas le mec qui a fait le soft.

            Concernant les virus, les machins de rootkit et autres, de ce que j'ai cru comprendre, c'est effectivement considéré comment étant une « arme numérique »... Donc oui, celui qui étudie ça dans son coin a sans doute des comptes à rendre du point de vue de la loi (mais je suis pas juriste, tout ça). Tout autant que ceux qui utilisaient SSH au lieu de SSF à l'époque où les méthodes de chiffrement étaient encore limitées en France ...
    • [^] # Re: Légalité du procédé?

      Posté par  . Évalué à 3.

      "Ensuite, il faut prouver que le FBI a bien "commandé" ces failles. Probablement déjà plus difficile..."
      Le NDA est un début de preuve : s'ils ont signé un contrat, c'est que le FBI a passé une commande. Ça ne dit sans doute pas noir sur blanc sur quoi ils ont travaillé, ni les backdoors qu'ils devaient ajouter, mais ça enlève l'excuse "ah mais non, on n'a jamais rien demandé à ce développeur, d'ailleurs on le connait pas !" pour le FBI.
    • [^] # Re: Légalité du procédé?

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

      La raison d'Etat doit exister aux usa, aussi :-)
      • [^] # Re: Légalité du procédé?

        Posté par  . Évalué à 2.

        Et pour des tas de raisons ;-)

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

    • [^] # Re: Légalité du procédé?

      Posté par  . Évalué à 3.

      En droit, ça s'appelle un abus de confiance (le dev aura probablement des comptes à rendre à la justice) et dans le droit américain je suspecte fortement que cet acte viole une bonne douzaine de lois fédérales, même si c'est le FBI qui l'a perpétré, mais bon, quod licet Jovi non licet bovi.

      S'il y a NDA c'est qu'il y a contrat, avec des signataires, donc des noms, donc des personnes responsables et justiciables. Il ne s'agit pas ici de saboter un programme dans un but bien précis comme arrêter une personne particulière ou une organisation criminelle. Il s'agit du monde entier qui est potentiellement visé, tout le monde est coupable. Le pire, c'est qu'il y a quand même des administrations américaines qui utilisent OpenBSD pour gérer des données plus ou moins sensibles (probablement l'Armée US aussi ?), donc autant de cibles faciles pour des pirates ou des gouvernements plus ou moins chanceux, talentueux ou bien renseignés. Soit les gens du FBI qui ont fait ça sont complètement cons ou inconscients ou les deux (ça aurait été une agence de renseignement, on aurait compris mais là il s'agit du FBI, en théorie ce sont des civils dont le but est de protéger les civils et pas d'aller plus loin que ça), soit le jeu en valait vraiment la chandelle et que cela dépasse le cadre de simple utilisation de OpenBSD, un système d'exploitation à la diffusion plutôt confidentielle, en comparaison avec les mastodontes du marché.

      Une chose est sûre, on n'est à l'abri nulle part et sur aucun OS, libre ou propriétaire.
      • [^] # Re: Légalité du procédé?

        Posté par  . Évalué à 0.

        il y a contrat, avec des signataires, donc des noms, donc des personnes responsables et justiciables.

        Et bien entendu, le contractant du FBI a mis son vrai nom sur le contrat...
        • [^] # Re: Légalité du procédé?

          Posté par  . Évalué à 2.

          le FBI, encore une fois si c'est bien le FBI qui est derrière le coup, l'a fait à travers une entreprise qui elle-même a des contrats avec le FBI. L'entreprise a probablement un contrat avec le FBI pour ça puisque développer des backdoors est une activité illicite et qu'elle - l'entreprise - voudra protéger ses arrières. Il s'agit quand même du FBI, donc de l'État fédéral américain. Donc oui, le contractant du FBI est obligé de mettre son vrai nom. Sinon, c'est une opération sous couverture potentiellement illégale pour l'État et certainement illégale pour l'entreprise contractante qui risque gros.

          On parle bien du FBI, pas de la CIA (qui a d'autres prérogative et qui est un peu au dessus des lois), et les États-Unis, on est d'accord, ce n'est pas un pays parfait, loin de là, mais ce n'est pas la Chine non plus. le Bureau Fédéral doit respecter les lois fédérales et à moins que les lois ne l'y autorise eh bien comme dans tous les pays qui se veulent libres et démocratiques, si le FBI a fait ça il doit en rendre des comptes devant la justice de son pays.

          Mais voyons le bon côté des choses, si c'est illégal - je l'espère pour le peuple américain et pour la justice et la démocratie dans le monde - alors il y a probablement un bon paquet de fric à se faire pour le projet OpenBSD, de quoi se financer pour au moins une dizaine d'année.
    • [^] # Re: Légalité du procédé?

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

      Il faut aussi qu'il n'y ait pas prescription. C'était il y a 10 ans quand même.

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

      • [^] # Re: Légalité du procédé?

        Posté par  . Évalué à 3.

        En droit français "Pour les infractions clandestines, qui sont non apparentes, la prescription ne court qu'à compter du jour où l'infraction a été découverte, dans des conditions permettant l'exercice de l'action publique." dixit Wikipédia.

        Les plus rigoureux pourront aller vérifier cette affirmation sur Légifrance ou bien se contenter de croire Wikipédia.

        BeOS le faisait il y a 20 ans !

        • [^] # Re: Légalité du procédé?

          Posté par  . Évalué à 4.

          Pas dans le cas de l'abus de biens sociaux.
          "Enfin, s’agissant d’une infraction délictuelle, la prescription est de trois ans, le point de départ étant fixé au jour de la commission des faits eu égard à son caractère instantané. Mais au regard de la nature occulte de cette infraction, la jurisprudence a reculé ce point de départ « au jour où le délit est apparu et a pu être constaté dans les conditions permettant l’exercice de l’action publique » (Cass.crim10/08/1981).

          Il en résultait une imprescriptibilité de l’infraction, ce qui a été fortement critiqué.

          La Cour de cassation a, en conséquence, modifié sa jurisprudence dans un arrêt rendu par la Chambre criminelle en date du 5 mai 1997. Elle y énonce que « la prescription de l’action publique du chef d’abus de biens sociaux court, sauf dissimulation, à compter de la présentation des comptes annuels par lesquels les dépenses litigieuses sont mises à la charge de la société ».
          "

          Cf. ici : http://www.avocats-picovschi.com/la-reforme-de-l-abus-de-bie(...)
  • # Et si ?

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

    Et si la faille/backdoor était ailleurs que dans le code concerné ?

    Dans le compilateur C ? Dans une ligne de sed planquée au fin-fond d'un Makefile ?
    • [^] # Re: Et si ?

      Posté par  . Évalué à 10.

      Oui.

      La faille de sécurité, ça peut être un piège logique, indétectable lors de la lecture de code.
      Prenons un exemple: le WEP. Sur la papier, ça se tient, le code est correct. Néanmoins, une erreur logique fait leaker un bout de la clé WEP à chaque paquet envoyé. Au final, bam, on lit ce qui se passe.

      S'il se passe la même chose avec les VPNs, c'est problématique. Imaginons que chaque paquet fasse leaker un bout de clé car une obscure opération de hachage au fin fond d'un bout de code d'un include oublié dans un coin de disque un peu poussiéreux au fond d'une cave qui (bon j'arrête), et que cette fonction de hachage soit moisie.
      -Le code est bon
      -Les revues de code passent
      -une recherche bourrin de faille ne donne rien.
      Celui qui connait la faille peut, à un coût en calcul raisonnable, lire les données en clair -> Profit.

      J'avais lu aussi que le FBI/NSA adorait péter les fonctions de génération aléatoires. Et ça c'est effectivement puissant. Tout passe, tout fonctionne, mais en quelques minutes de calcul, tu déchiffres absolument tout. (Non je ne parlerai pas de debian).
      • [^] # Re: Et si ?

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

        >>>Prenons un exemple: le WEP. Sur la papier, ça se tient, le code est correct.

        Et tout dépend de l'époque, il y a quelques années, des DSI expliquaient fièrement que tout était archi-sécurisé chez eux, ils avaient du WEP. Aujourd'hui ce genre de déclaration fait doucement marrer.

        ウィズコロナ

        • [^] # Re: Et si ?

          Posté par  . Évalué à 8.

          On 15/Dec - 13:03, palm123 wrote:
          > Et tout dépend de l'époque, il y a quelques années, des DSI expliquaient
          > fièrement que tout était archi-sécurisé chez eux, ils avaient du WEP.
          > Aujourd'hui ce genre de déclaration fait doucement marrer.

          Effectivement, maintenant tu as un DSI qui te dit « On a un parc de serveurs
          ultra-sécurisé avec de l'OpenBSD », on te rit au nez.
          • [^] # Re: Et si ?

            Posté par  . Évalué à 1.

            d'un autre coté un utilisateur d'openBSD ne dira jamais qu'il utilise openBSD
            • [^] # Re: Et si ?

              Posté par  . Évalué à 5.

              contrairement à Arch Linux ?

              (plus sérieusement : pourquoi ? si ton système est bien, tu n'as pas besoin de le cacher pour être sécurisé)

              DLFP >> PCInpact > Numerama >> LinuxFr.org

              • [^] # Re: Et si ?

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

                Security through obscurity. Ça marche bien tant que c'est pas ta seule protection. Si ton Apache n'annonce pas sa version exacte à tout le monde, tu as un peu plus de chances de pouvoir patcher à temps le jour où il y a un zero day.

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

                • [^] # Re: Et si ?

                  Posté par  . Évalué à 5.

                  Plus drôle : le faire passer pour un IIS pour canaliser les attaques extérieures.

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

  • # ça allait fuiter...

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

    Théo a été obligé d'en parler, sinon ça allait fuiter sur WikiLeaks...
  • # "Reflections on Trusting Trust"

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

    Le principe de la backdoor la plus intéressante est celle qui serait intégrée au compilateur C, de telle manière qu'une compilation du code source du compilateur C sans backdoor produise un exécutable avec backdoor : totalement indétectable même avec le code source.

    http://cm.bell-labs.com/who/ken/trust.html
    http://en.wikipedia.org/wiki/Backdoor_%28computing%29#Reflec(...)

    blog.rom1v.com

    • [^] # Re: "Reflections on Trusting Trust"

      Posté par  . Évalué à 2.

      Tu peux quand même aller auditer le binaire...
      On trouve parfois de drôle de trucs apparemment: http://it.slashdot.org/story/10/12/14/2032209/Hidden-Backdoo(...)
    • [^] # Tu retardes..

      Posté par  . Évalué à 3.

      Pas totalement indetectable, tu retardes..
      En utilisant un autre compilateur, on peut trouver le probleme:
      http://www.dwheeler.com/trusting-trust/dissertation/html/wheeler-trusting-trust-ddc.html
      • [^] # Re: Tu retardes..

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

        Je comprend mieux pourquoi en aéronautique, ils regardent le code ASM produit par le compilateur, et pourquoi les puces de sécurité produite pour l'armée sont reverse ingénéré pour vérifier leur contenu.

        "La première sécurité est la liberté"

        • [^] # Re: Tu retardes..

          Posté par  . Évalué à 2.

          Et comment tu peux être sûr que le le prog de reverse n'a pas de backdoor, hein !
          Tu y'as pensé ?
          Ils sont PARTOUT !
        • [^] # Re: Tu retardes..

          Posté par  . Évalué à 8.

          Non en fait on regarde le code ASM parce que l'Ada ÉCRIT TOUT EN CAPITALES ça fait mal aux yeux /o\

          Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

  • # Et si le mail était faux ?

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

    Franchement, personne ne remets en cause le fait que le mail d'origine du mec est faux ?

    ( celui de gregory perry ) ?

    Y a pas de trace de signature GPG ni rien.
  • # Il y a bien une faille

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

    Enfin d'apres #grsecurity
    <spender> you see that n--,buf++ change in 2001? :P
    <spender> was the difference between always using only the first byte of entropy for its PRNG, and using the whole buffer that it was supposed to :p

    Le commit avec la faille http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/rnd.c.diff?r1=1.35;r2=1.36

    Et le correctif http://ftp.openbsd.org/pub/OpenBSD/patches/2.8/common/017_rnd.patch

    Donc en gros la faille a ete presente 1 an.
    • [^] # Re: Il y a bien une faille

      Posté par  . Évalué à 2.

      On parle ici de plusieurs mécanismes ("to make you aware of the fact that the FBI implemented a number of backdoors and side channel key leaking mechanisms ").

      En outre, Jason Wright (au moins) n'est, à priori, pas responsable du commit.
      • [^] # Re: Il y a bien une faille

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

        C'est Michael Shalayeff (mickey) qui a introduit la faille (volontairement ? ou pas ?) :
        http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/rnd.c
        Revision 1.36: Thu Apr 13 13:48:29 2000 UTC (10 years, 8 months ago) by mickey

        En 2000, son adresse mail était mickey@akula.com et sa signature était « paranoic mickey (my employers have changed but, the name has remained) ».
      • [^] # Re: Il y a bien une faille

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

        Moi ce qui me choque un peu dans cette histoire c'est que le gars (Greg) qui fait ces allégations cite un nom (Jason) et reste flou sur d'autres intervenants.

        Pourquoi ? Cela fait 10 ans qu'il attend pour sortir ça de son chapeau pourquoi n'a -t-il pu, si il est de bonne foi, étayer ses propos ?

        Le fameux Jason réponds aujourd'hui et si il n'est pas coupable des faits qui lui sont reprochés doit l'avoir bien en travers de la gorge... D'ailleurs, il l'exprime bien dans son mail. Pourquoi monsieur De Raadt ne l'a pas contacté pour qu'il est un droit de réponse ou au moins un moyen de s'expliquer et lui démontrer sa bonne foi... Theo est pourtant quelqu'un de très diplomate tout le monde le sait :)

        Tout ça ressemble plus a des chamailleries de psychotiques. Espérons que des faits viennent étayer ou détruire ces évènements.
  • # ça ramène moins sa gueule chez Gcu-Squad !

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

    Aucun article avec un titre débile. Pourtant la nouvelle a de quoi piquer. Comme Bon Scott et Jimi Hendrix, il semblerait que les admin de GCU soient morts étouffés dans leur vomi.
  • # Bounty

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

    Pour les amateurs, Dag-Erling Smørgrav propose une triple récompense à qui prouvera ces allégations. Détails ici :

    [http://maycontaintracesofbolts.blogspot.com/2010/12/openbsd-(...)]

    À vos loupes !
  • # Acronyme openBSD

    Posté par  . Évalué à 9.

    En fait, on nous a depuis le début trompé sur le sens de l'acronyme OpenBSD, si j'ai bien compris ... Ca devrait se lire "Open Backdoor Software Distribution", non ?

    (Et je vais aller tout de suite prendre l'air, en plus avec la clim foireuse d'ici ça me fera du bien ;) )
  • # grave quand mêmesi c'est juste

    Posté par  . Évalué à -1.

    c'est super grave cette news les gars.
    est-ce un hoax ?

Suivre le flux des commentaires

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