Exploit local dans le noyau Linux 2.6.30

Posté par  (site web personnel) . Modéré par Sylvain Rampacek.
26
18
juil.
2009
Sécurité
Brad Spengler, mainteneur du projet Grsecurity, a publié un exploit local pour le noyau Linux. Seule la version 2.6.30 du noyau est impactée. L'exploit a été publié rapidement car aucune distribution n'utilise cette version pour le moment. Il est capable de contourner les protections AppArmor, SELinux, LSM, et désactive l'audit. La faille concerne les interfaces réseaux virtuelles tun et a été introduite en février dernier. D'abord considérée comme un simple bug, elle a été découverte le 4 juillet, corrigée le lendemain, puis Brad a publié son exploit le 15 juillet.

Brad profite de l'exploit pour dire tout le mal qu'il pense de la gestion de la sécurité dans le noyau Linux (lire notamment tous les commentaires présents dans le fichier exploit.c du tgz). Il reproche notamment la correction silencieuse de failles qui pose problème aux distributions Linux : les mainteneurs ne savent pas quels patchs doivent être backportés dans les branches stables. Il reproche également l'absence d'analyse de l'impact d'un bug en terme de sécurité : certaines failles sont considérées comme non exploitables, alors qu'elles le sont.

La seconde partie de cette dépêche détaille la faille. La faille est intéressante, car en lisant le code source, elle ne semble pas exploitable. En fait, comme le pointeur est déréférencé avant qu'on teste si le pointeur est NULL, gcc supprime le test car il suppose que de toute façon le déréférencement causera une erreur fatale. L'option -fno-delete-null-pointer-checks de gcc permet de désactiver cette optimisation. Extrait du code posant problème :
struct sock *sk = tun->sk;
...
if (!tun) return POLLERR;

L'exploit alloue de la mémoire à l'adresse 0 (NULL) dans l'espace utilisateur où le code de l'exploit sera écrit. Le déréférencement du pointeur NULL ne cause donc pas d'erreur dans le noyau.

En décembre 2008, Julia Lawall avait posté 3 patchs (drm, agnx et go7007) corrigeant des bugs similares. Les patchs ont été générés avec Coccinnelle : outil permettant de patcher les pilotes Linux en utilisant des règles décrites dans un langage haut niveau.

Aller plus loin

  • # Kernel 2.6.30

    Posté par  . Évalué à 6.

    Hello,
    '[...]car aucune distribution n'utilise cette version pour le moment.'

    Et bien moi si (avec la version tildarchée de Gentoo) et il y a également Pardus 2009 qui utilise un kernel 2.6.30 (et peut-être d'autres...).
    • [^] # Re: Kernel 2.6.30

      Posté par  . Évalué à 3.

      (et peut-être d'autres...).

      Debian Unstable. Même s'il ne s'agit pas vraiment d'une distribution au sens propre (vu qu'il faut passer par une stable qu'on upgrade), elle doit être assez utilisée tout de même.

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

    • [^] # Re: Kernel 2.6.30

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

      La faille est également présente dans le noyau de test version 2.6.18 de RHEL5 (le patch introduisant la faille y a été backporté le 15 avril). Debian Sid propose le noyau 2.6.30.

      J'ai testé l'exploit, mais il ne fonctionne pas sur ma Debian, car il a besoin de Pulse Audio (qui n'est pas installé chez moi). Il semble que l'exploit utilise 3 failles différentes :
      * Faille noyau (tun)
      * Bug (faille) Pulse Audio
      * Bug dans la fonction personality() permettant de contourner la protection "mmap_min_addr" (adresse minimale qui peut être mappée). Par défaut, on n'a pas le droit de mapper une zone mémoire à partir de l'adresse NULL.
    • [^] # Re: Kernel 2.6.30

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

      ArchLinux aussi utilise un noyau 2.6.30
    • [^] # Re: Kernel 2.6.30

      Posté par  . Évalué à 1.

      bah selon distrowatch, on a quand même:
      - sidux 2009-02
      - ExTiX 7.0
      - Frugalware Linux 1.1 Pre 2
      - Pardus Linux 2009 RC (passé depuis en 2.6.30.1 dans la final)
      - openSUSE 11.2 Milestone 3
      - Ubuntu 9.10 Alpha 2

      bon, ok, peu de versions finales de distributions majeures, mais quand même, cette version du noyau a été diffusée.



      • [^] # Re: Kernel 2.6.30

        Posté par  . Évalué à 1.

        Bonjour,

        On a aussi SabayonLinux 4.2 qui utilise ce noyau ^^
        Pourquoi créer un noyau pour qu'il ne soit pas utiliser sinon ?!?
  • # ArchLinux

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

    Il y a aussi ArchLinux ;) Mais comme on installe un nouveau kernel dès la sortie d'une version de sécurité, on a pas de problèmes à se faire.
    • [^] # Re: ArchLinux

      Posté par  . Évalué à 1.

      Archlinux, caylebien. :o)
      Au 18 juillet 2009, la version stable du noyau d'Archlinux est la 2.6.30.1-1.
      La faille y est-elle corrigée ?
      • [^] # Re: ArchLinux

        Posté par  . Évalué à 4.

        Je dirais que non, car (si j'en crois les infos remontées par 'yaourt') le paquet date du 04 juillet, donc la veille de la correction de la faille.


        yaourt -Si core/kernel26
        Repository : core
        Name : kernel26
        Version : 2.6.30.1-1
        [...]
        Packager : Allan McRae <allan@archlinux.org>
        Architecture : i686
        Build Date : sam. 04 juil. 2009 13:18:23 CEST
        MD5 Sum : 0ee6fdabf3f7a2c3be64f4cb5574975c
        Description : The Linux Kernel and modules
        • [^] # Re: ArchLinux

          Posté par  . Évalué à 4.

          Je me réponds à moi-même pour signaler que la mise à jour dans ArchLinux vient de tomber.


          yaourt -Si testing/kernel26
          Repository : testing
          Name : kernel26
          Version : 2.6.30.2-1
          [...]
          Packager : Tobias Powalowski <tpowa@archlinux.org>
          Architecture : i686
          Build Date : lun. 20 juil. 2009 13:24:01 CEST
          MD5 Sum : 471b257bb598a00049a228ad4afc7747
          Description : The Linux Kernel and modules
          • [^] # Re: ArchLinux

            Posté par  . Évalué à 1.

            Elle est passée dans le dépôt core aujourd'hui d'ailleurs ;)
  • # Quelques commentaires

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

    >>> Brad profite de l'exploit pour dire tout le mal qu'il pense de la gestion de la sécurité dans le noyau Linux

    Brad a toujours été hyper-critique sur la sécurité du noyau Linux. Il faut bien voir que son gagne pain c'est grsecurity c'est à dire un patch de sécurité à appliquer sur le noyau vanilla. Il a donc tout intérêt à dénigrer le noyau normal afin de souligner la plus-value de son patch.
    Donc il faut prendre ce qu'il dit avec un gros grain de sel.
    Néanmoins on est forcé de constater que ses déclarations ont plus de force quand elles sont accompagnés d'un exploit 0-day qui passe à travers SELinux ;-)

    Il faut vraiment lire tout le blabla qu'il a mis en commentaire du fichier exploit.c car c'est très instructif sur le coté technique de la faille mais aussi sur le personnage qu'est Brad.
    Ce qui m'a étonné c'est qu'il colle des extraits de mails issus de la liste de diffusion vendor-sec.
    Cette liste est faite pour que des informations circulent entre les développeurs et les entreprises du libre au sujet des problèmes de sécurité. Bien entendu la liste est privée et dévoiler ainsi des mails privés comme le fait Brad est plus qu'impoli. Je me demande même si ce n'est pas illégal.

    Il faut savoir que Brad avait commencé par poster des vidéos de son exploit à l'oeuvre mais sans donner de détails techniques. Dans les commentaires d'exploit.c il se délecte de lire les échanges de mails sur vendor-sec (en ne donnant pas le nom du type qui lui a fourni les mails) ou les gens essayent, en ayant la vidéo pour seule information, de comprendre d'ou peut bien venir la faille.
    Il distribue les bons points et les mauvais points en fonction des analyses proposés, il casse du sucre sur le dos de Linus Torvalds, qualifié d'expert sécurité en fauteuil (arm-chair security expert) et enfin il balance un paragraphe final sur la sécurité du noyau qui serait déplorable.

    Ci-dessous je traduis l'ironique paragraphe d'introduction et le paragraphe final (je refuse de traduire les mail privés de vendor-sec).

    "Un mec monté sur son cheval m'a apporté ces informations : toutes mes félicitations aux membres de vendor-sec pour leur excellente analyse de la vidéo de mon exploit, dans la même veine que leurs analyses des vulnérabilités du noyau. Regardez les maitres à l'oeuvre".

    "Aux membres de vendor-sec : Même si vous ne me remercierez jamais (ou sgrakkyu ou Julien) vous êtes les bienvenus pour toute cette recherche gratuite dans le domaine de la sécurité qui aurait aussi bien pu être vendue dans le privé à la place. L'industrie (NdT : le marché des exploits) n'est plus ce qu'elle était en 2000, les gens ne publient plus les exploits maintenant : ils font du fric avec.
    Ne pas voir débouler des exploits ne signifie donc pas que vous faites du bon travail. Avez-vous noté les exploits très complexes qui apparaissent impossiblement rapidement juste après qu'une faille soit finalement patchée ? Il y a une raison pour ça.
    Si le code vulnérable avait été incorporé dans le 2.6.29 au lieu de l'être dans le 2.6.30 je n'aurai pas publié mon exploit. Je n'ai pas l'utilité de cet exploit...mais une bonne poilade ne se refuse jamais.
    - Ma suggestion est que vous engagiez des gars comme sgrakkyus ou Julien plutôt que ces vieux qui n'ont jamais écrit un exploit de toute leur vie. A part Stealth je ne connais personne de doué dans cette industrie et qui soit employé par vous.
    - Deuxième suggestion : Comme vous êtes des compagnies qui poussent l'open source et le logiciel libre ce serait bien si les justifications pour vos classifications de vulnérabilités étaient plus transparentes (ou même qu'elle soient publiées tout simplement). La vieille habitude que vous avez de classifier toute faille pour laquelle un exploit n'a pas été écrit en Denial of Service devient très fatigante et ne trompe plus personne.
    - Troisièmement, la politique officielle qui consiste à ne pas mentionner les informations qui concernent la sécurité lors des modifications du code de Linux est une honte et un mauvais service que vous rendez à vous même, aux autres vendeurs et à vos clients. Cela démontre un manque d'intégrité et de confiance dans vos propres produits. Je sais que vous n'avez aucune intention de changer cette politique puisque vous profitez grâce à celle-ci d'une réputation de sécurité indue et qui ne se base pas sur la réalité. Dire la vérité sur les vulnérabilités de vos logiciels ternirait votre image et ce n'est pas bon pour le business. Vous êtes félicités quand vous dissimulez des choses et pourtant c'est Microsoft qui à une mauvaise réputation.
    Si vous suivez les conseils que je vous donne alors peut-être que votre sécurité ne sera plus la risée de toute l'industrie
    ".

    A noter, pour répondre à une partie des critiques de Brad, que les mainteneurs des versions stables des noyaux se refusent à classer les corrections de bugs en fonction de critères de sécurité car pour eux il n'est pas possible de savoir à l'avance toutes les implications en matière de faille d'un bug donné.
    Brad affirme que cette politique de non classification empêche les gens de faire des choix quand aux corrections à appliquer et les mainteneurs lui répondent qu'il n'y a pas de choix à faire et qu'il faut de toute façon appliquer toutes les corrections.

    Bien malin celui qui peut dire qui a raison et qui a tort dans cette controverse, si les développeurs du noyau sont suffisamment attentifs aux problèmes de sécurité ou pas, si la réputation de Linux est vraiment surfaite ou si Brad exagère afin de pousser sa solution.
    Les pauvres péons que nous sommes sont bien en peine de trier et d'évaluer vraiment les affirmations des uns et des autres...mais en tout cas la controverse est lancée et la situation ne peut que s'améliorer.
    • [^] # Re: Quelques commentaires

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

      Bien que je pense que parmi tout ce qu'il raconte, il y a une part de vérité, le ton utilisée par Brad n'est pas le plus approprié pour discuter avec les développeurs. Ses critiques ne me semblent pas très constructives. Il ne propose pas de solution pour évaluer la criticité d'un bug noyau par exemple. Il se vante de contourner SELinux, AppArmor, LSM, l'audit, et son exploit utilise des failles dans Pulse Audio et personality(). Est-ce qu'il propose un correctif ou une bien une procédure pour éviter d'autres bugs similaires ? Non, il se contente de se moquer ouvertement des développeurs noyau...
      • [^] # Re: Quelques commentaires

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

        >>> son exploit utilise des failles dans Pulse Audio et personality()

        D'après les commentaires présents dans son code il n'a pas besoin de PulseAudio ou de quoi que ce soit :

        "SELinux lets any user in unconfined_t map at 0, overriding the mmap_min_addr restriction! pulseaudio is not needed at all! Having SELinux enabled actually *WEAKENS* system security for these kinds of exploits!".

        Quand au ton utilisé par Brad c'est clair qu'il est particulièrement exaspérant. Avec lui on a toujours le sentiment qu'il est l'être le plus intelligent sur cette planète et que tous les autres ne sont que de sombres abrutis et qu'ils devraient l'écouter comme le messie.
        Mais bon comme le dit l'un des intervenants sur l'article de LWN : "Personally I don't give a shit how angry or insane he may appear to be. He did a good job finding the exploit and did a good thing being public about it.".
    • [^] # Re: Quelques commentaires

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

      >> Bien malin celui qui peut dire qui a raison et qui a tort dans cette controverse, si les développeurs du noyau sont suffisamment attentifs aux problèmes de sécurité ou pas, si la réputation de Linux est vraiment surfaite ou si Brad exagère afin de pousser sa solution.

      Ce que je vois, c'est que Brad parle beaucoup, mais peut se le permettre car
      1/ Il abat de la besogne autant que les autres
      2/ Il donne des résultats
      3/ Ses idées ne peuvent pas faire de mal : soutenir les pros (les engager, les financer) et avoir une politique morale…

      Par ailleurs, tous ces gens qui codent du GPL se font des échanges *secrets* qui concernent le code. Certes, la "sécurité" peut justifier ça, mais je crois qu'il y a bien une cabale qui se fout du libre et qui veut juste pas perdre trop de fric. Je crois ainsi que Brad veut une économie et une politique responsables en matière de sécurité qui concerne autant l'industrie derrière linux que les "petits" utilisateurs qui ont autant le droit d'être correctement informés.
    • [^] # légal/illégal

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

      Bien entendu la liste est privée et dévoiler ainsi des mails privés comme le fait Brad est plus qu'impoli. Je me demande même si ce n'est pas illégal

      Je ne connais pas la loi US, mais pour ce qui est de la loi française (merci Eolas, mais je n'ai plus le lien sur l'article précis), par défaut tu peux divulguer toute correspondance que tu veux du moment où elle t'était destinée (ça enlève du cadre la réception par erreur ou le piratage).

      Après, si ils ont signé un NDA, c'est une autre histoire et c'est le non respect du NDA qui va jouer, pas le secret de la correspondance.

      Bien malin celui qui peut dire qui a raison et qui a tort dans cette controverse,

      Oh que oui... Chacun a des arguments qui se tiennent (la forme? Certes, mais il y a l'exploit, bien documenté, une bonne preuve), il n'y a pas d'un côté les gentils et de l'autre les méchants!
      • [^] # Re: légal/illégal

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

        Non en ce qui concerne le secret de la correspondance, il faut l'accord de l'émetteur.
        Je ne vais pas dire que j'ai 100% raison, car je n'ai pas connaissances des textes de lois exacts, mais j'en suis plus que quasi certain.
        Les divers articles qui en parlent sur Internet me confortent d'ailleurs dans cette position.
        • [^] # Re: légal/illégal

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

          Non en ce qui concerne le secret de la correspondance, il faut l'accord de l'émetteur.

          non, et re-non.

          Puisque tu m'obliges à rechercher...

          http://www.maitre-eolas.fr/post/2009/05/11/1406-pour-la-lett(...)
          "Quand vous envoyez un courrier, qu'il soit épistolaire ou électronique, il cesse de vous appartenir et n'est protégé que pendant son acheminement vers son destinataire. Au-delà, son destinataire en devient le propriétaire et en fait ce qu'il veut, sauf si le courrier contient des éléments relatifs à votre vie privée, dont la divulgation est dès lors prohibée (art. 9 du code civil), ou que son destinataire est tenu au secret professionnel (comme un avocat). Et une prise de position politique d'un citoyen adressée à son ministre ne relève pas de la vie privée."

          mais j'en suis plus que quasi certain

          Tu l'es toujours maintenant? ;-)

          Conclusion : arrêter de croire toutes les sottises qu'on trouve sur le net... (J'ai plus confiance en Maitre Eolas, avocat de profession, que tous les beaux parleurs sur le net)
          • [^] # Re: légal/illégal

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

            Cette précision juridique est intéressante mais elle ne change absolument rien au constat de l'illégalité de ce qu'à fait Brad (selon la loi française certes).
            Il n'est pas membre de la liste vendor-sec donc aucun de ces mails ne lui était adressé donc il n'avait pas le droit (toujours selon la loi française) de les publier.
            • [^] # Re: légal/illégal

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

              Il n'est pas membre de la liste vendor-sec

              Dans ce cas, oui c'est illégal si un membre de la liste ne lui a pas transféré les mails (car la, vu qu'un membre a transféré, il devient lecteur légitime de la correspondance, et peut donc en faire ce qu'il veut, comme les publier) (toujours selon la loi française).

              Comment a-t-il eu les messages?
              Car j'ai plus de doutes que toi sur l'illégalité que tu veux lui donner, du moins à la vue de la loi française.
              • [^] # Re: légal/illégal

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

                >>> Comment a-t-il eu les messages?

                Dans les commentaires de exploit.c il explique comment il est rentré en possession de ces mails...mais on ne peut pas dire que ce soit d'une précision absolue ;-)

                "A man riding on horseback has delivered some news"
                • [^] # Re: légal/illégal

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

                  Effectivement, c'est d'une clareté...

                  Sans cette information, tu ne peux pas dire que c'est illégal (ce que tu n'as effectivement pas dit ;-), tu t'es juste demandé), et je ne peux pas affirmer que c'est légal non plus (n'ayant pas une preuve que le mail lui a été passé volontaire).

                  Donc je ne peux que supputer : il y a de fortes chances qu'il ne soit pas l'illégalité au vue de la loi française, sinon ça signifierait de manière certaine que la liste vendor-sec a un gros trop de sécurité (piratable), et ça craindrait un peu beaucoup!
                • [^] # Re: légal/illégal

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

                  Hugues — (Voix off.) Bref, un jour un cavalier est arrivé à fond les ballons avec une lettre.

                  Le messager du Poney Express — Eh, les pédés il y a une lettre pour vous ! Tenez. Bonne bourre !

                  Hugues — Pauvre con, va !

                  LA CLASSE AMÉRICAINE ...
                • [^] # Re: légal/illégal

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

                  quelqu'un monté sur un cheval de troie ? :-)

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

            • [^] # Re: légal/illégal

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

              Faut voir... Lui a utilisé un mail qui lui était adressé... C'est la personne qui a fuité, la source, qui est responsable si elle a signé un NDA. Brad n'a rien enfreint.
              • [^] # Re: légal/illégal

                Posté par  . Évalué à 0.

                La divulgation de ces mails est illégale pour deux raisons:

                * Comme le rappelle Me Eolas, si cette correspondance contient des éléments relatifs à la vie privée de l'expéditeur, le destinataire ne devient pas propriétaire du message et ne peut donc pas en disposer publiquement comme bon lui semble. Et c'est bien le cas en l'espèce puisque le mail contient dans ses entêtes le nom de l'expéditeur mais aussi l'adresse IP (le plus souvent personnelle) d'où a été envoyé le message.

                * Me Eolas ne s'est basé que sur le code civil pour fournir sa réponse. Cependant on peut aussi se référer au code de la propriété intellectuelle, et considérer qu'en tant qu'oeuvre de l'esprit un mail bénéficie de sa protection. Il ne peut donc être diffusé publiquement sans le consentement de l'auteur.
                • [^] # Re: légal/illégal

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

                  Et c'est bien le cas en l'espèce puisque le mail contient dans ses entêtes le nom de l'expéditeur mais aussi l'adresse IP (le plus souvent personnelle) d'où a été envoyé le message.

                  Brad Spengler n'a pas divulgué les en-têtes. Quand au nom de l'expéditeur, cela n'appartient pas à la vie privée (ton nom est partout!).
                  Je t'invite à lire le post d'Eolas que j'ai pointé, à aucun moment il n'a été jugé illégal que le nom de la personne critiquant HADOPI arrive chez le chef de celui-ci en passant par parlementaire puis gouvernement : c'était dégueulasse, mais légal, et il n'y a pas plus dans les messages récupérés par Brad Spengler

                  et considérer qu'en tant qu'oeuvre de l'esprit un mail bénéficie de sa protection

                  Faut arrêter la fumette, un mail n'est aucunement une oeuvre de l'esprit, mais une correspondance. Je te défie de trouver le moindre juge qui n'éclatera pas de rire face à cette argumentation plus que bancale.
                  • [^] # Re: légal/illégal

                    Posté par  . Évalué à -1.

                    « Brad Spengler n'a pas divulgué les en-têtes. »

                    Peu importe, c'est tout le mail qui se trouve protégé et pas seulement les parties où n'apparaissent pas les données personnelles.


                    « Faut arrêter la fumette, un mail n'est aucunement une oeuvre de l'esprit, mais une correspondance. Je te défie de trouver le moindre juge qui n'éclatera pas de rire face à cette argumentation plus que bancale. »

                    En parlant d'arrêter la fumette... il n'y a pas que les oeuvres artistiques a être considérées comme des oeuvres de l'esprit mais aussi les logiciels, y compris le matériel de conception préparatoire

                    [http://www.industrie.gouv.fr/guidepropintel/fiches_pratiques(...)]
                  • [^] # Re: légal/illégal

                    Posté par  . Évalué à 0.

                    « Je t'invite à lire le post d'Eolas que j'ai pointé, à aucun moment il n'a été jugé illégal que le nom de la personne critiquant HADOPI arrive chez le chef de celui-ci en passant par parlementaire puis gouvernement : c'était dégueulasse, mais légal, et il n'y a pas plus dans les messages récupérés par Brad Spengler »

                    Me Eolas en tant qu'avocat sait tout à fait comment interpréter la loi pour faire valoir son point de vue. Cependant on ne peut affirmer de la légalité ou non du procédé tant que la justice ne ce sera pas prononcée.

                    Pour revenir au problème une correspondance privée (ce qui est le cas pour ceux qui participent à la liste de développement) ne peut pas être rendue publique sans l'accord des rédacteurs. C'est à la fois une atteinte à la vie privée au regard du droit français, et sans doute contraire au contrat d'utilisation tacite passé lors de l'inscription sur la liste.

                    Enfin, je maintiens que toute correspondance technique en vue du développement ou de l'amélioration d'un logiciel peut bénéficier de la protection du code de la propriété intellectuelle.
                    • [^] # Re: légal/illégal

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

                      C'est quoi cette croyance que les choses ne sont pas illégales avant qu'un juge ne se prononce ?

                      Quand un juge se prononce il dit si quelque chose *était* ou pas illégal, pas que ça le devient à partir de maintenant. Par conséquence, bien sur qu'on peut affirmer ou pas que quelque chose est légal. Éventuellement on peut se tromper ou ne pas tous être d'accord (et c'est entre autres pour ça que le juge est là), mais ça n'empêche pas le procédé d'être éventuellement illégal dès maintenant et de le dire dès maintenant.
                      • [^] # Re: légal/illégal

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

                        C'est quoi cette croyance que les choses ne sont pas illégales avant qu'un juge ne se prononce ?

                        Euh... Pourquoi cette question? Ici, les choses ne sont pas illégales car aucun article du code pénal (ou autre) ne condamne la divulgation de correspondance privée dont on est le destinataire (ni l'expéditeur au passage).

                        Pourquoi vouloir inventer des interdictions qui n'existent pas?
                        • [^] # Re: légal/illégal

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

                          Je ne sais pas si c'est légal ou pas, je ne me prononce pas. Mais c'est le "tu peux pas dire si c'est illégal, ça a pas été jugé" qui m'agace et qu'on voit trop souvent ici.
                        • [^] # Re: légal/illégal

                          Posté par  . Évalué à -1.

                          Allez publier les photos personnelles de votre copine à poil qu'elle vous a gentillement envoyé par mail, et vous allez voir si c'est légal.

                          C'est bien de la correspondance privée avec de photos faisant partie du message, cela relève au final de la vie privée.
                          • [^] # Re: légal/illégal

                            Posté par  . Évalué à 1.

                            bizarre que personne ait répondu.
                            Le mail contenait bien une partie, lié au CPI (photos, droit à l'image) (qui n'as pas forcément a voir avec la vie privée)
                            Ainsi donc le contenu a bel et bien une importance cruciale pour savoir si on a le droit de divulger ou non un mail.

                            Croire de facto parce qu'on a recu quelque chose on a le droit d'en faire tout et n'importe quoi est relativement comique.

                            Si je recois un code source par mail, il devient ma propriété ?
                            Bien sur que non.
                      • [^] # Re: légal/illégal

                        Posté par  . Évalué à 0.

                        Affirmer était pris dans le sens « manifester de manière indiscutable, prouver, démontrer ».
                        Ici il n'y a pas de certitude absolue, il y a matière à débat.

                        Au regard de la loi française on ne peut divulguer une correspondance privée qu'avec l'autorisation de l'expéditeur, ce n'est pas moi qui le dit c'est la loi:

                        A lire [http://blog-droit.over-blog.com/article-3186781.html]
                    • [^] # Re: légal/illégal

                      Posté par  . Évalué à 2.

                      Pour revenir au problème une correspondance privée (ce qui est le cas pour ceux qui participent à la liste de développement) ne peut pas être rendue publique sans l'accord des rédacteurs. C'est à la fois une atteinte à la vie privée au regard du droit français, et sans doute contraire au contrat d'utilisation tacite passé lors de l'inscription sur la liste.

                      D'ailleurs, il faut voir le nombre de journalistes qu'on a mis en examen à cause de ça ...

                      Enfin, je maintiens que toute correspondance technique en vue du développement ou de l'amélioration d'un logiciel peut bénéficier de la protection du code de la propriété intellectuelle.

                      C'est ton avis ou bien tu as des sources sérieuses pour le confirmer ?
                      • [^] # Re: légal/illégal

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

                        D'ailleurs, il faut voir le nombre de journalistes qu'on a mis en examen à cause de ça ...

                        source, source, source...
                        de ce que je connais, les journalistes sont mis en examen car ni l'expéditeur ni le destinataire n'ont souhaité que le journaliste ai accès à la correspondance (violation de la correspondance privée, article L 226-15 du code pénal)
                        Et je n'ai jamais vu de journaliste mis en examen quand le destinataire du courrier a transmis au journaliste le mail de l'expéditeur.

                        J'ai l'impression qu'il y a un bon gros mélange entre les gens qui se font transférer un mail et les gens qui interceptent, l'un est légal (pas interdit, ou alors sortez moi l'article de loi), l'autre non (explicitement interdit)...
                        • [^] # Re: légal/illégal

                          Posté par  . Évalué à 3.

                          source, source, source...
                          En fait, c'était un commentaire ironique. :)
                      • [^] # Re: légal/illégal

                        Posté par  . Évalué à 2.

                        « C'est ton avis ou bien tu as des sources sérieuses pour le confirmer ? »

                        Ici : [http://www.industrie.gouv.fr/guidepropintel/reglementations/(...)]
                        au paragraphe 1.2 Les logiciels il est indiqué que le logiciel (dès lors qu'il est original) est considéré comme une oeuvre de l'esprit et est protégé par le droit d'auteur, de plus cette protection s'étend aussi aux travaux préparatoires (Article L. 112-2 du Code de la Propriété Intellectuelle).

                        L'article de loi en question : [http://droit-finances.commentcamarche.net/legifrance/68-code(...)] où on peut lire précisément « 13° Les logiciels, y compris le matériel de conception préparatoire ;


                        PS: Il est regrettable de constater que certains s'amusent sur linuxfr à « moinser » systématiquement des opinions contraires à la leur et obligent ainsi à redonner les mêmes explications avec les mêmes informations pertinentes...
                        • [^] # Re: légal/illégal

                          Posté par  . Évalué à 2.

                          PS: Il est regrettable de constater que certains s'amusent sur linuxfr à « moinser » systématiquement des opinions contraires à la leur et obligent ainsi à redonner les mêmes explications avec les mêmes informations pertinentes...

                          Pourquoi faut-il redonner les informations si le texte est moinsé? Si elles ont été jugée inutiles une fois, elles ne le seront pas plus utile (voire plus inutile) une deuxième fois dans le même contexte.

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

                          • [^] # Re: légal/illégal

                            Posté par  . Évalué à 4.

                            Si elles ont été jugée inutiles une fois, elles ne le seront pas plus utile (voire plus inutile) une deuxième fois dans le même contexte.
                            C'est a supposer que le moinssage a été parce qu'inutile, et non pas parce que bidule chouette aime pas truc muche (et que si bidule chouette moinsse trop truc muche, il ne pourras pas continuer indéfiniment).
                            • [^] # Re: légal/illégal

                              Posté par  . Évalué à 3.

                              Celui (ou ceux) qui n'aiment pas trucmuche ne pourront pas le moinser indéfiniment mais, moi, quand je vois deux fois la même chose, et à fortiori si ce n'est pas un double post résultant d'une erreur de manipulation, j'ai tendance à moinser.

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

          • [^] # Re: légal/illégal

            Posté par  . Évalué à 1.

            Me Eolas : « Quand vous envoyez un courrier, qu'il soit épistolaire ou électronique, il cesse de vous appartenir et n'est protégé que pendant son acheminement vers son destinataire. Au-delà, son destinataire en devient le propriétaire et en fait ce qu'il veut, sauf si le courrier contient des éléments relatifs à votre vie privée, dont la divulgation est dès lors prohibée (art. 9 du code civil), ou que son destinataire est tenu au secret professionnel (comme un avocat). »

            Le courrier appartient au destinataire (il peut l'imprimer, le détruire, ...), mais ce qu'il contient reste la propriété de l'expéditeur (ce que ne nie pas Me Eolas puisqu'il peut y avoir atteinte à la vie privée). Enfin le fait que le code de la propriété intellectuelle ne soit pas mentionné, ne signifie pas qu'il ne s'applique pas.
      • [^] # Re: légal/illégal

        Posté par  . Évalué à 2.

        En France, les mails échangés sur une liste de discussion (où les abonnés sont identifiables et dont l'accès nécessite un abonnement) font partie de la correspondance privée, et publier le contenu d'un mail ne peut se faire qu'avec l'accord de l'expéditeur :

        Secret de la correspondance:
            [http://www.educnet.education.fr/legamedia/legadico/contenus/(...)]
            [http://www.murielle-cahen.com/publications/page2310.asp]

        Nature d'une liste de diffusion:
            [http://www.cru.fr/faq/droit-net/quelle_est_la_nature_juridiq(...)]
        • [^] # Re: légal/illégal

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

          Mais pourquoi diable le mec de TF1 viré à cause de son mail n'attaque-t-il pas sa député pour violation de la correspondance lui ayant couté son poste, vraiment?

          Ah, j'ai une réponse logique : parce qu'elle était dans son droit (personne destinataire du mail).
          A ton tour maintenant de trouver une raison, parce que le mec attaque TF1 en justice pour licenciement abusif, pas sa député pour rupture de la correspondance privée.

          Tu veux plus de preuves que tu interprètes trop? Educnet et murielle-cahen parlent du L 226-15, qui punit toute personne qui intercepte une communication. Ne s'applique pas au destinataire:

          Source : http://www.google.fr/search?q=L+226-15 (premier lien)
          "Est puni des mêmes peines le fait, commis de mauvaise foi, d'intercepter, de détourner, d'utiliser ou de divulguer des correspondances émises, transmises ou reçues par la voie des télécommunications ou de procéder à l'installation d'appareils conçus pour réaliser de telles interceptions"

          Mais bordel, tu insistes, et tu donnes le bâton pour te faire battre, c'est énorme ton obstination. En plus murielle-cahen, avocat, parle bien de violation de la correspondance privée, et pas du tout de ce que fait le destinataire, c'est toi qui en déduit ce qui t'arrange. (pour educnet, ils balance l'article du code pénal, et en font une tirade qui n'a rien à voir, aucune base solide, la honte)

          Quitte à te le rappeler : du moment ou le destinataire a reçu un message de toi, il peut faire ce qu'il veut de ce message, il ne t'appartient plus (tu lui a donné.) La loi est (pour une fois) limpide à ce sujet, et parle d'interception, rien à voir, le destinataire n'interceptant pas mais recevant un message. Trouve-moi les articles de loi qui interdisent la publication par le destinataire d'une correspondance plutôt que des sites bizarres (le pire dans l'histoire, c'est que les gens vont faire confiance à ces sites et se retrouver jeté au tribunal sans comprendre...)

          Il y a plein de jurisprudence sur le sujet, je te laisse chercher les décisions de justice, puisque tu as l'air de trouver tout ce qu'il te plait...
          • [^] # Re: légal/illégal

            Posté par  . Évalué à 2.

            Vous lisez mal ce qui est écrit en ne retenant que les cas extrêmes définis dans cette loi alors qu'elle concerne des cas beaucoup moins particuliers. Les ou ont là toute leur importance :

            « Est puni des mêmes peines le fait, commis de mauvaise foi, d'intercepter, de détourner, d'utiliser ou de divulguer des correspondances émises, transmises ou reçues par la voie des télécommunications ou de procéder à l'installation d'appareils conçus pour réaliser de telles interceptions »

            Donc comme vous le voyez la loi ne se restreint pas aux interceptions.


            Puisque il vous faut d'autres explications :

            « La divulgation non autorisée par l'émetteur du courrier électronique est une violation du secret des correspondances qui engage la responsabilité pénale de l'auteur de l'infraction sur le fondement de l'article L 226-15 du Code Pénal. »

            [http://blog-droit.over-blog.com/article-3186781.html]


            Et pour compléter, un cas concret comme quoi le destinataire d'un courrier ne peut en disposer comme bon lui semble :
            [http://www.net-iris.fr/forum-juridique/personne-famille/1203(...)]


            Pour l'affaire avec TF1, la priorité logique c'est d'attaquer TF1 pour le licenciement. Ensuite rien ne dit qu'il ne se retournera pas contre sa député UMP (qui avait transmis le mail au ministère de la culture pour obtenir des explications) ni contre le ministère lui-même. Au fait si d'après-vous il n'y a pas violation de la correspondance privée, pourquoi le collaborateur de Mme Albanel a-t-il été suspendu ?
            • [^] # Re: légal/illégal

              Posté par  . Évalué à 4.

              Après recherche, je crois que ce n’est pas comme ça qu’il faut interpréter le texte (c’est http://assiste.com.free.fr/p/droit/secret_des_correspondance(...) qui m’a mis sur la voie).

              Le premier alinéa, qui parle clairement d’interception en connaissance de cause :

              « Le fait, commis de mauvaise foi, d’ouvrir, de supprimer, de retarder ou de détourner des correspondances arrivées ou non à destination et adressées à des tiers, ou d'en prendre frauduleusement connaissance, est puni d'un an d’emprisonnement et de 45000 euros d'amende. »

              C’est le second alinéa qui pose problème mais il faut lire « émises, transmises ou reçues-par-la-voie-des-télécommunications » tout attaché, le « reçues » notamment s’applique à « voie de télécommunications » (je ne sais pas si je suis bien clair). Cet alinéa que vous citez ne sert qu’à étendre le premier alinéa aux messages émis, transmis ou reçus par télécommunications (dont les mails).
              • [^] # Re: légal/illégal

                Posté par  . Évalué à 1.

                Si on reprend le texte actuel [http://legifrance.gouv.fr/affichCode.do?idSectionTA=LEGISCTA(...)]

                Dans le premier alinéa on apprend que : « Le fait, commis de mauvaise foi, d'ouvrir [...] des correspondances arrivées ou non à destination et adressées à des tiers [...] est puni d'un an d'emprisonnement et de 45000 euros d'amende. »

                Et dans le second alinéa : « Est puni des mêmes peines le fait, commis de mauvaise foi, [...] d'utiliser ou de divulguer des correspondances émises, transmises ou reçues par la voie des télécommunications [...]. »

                Au final je soutiens que le fait, en toute connaissance de cause, de prendre connaissance de la correspondance par courrier électronique d'autri (c'est ce qui se passe lorsque l'on s'est vu transférer des messages personnels échangés entre d'autres personnes) et de la divulguer est condamnable.

                Reste encore le problème de la correspondance personnelles entre soi et une autre personne, et là encore je soutiens qu'on ne peut rendre publique les messages expédiés par cette autre personne, car elle reste propriétaire (au sens de la propriété intellectuelle) de ses écrits, comme le signale Wikipedia au sujet du Secret_de_la_correspondance : « Une correspondance reste la propriété intellectuelle de son auteur bien que le support physique soit la propriété du destinataire. »
                • [^] # Re: légal/illégal

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

                  Tu oublis des mots importants, comme commis de mauvaise foi.

                  En quoi serait-ce de la mauvaise foi si je transmets au monde entier un mail que j'ai reçu?

                  Bon, maintenant, je te laisse en penser ce que tu veux, je n'ai personnellement trouvé que des décisions de justice sanctionnant une personne n'étant pas sensée lire les mail, et pas un destinataire qui divulgue une correspondance privée (par exemple un site qui liste des décisions de justice : http://www.google.fr/search?hl=fr&q=correspondance+privée+site%3Ajuriscom.net ), j'abandonne.
                  • [^] # Re: légal/illégal

                    Posté par  . Évalué à 2.

                    « commis de mauvaise foi »

                    La mauvaise foi est avérée si l'on sait pertinemment que le contenu, auquel on accède, relève d'une correspondance privée. Comment peut-on nier la chose lorsqu'on reçoit un message dont on n'est pas le destinataire et qui est indiqué comme transféré dans son titre...

                    « je n'ai personnellement trouvé que des décisions de justice sanctionnant une personne n'étant pas sensée lire les mail, et pas un destinataire qui divulgue une correspondance privée »

                    * Parce qu'il est matériellement plus simple de démontrer que quelqu'un est en possession de courriers personnels et privés d'autres personnes. (On tombe là sur la violation de correspondance privée).

                    * Parce que c'est plus rémunérateur (journaux condamnés).

                    * Et parce qu'il est plus difficile de faire condamner le destinataire du courrier fuité. Il est fréquent que le responsable soit plutôt une personne de l'entourage (et on retombe sur la violation de correspondance privée). Mais aussi parce que le destinataire responsable de la fuite peut toujours invoquer l'exception de la copie privée, même s'il communique avec un journaliste, face au non respect de la propriété du contenu du message.
          • [^] # Re: légal/illégal

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

            > Mais pourquoi diable le mec de TF1 viré à cause de son mail n'attaque-t-il pas sa député pour violation de la correspondance lui ayant couté son poste, vraiment?

            à cause de l'immunité parlementaire en France ? (à tort ou à raison)
            http://fr.wikipedia.org/wiki/Immunité_parlementaire_en_France
          • [^] # Re: légal/illégal

            Posté par  . Évalué à 1.

            Ah, j'ai une réponse logique : parce qu'elle était dans son droit (personne destinataire du mail).
            Moi j'ai une autre réponse, et qui est beaucoup plus logique et beaucoup moins "déliresque" que toi :
            parce qu'il a attaqué tf1, et non pas la député.
            C'est à la justice ensuite de dire :quels sont les responsabilité dans son licenciement (et si la député a bien une responsabilité en ne respectant pas la loi).

            bref, plutot que de partir dans des délires, basé sur des hypothèses fausses, il peut etre bon ton de se renseigner un minimum.
            • [^] # Re: légal/illégal

              Posté par  . Évalué à 1.

              Personne ne l'empêchait d'attaquer les deux pour deux motifs différents.

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

              • [^] # Re: légal/illégal

                Posté par  . Évalué à 2.

                Personne ne l'empêchait d'attaquer les deux pour deux motifs différents.
                Ca ma toujours fait marrer les gens qui estiment qu'attaquer quelqu'un ou quelque chose c'est super simple, ca pose aucun problème et puis un individu sans formation juridique, qui travaille, a aucun problème pour mener deux attaques de front en même temps....
                (et surtout, est totalement gratuit si il s'aide d'un avocat).

                T'en as d'autres des comme ça ?
                • [^] # Re: légal/illégal

                  Posté par  . Évalué à 2.

                  Ce que je voulais dire, c'est que s'il n'a pas attaqué la député, ce n'est pas parce que son procès avec son ancien employeur l'en empêchait (d'un point de vue juridique). Car c'est ce que je comprenait de ton commentaire.

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

                  • [^] # Re: légal/illégal

                    Posté par  . Évalué à 3.

                    ca n'empêche pas, mais ca peut faire doublon, et ca lui apporte pas grand chose.
                    Par contre si il souhaite _ensuite_ attaquer la député "voila, de la faute de la député, j'ai été licencié sans raison, _tel que la montré ce jugement_" .
                    Ca a un impact autrement plus fort, et donc d'un point de vu tactique est mieux.

                    Donc pour résumer
                    - Difficulté pour mener deux attaques de front
                    - Pas de gains avec l'attaque sur la député, contrairement avec celui sur tf1. Donc priorité à tf1
                    - Un jugement "postif" a tf1 aura une très bonne valeur pour montrer le préjudice qui lui a fait la député. Donc aucun intérêt à l'attaquer maintenant.
                    • [^] # Re: légal/illégal

                      Posté par  . Évalué à 2.

                      Mais je ne vois pas en quoi, comme tu le dis dans un commentaire plus haut:

                      C'est à la justice ensuite de dire :quels sont les responsabilité dans son licenciement (et si la député a bien une responsabilité en ne respectant pas la loi).

                      la justice va dire que la député n'a pas respecter la loi dans un procès qui ne concerne pas. (je ne pense pas que la manière dont celui qui a transmis l'information à TF1 entre en compte dans ce procès).

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

                      • [^] # Re: légal/illégal

                        Posté par  . Évalué à 3.

                        la justice va dire que la député n'a pas respecter la loi dans un procès qui ne concerne pas. (je ne pense pas que la manière dont celui qui a transmis l'information à TF1 entre en compte dans ce procès).
                        Je pense surtout que la justice va (peut etre) dire
                        - qu'elle a eu accés a des informations alors qu'elle n'aurait pas du y avoir accés (relevant de la vie privée).
                        - Qu'elle a utilisée ces informations contre les règles établies sur le licenciement.

                        Le point qui interesse le jugement de tf1 est bien entendu le 2em. Mais le premier permet de remonter sans problème sur "qui a fournis les informations".
                        Et une décision de justice est difficilement contestable ;)
                        • [^] # Re: légal/illégal

                          Posté par  . Évalué à 2.

                          - qu'elle a eu accés a des informations alors qu'elle n'aurait pas du y avoir accés (relevant de la vie privée).

                          Je ne sais pas si la justice se prononcera là-dessus car TF1 a obtenu ces informations par le ministre et c'est ce dernier qui n'aurait pas dû y avoir accès dans ce cas. De plus je ne sais pas si une cours qui juge un licenciement abusif est compétente pour juger cela.

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

                          • [^] # Re: légal/illégal

                            Posté par  . Évalué à 2.

                            Le fait que la ministre n'a pas le droit d'y avoir accés n'empêche en rien que tf1 non plus n'a pas le droit d'y avoir accés
                            (le ministère fait du recel (a récup des infos relevant de la vie privée), et de la diffusion de ces dernières, sans accord de la personne.

                            Petit apparté, on voit a quel point le ministère est attaché au droit et veut les faire respecter par hadopi...

                            )
                            • [^] # Re: légal/illégal

                              Posté par  . Évalué à 2.

                              Sauf que le ministre n'était pas censé savoir que la député n'avait pas l'accord pour diffuser ces informations.

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

                              • [^] # Re: légal/illégal

                                Posté par  . Évalué à 2.

                                Sauf que le ministre n'était pas censé savoir que la député n'avait pas l'accord pour diffuser ces informations.
                                A supposer. Cela ne l'autoriser toujours pas à diffuser.
                                Le(a) ministre a reçu en copie l'autorisation explicite pour transmettre ces infos ? Cette autorisation n'est pas présente sur le mail qu'elle a reçue.

                                De plus, l'email envoyé avec la copie contredit quelque peu la "bonne foi".
                                Pour mémoire
                                Bonjour Jean-Michel, vous avez des salariés qui, manifestement, aiment tirer contre leur camp. Cordialement
                    • [^] # Re: légal/illégal

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

                      Donc pour résumer
                      - Difficulté pour mener deux attaques de front
                      - Pas de gains avec l'attaque sur la député, contrairement avec celui sur tf1. Donc priorité à tf1
                      - Un jugement "postif" a tf1 aura une très bonne valeur pour montrer le préjudice qui lui a fait la député. Donc aucun intérêt à l'attaquer maintenant.


                      Ou alors plus simple : ce n'est pas illégal, et l'avocat lui a dit, donc il ne s'y aventure pas, il ne s'aventure même pas à dire aux médias à dire que c'était illégal et en violation de la correspondance privée (dans le cas de l'immunité parlementaire).

                      Ah? Ca doit être trop simple comme explication, donc faut en trouver une autre... Pourriez au moins dégoter un jugement si c'est si évidement, la correspondance privée est quand même un grand classique, ça serait étonnant qu'il n'y ai pas un seul jugement qui traine.

                      PS : j'ai cherché, et trouvé uniquement des dizaines de condamnations pour violation de correspondances privée par une personne externe à l'expéditeur/destinataire et une loi qui l'interdit aussi (toujours le même problème : mauvaise foi, interception...), rien quand le destinataire divulgue volontairement. J'ai pourtant pas mal cherché...
                      • [^] # Re: légal/illégal

                        Posté par  . Évalué à 0.

                        « PS : j'ai cherché, et trouvé uniquement des dizaines de condamnations pour violation de correspondances privée par une personne externe à l'expéditeur/destinataire et une loi qui l'interdit aussi (toujours le même problème : mauvaise foi, interception...), rien quand le destinataire divulgue volontairement. J'ai pourtant pas mal cherché... »

                        Parce que pour le destinataire du courrier c'est du domaine de l'atteinte à la vie privée la plupart du temps.

                        Tandis que pour celui qui publie, ce que lui a transmis le destinataire, c'est une violation de correspondance privée.
                      • [^] # Re: légal/illégal

                        Posté par  . Évalué à 0.

                        « Ou alors plus simple : ce n'est pas illégal, et l'avocat lui a dit, donc il ne s'y aventure pas, il ne s'aventure même pas à dire aux médias à dire que c'était illégal et en violation de la correspondance privée (dans le cas de l'immunité parlementaire). »

                        Ou alors l'avocat informe son client que les risques de perdre le procès sont trop importants, sachant que celui qui perd doit payer les frais du procès et d'avocat de la partie adverse. Et il faudrait en plus que la plainte soit enregistrée...
    • [^] # Re: Quelques commentaires

      Posté par  . Évalué à 1.

      A noter, pour répondre à une partie des critiques de Brad, que les mainteneurs des versions stables des noyaux se refusent à classer les corrections de bugs en fonction de critères de sécurité car pour eux il n'est pas possible de savoir à l'avance toutes les implications en matière de faille d'un bug donné.

      C'est absolument faux, c'est tout a fait possible, simplement ca demande du boulot et un peu de temps, ce qui ralentirait le developpement. Et oui, dans qqe cas il est possible de se tromper et mettre un bug en DoS plutot qu'EoP ou autre, mais c'est toujours mieux que ne pas le voir.
      • [^] # Re: Quelques commentaires

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

        >>> C'est absolument faux, c'est tout a fait possible, simplement ca demande du boulot et un peu de temps

        Cela a déjà été discuté as nauseam et manifestement les gens en charge des versions -stables du noyau ne sont pas du même avis que toi.
        • [^] # Re: Quelques commentaires

          Posté par  . Évalué à 3.

          Vu que je connais intimement une societe faisant un OS de masse ou cela se fait depuis un bon moment, je crois etre sur et certain de ce que je dis...
          • [^] # Re: Quelques commentaires

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

            Oh je ne doute pas que vous fassiez une distinction entre les bugs ayant des conséquences sur la sécurité et ceux n'en ayant à priori pas.
            Le problème c'est que tu ne peux pas savoir si ceux que tu a mis dans le seconde catégorie ne relèvent pas en fait de la première...alors pourquoi dépenser de précieuses ressources à faire cette distinction qui n'a pas vraiment d'utilité ? Est-ce que ce n'est pas plus logique de dire aux utilisateurs d'appliquer toutes les corrections au lieu d'essayer de jouer au plus malin et de faire du pick and choose sur les correctifs ?
            • [^] # Re: Quelques commentaires

              Posté par  . Évalué à 4.

              Le problème c'est que tu ne peux pas savoir si ceux que tu a mis dans le seconde catégorie ne relèvent pas en fait de la première...alors pourquoi dépenser de précieuses ressources à faire cette distinction qui n'a pas vraiment d'utilité ?

              C'est vrai, tu ne peux pas _garantir_ que tu ne te tromperas jamais. Mais cela ne veut pas dire que le taux de tri correct est bas, il est au contraire haut. Quand a l'utilite, c'est extremement utile, nottament car ca te permet de savoir si les versions precedentes ont une faille ou pas (on corrige un bug dans Vista, on voit que c'est un probleme de securite, on va jeter un oeil a XP, si c'est pas un bug de securite, on ne regarde pas XP) et la corriger dans la version precedente.
              Il est absolument irrealiste de demander aux gens de rester sur la derniere version du kernel pour des raisons de certification et autres, le backport de patchs de securite est donc une necessite.

              Est-ce que ce n'est pas plus logique de dire aux utilisateurs d'appliquer toutes les corrections au lieu d'essayer de jouer au plus malin et de faire du pick and choose sur les correctifs ?

              Justement non, parce que les utilisateurs ils vont devoir se taper un nombre de correctifs enorme alors qu'ils n'ont pas besoin de la plupart de ces correctifs la plupart du temps.

              Si tu jettes un oeil sur ce qu'on fait depuis qqe annees, nos patchs contiennent 2 branches : une pour les patchs critiques (securite et autres patchs particuliers qui sont tres importants) et une pour les patchs "normaux" qui contient tout

              Resultat, la grosse majorite des gens est sur la branche qui ne contient que les patchs critiques, et pas tout le bordel dont ils se fichent eperdument. Le jour ou ils auront besoin d'un patch pour un truc, ils changent de branche et c'est regle.
              • [^] # Re: Quelques commentaires

                Posté par  . Évalué à 7.

                Ce que tu dis est certainement valable pour les branches stables (quatrième composant dans le numéro de version pour le noyau linux, mises à jour des distributions, ...), où les patchs sont peu nombreux, déjà identifiés comme critiques (sans quoi ils ne sont pas rétro-portés dans les branches stables), et où les patchs sont sujet à une attention particulière, plutôt pour éviter des régressions par effet de bord que pour évaluer les conséquences en terme de sécurité (et c'est dommage puisqu'une bonne partie du travail est déjà faite).

                Mais est-ce applicable pour le lot commun des patchs concernant un OS ? Pour les trois que je connais, la tâche semble ardue : ce qui est reproché aujourd'hui à Linux l'est régulièrement à Microsoft. Et OpenBSD ne prétends par faire mieux : les devs anticipent la question en martelant : "nous préférons passer du temps à prévenir et corriger plein de choses qu'à évaluer la possibilité qu'un de nos patch répare une faille de sécurité" ; il leur arrive effectivement de découvrir avoir corrigé une faille longtemps après l'application d'un patch (par ex. sur leur version d'apache).

                Autrement dit, tout les fournisseurs OS sont régulièrement accusés de cacher intentionnellement la poussière sous le tapis ; et le fait que ça touche tout les OS permet justement de douter du qualificatif "intentionnellement".

                Détaillons le cas de la démarche dite "proactive" (= le principe de "mieux vaut prévenir que guérir") d'OpenBSD. L'équipe de développeur est assez réduite ; à chaque nouvelle faille, et à chaque découverte de paradigmes de programmation sécurisée, ils ont pour habitude de passer tout leur CVS (contenant un OS complet hein, pas seulement le noyau) à la moulinette du rechercher/remplacer. C'était le cas lorsqu'ils ont remplacé tout les srt[n]cat/cpy par des strlcat/cpy, la plupart des atoll/atoi par des strtonum, trouvé une méthodologie plus robuste pour prévenir les débordement d'entiers, activé tel ou tel warning supplémentaire du compilateur et corrigé tout ce qui bronche, etc. : un travail de titan, et des dizaines de milliers de patchs à chaque fois. Si, pour chacun de ces patchs, il avait fallu passer plusieurs heures à chercher s'il corrigeait une faille effective, ils n'auraient jamais pu mener ces chantiers à terme, loin s'en faut.

                Moralité : dans ce cas, l'effort de transparence (catégorisation des modifications appliquées dans les branches de développement de l'OS) est antithétique et préjudiciable à la sécurité effective du système. Tout simplement parce que les ressources humaines ne sont pas illimitées (peut-être qu'elle le sont chez Microsoft, mais ce n'est pas le cas pour les OS libres que je connais). Et si le "armchair security expert" était, justement, celui qui juge le résultat de haut et de loin, sans mettre les mains dans le cambouis ?
            • [^] # Re: Quelques commentaires

              Posté par  . Évalué à 2.

              >alors pourquoi dépenser de précieuses ressources à faire cette distinction qui n'a pas vraiment d'utilité ?

              Pas vraiment d'utilite, tu exageres la: la prise en compte d'un patch a un cout pour les utilisateurs (installation, temps de reboot, test de la nouvelle version, etc) donc si le fournisseur de l'OS diminue le nombre de changement a prendre en compte, cela a vraiment une utilite pour l'utilisateur!
          • [^] # Re: Quelques commentaires

            Posté par  . Évalué à 3.

            tu réfutes formellement ce "il n'est pas possible de savoir à l'avance toutes les implications en matière de faille d'un bug donné." ?
            • [^] # Re: Quelques commentaires

              Posté par  . Évalué à 4.

              Non, je dis que dans la tres grande majorite des cas, on peut savoir si le bug corrige est une faille ou pas, et que le savoir dans la tres grande majorite des cas est bcp plus utile que ne jamais le savoir.
  • # Sus à l'anglois !

    Posté par  . Évalué à 7.

    « Seule la version 2.6.30 du noyau est impactée. »

    Impacter n'est pas français ; on dit « affecter » !

    (Cette dépêche contient d'autres anglicismes, mais celui-là me déplaît particulièrement.)
    • [^] # Re: Sus à l'anglois !

      Posté par  . Évalué à 3.

      Entre l'anglicisme et le latinisme, seule importe la justesse du mot français.

      Méditons ensemble ce proverbe chinois « Quand le sage montre la Lune, l'imbécile regarde le doigt. »
    • [^] # Re: Sus à l'anglois !

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

      Même si ça ne te plait pas, une langue vivante... Vit.
      Et c'est à double sens (pleins de mots français sont utilisés en anglais et en allemand, et en bonus avec l'accent français, rigolo :) ).

      Une langue s'alimente des autres langues, évolue, se transforme, et c'est ce qui fait son charme.
      D'autres diront que, horreur, "Week-end" est dans le Larousse (http://www.larousse.fr/dictionnaires/francais/Week-end ), vade retro satanas, mais la majorité continueront à faire vivre la langue.
      On a bien "impact" (http://www.larousse.fr/dictionnaires/francais/Impact ) dans le Larousse, ça me parait assez naturel de prendre "impacter". Ca rentrera un jour dans les dicos, faudra t'y faire.

      Sur ce, bon Week-end ;-)
      • [^] # Re: Sus à l'anglois !

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

        Impacter ne me choque pas, mais je ne suis pas forcément pour de l'anglicisme outre mesure.

        On en arrive à voir des gens incapable de s'exprimer avec des mots de leur langue maternelle alors même qu'il existe déjà un équivalent, et même, c'est là que ça deviens vraiment n'importe quoi, des gens qui connaissent les mots dans leur langue natale mais ne savent même pas que le mot étranger est son stricte équivalent.

        Par exemple, sur linuxfr j'avais vu un bonhomme qui ne savais pas traduire backup, et dans le même file de discussion, on me disait que «en amont» traduisait mal «upstream».

        https://linuxfr.org//comments/982038.html#982038

        Le problème que cela soulève n'est pas tant la racine des mots que la compréhension des mots qu'on emploi.
        • [^] # Re: Sus à l'anglois !

          Posté par  . Évalué à 5.

          « Nouveau Petit Robert de la langue française 2007 » :
               Impacter (v. tr.)   Avoir un impact, une incidence sur, toucher.
                        ex. Les charges ont fortement impacté le résultat.
          • [^] # Re: Sus à l'anglois !

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

            Oui et donc ? J'ai dit que impacter ne me choquais pas pour ma part…
            • [^] # Re: Sus à l'anglois !

              Posté par  . Évalué à 2.

              Et donc ce verbe français ne devrait point choquer qui que ce soit.
          • [^] # Re: Sus à l'anglois !

            Posté par  . Évalué à 4.

            Ce mot n'apparaît pas dans le dictionnaire de l'Académie française.
            De même pour "les fondamentaux de l'enseignement" : fondamental est un adjectif, pas un nom.
            Ce n'est pas parce que 1000 personnes pensent la même connerie que ce n'est pas une connerie...
            • [^] # Re: Sus à l'anglois !

              Posté par  . Évalué à 2.

              Le sarkozysme ça n'est sûrement pas dans le dictionnaire de l'académie française. Pour autant, à le sentir passer, je défie quiconque de me dire que ce n'est pas français et que ça n'existe pas.
            • [^] # Re: Sus à l'anglois !

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

              Pas le verbe, mais l'utilisation abusive d'impact dans la neuvième édition :

              C'est par une extension abusive qu'on emploie Impact en parlant d'une influence diffuse ou générale.
      • [^] # Re: Sus à l'anglois !

        Posté par  . Évalué à 4.

        « Une langue s'alimente des autres langues, évolue, se transforme, et c'est ce qui fait son charme. »

        Quand toutes les langues seront inondées d'anglais et se ressembleront, je ne sais pas où sera leur charme...

        Une langue vit et importe des mots d'autres langues : oui bien sûr, mais autant certains imports se justifient en ce qu'ils viennent remplir un vide dans notre langue, autant d'autres font doublon avec un terme déjà existant et finissent parfois par le supplanter. Bref, je partage essentiellement le point de vue exprimé plus haut par Mathieu Stumpf, si ce n'est que, justement, impacter me choque dans la mesure où il existe un équivalent en français. C'est nous qui faisons vivre la langue, elle évolue dans la direction où on la mène.

        Croux, désolé, j'en suis encore au Petit Robert 1992. (Il y a quand même écrit « nouveau » dessus !) Impacter n'est pas dedans.

        En fait, je crois qu'il y a une autre raison pour laquelle, personnellement, le mot « impacter » ne me plaît pas beaucoup quand je le lis dans les médias : l'image d'un impact lui donne peut-être un coté un peu spectaculaire par rapport au classique « affecter », et je n'aime pas trop la surenchère médiatique dans le spectaculaire.
        • [^] # Re: Sus à l'anglois !

          Posté par  . Évalué à 0.

          « Croux, désolé, j'en suis encore au Petit Robert 1992. (Il y a quand même écrit « nouveau » dessus !) Impacter n'est pas dedans. »

          1992 ! A cette époque là internet et les emails n'existaient sans doute pas pour le Petit Robert...
          • [^] # Re: Sus à l'anglois !

            Posté par  . Évalué à -2.

            Et on ne dit pas « email », on dit « courriel ». Comme ça au moins, l'écriture correspond à la prononciation !
            • [^] # Re: Sus à l'anglois !

              Posté par  . Évalué à 2.

              Ce n'est pas dans ce sens là que j'ai utilisé le mot « email ». Je voulais parler de l'adresse mél.
              Au fait « courriel » ne serait-il pas un québécisme ?
              • [^] # Re: Sus à l'anglois !

                Posté par  . Évalué à 2.

                Au fait « courriel » ne serait-il pas un québécisme ?

                Il me semble que le mot vient du Québec mais qu'il est actuellement recommandé par l'Académie Française.

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

  • # Il me manque une piece du puzzle

    Posté par  . Évalué à 1.

    Qui saurait expliquer comment une affectation de variable se transforme en appel de code arbitraire?

    (desole pour l'absence d'accent)
    • [^] # Re: Il me manque une piece du puzzle

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

      Les joies du C -> []
    • [^] # Re: Il me manque une piece du puzzle

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

      Un objet "tun" utilise la structure tun_fops (de type "struct file_operations") qui contient des callbacks vers les fonctions appelées lors des différentes opérations sur le fichier /dev/net/tun. L'exploit utilise l'opération "mmap" sur le fichier tun. Si j'ai bien compris, l'idée est d'écraser tun_fops->mmap pour le faire pointer vers une fonction située à l'adresse 1. À cet adresse, l'exploit écrit le code machine de l'instruction "CALL <own_the_kernel>". Enfin, la fonction own_the_kernel change l'utilisateur du processus (pour passer root).

      L'exploit est assez compliqué, alors je suis pas sûr de ce que je raconte. Mais bon, ça te donnera une meilleure idée de ce qui se passe.
    • [^] # Re: Il me manque une piece du puzzle

      Posté par  . Évalué à 7.

      En regardant l'extrait de code, j'ai l'impression que ce n'est pas l'affectation qui provoque l'exploit.
      C'est l'optimisation de gcc qui supprime la vérification if (!tun) return POLLERR;

      Du coup, derrière, au lieu de sortir de la fonction, on se retrouve avec sk qui pointe vers l'adresse 0 + offsetof(tun, sk).

      Et là, c'est le drame. Par exemple, si le socket et supprimé, c'est sk->sk_destruct(sk) qui est appelé, et donc si tu as mis la fonction qui va bien à l'adresse 0 + offsetof(tun, sk) + offsetof(sk, sk_destruct), tu deviens calife à la place du calife...
      • [^] # Re: Il me manque une piece du puzzle

        Posté par  . Évalué à 6.

        Je suis pas en forme moi...
        Dans mon exemple, sk est un pointeur, situé à l'adresse offsetof(tun, sk).
        Donc, si sk->sk_destruct(sk) est appelé, le code appelé est situé à l'adresse pointée par sk, plus offsetof(sk, sk_destruct).

        Mais ce n'est qu'un exemple...
        Ce qui est marrant c'est que c'est optimisation de gcc qui permet au code d'être exécuté, au lieu de faire un oops.
  • # Je ne comprends pas

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

    Je ne connais pas assez pour juger mais quand je lis la news j'ai l'impression qu'on me dit "le code est bon n théorie mais le compilateur fait une optimisation foireuse qui créé la faille de sécurité".

    Il me parait très sain de dire que le kernel en question a un problème et de palier ce problème, mais ce n'est pas surtout le compilateur qui dans ce cas a un énorme bug ? Un compilo qui ajoute des failles de sécurités c'est surtout ça qui me parait dangereux et qui est à corriger. Ce n'est pas vraiment aux développeurs de prévoir et contourner les optimisations foireuses du compilo.

    Or je vois des annonces à propos du kernel mais pas à propos d'une correction critique de gcc. J'ai mal compris un truc ?
    • [^] # Re: Je ne comprends pas

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

      Tu as mal compris.
      Le compilo a viré du code car le code en question est sensé ne jamais être utilisé (le pointeur est utilisé la ligne d'avant, donc ne peut pas être à NULL).

      Le compilo a fait son boulot en virant du code inutile, juste "trop bien" alors qu'il y avait un bug (test fait trop tard), et c'est le bug qui rend le code inutile donc viré.

      Le compilo a fait ce qu'on lui a demandé, sauf que la demande était bugguée (faire le test avant), une fois la demande corrigée le compilo fait correctement son boulot.

      Le compilo n'a juste pas la fonctionnalité de correction des bugs dans la demande humaine.
      • [^] # Re: Je ne comprends pas

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

        ok, je comprends mieux, merci
      • [^] # Re: Je ne comprends pas

        Posté par  . Évalué à 2.

        Ben moi je n'ai pas compris :-)

        Si le compilateur n'avait pas "fait son boulot" alors l'exploitation de la faille ne serait pas possible (si j'ai bien compris). Par exemple un autre compilateur n'aurait pas engendré le problème. Donc le compilateur modifie le comportement du programme.

        Dans mon esprit simplet, un compilateur qui modifie le comportement d'un programme, ça se nomme nomme bug.
        • [^] # Re: Je ne comprends pas

          Posté par  . Évalué à 6.

          Dans mon esprit simplet, un compilateur qui modifie le comportement d'un programme, ça se nomme nomme bug.

          Il ne modifie pas le comportement du programme, dans le sens où du point de vue formel, il n'a rien fait d'illégal. Voici un autre exemple, plus simple :

          void dummy(double *array, size_t len) {
          double acc = 0.0;
          for (int i = 0; i < len; ++i)
          __acc += array[i];
          }


          Un bon compilateur, qui optimise bien, va tout simplement supprimer la boucle (et avec l'inlining, il ne subsistera plus rien du code original). Un mec qui voudrait (par exemple) utiliser dummy() pour flusher arbitrairement la mémoire cache ne pourrait plus le faire.

          Autre exemple : memset fait partie des fonctions standard du C. À ce titre, elle est donc « magique », et le compilateur peut faire un peu ce qu'il veut avec du moment que ça ne viole pas les contraintes du programme. Si par exemple je tape un code du genre (piqué à Marc Espie sur fclc)
          void f() {
          char passwd[250];
          // code qui demande un mot de passe a l'utilisateur.
          // code qui s'en sert
          memset(passwd, 0, sizeof passwd);
          }

          Ben là, le compilateur peut dire « hé mais de toute manière, passwd est local à la fonction, donc faire un memset dessus ça prend du temps et des ressources pour rien ». Et paf, il le vire. Sauf qu'en fait, le memset était là pour éviter qu'un petit malin essaie ensuite de lire dans la zone mémoire où passwd est alloué (par exemple pour lire une ancienne valeur de passwd). Du point de vue du « sens » du programme, tout est respecté. Du point de vue sécurité, c'est une « catastrophe ».
          • [^] # Re: Je ne comprends pas

            Posté par  . Évalué à 2.

            Et pourquoi dans des cas aussi simples ne pas faire de warning pour avertir, sans optimiser? Est-ce car les cas réels ne sont pas aussi simples?
            • [^] # Re: Je ne comprends pas

              Posté par  . Évalué à 3.

              Et pourquoi dans des cas aussi simples ne pas faire de warning pour avertir, sans optimiser?

              Parce que la plupart du temps le compilateur a raison de supprimer le code. Sauf quand il a tort. Il ne va pas faire un warning pour chaque boucle simple qu'il optimise, sinon on est pas rendu (mais on peut lui dire de générer un rapport si on veut savoir ce qu'il a fait ...). Dans le cas de la fonction qui agit sur un mot de passe, je dirais que 9 fois sur 10, le memset est réellement inutile car il ne s'agit pas de code ni de données sensibles.

              Est-ce car les cas réels ne sont pas aussi simples?
              Je me sers d'une boucle à peine plus compliquée que la première donnée pour faire des micro-benchmarks (j'accumule dans une variable acc que j'affecte ensuite à un pointeur pacc pour empêcher le compilateur de supprimer le code).

              Concernant le deuxième exemple, je l'ai emprunté à Marc Espie, qui s'en servait sur fr.comp.lang.c pour donner un exemple de suppression automagique (car memset est une fonction standard, donc le compilateur « sait » comment elle fonctionne, quand il peut se permettre de la virer, etc.) de code de la part de gcc. C'est un « vrai » code dans le sens où je pense qu'il est légitime de vouloir nettoyer la mémoire quand on est un peu obsédé niveau sécurité.

              Dans la vraie vie, avec des codes réels, il y a plein de cas où le compilateur supprime avec raison tout un tas de trucs en se disant « au final c'est pareil ». Sauf quand c'est pas vrai.
        • [^] # Re: Je ne comprends pas

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

          Dans mon esprit simplet, un compilateur qui modifie le comportement d'un programme, ça se nomme nomme bug.
          Ça s'appelle de l'optimisation, dans le cas contraire il suffit de compiler le noyau en -O0 et tu es sûr qu'il ne supprimera pas le test (et accepter les conséquences au niveau des performances). Autrement faut chercher quel flag de GCC effectue ce type d'optimisation dans son manpage monstrueux.
          • [^] # Re: Je ne comprends pas

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

            Voici le flag:


            -fdelete-null-pointer-checks
            Use global dataflow analysis to identify and eliminate useless checks for null pointers. The compiler assumes that dereferencing a null pointer would have halted the program. If a pointer is checked after it has already been dereferenced, it cannot be null.

            In some environments, this assumption is not true, and programs can safely dereference null pointers. Use -fno-delete-null-pointer-checks to disable this optimization for programs which depend on that behavior.

            Enabled at levels -O2, -O3, -Os.
        • [^] # Re: Je ne comprends pas

          Posté par  . Évalué à 3.

          Une des lecons importante de l'informatique c'est GIGO: 'garbage in -> garbage out'.
          Soit quand tu rentres des informations erronees en entree, tu auras un resultat errone en sortie.
          Dans ce cas present le programme C etait errone (avait un bug), ce bug etait expose ou non suivant l'implementation du compilateur, le probleme ne vient donc pas du compilateur mais du programme.
      • [^] # Re: Je ne comprends pas

        Posté par  . Évalué à 1.

        Le compilo a fait son boulot en virant du code inutile,

        Et il me semble bien que ce n'est pas la première fois que ça cause un problêème; de mémoire, il y a quelques mois/années, c'était un memset à 0 «optimisé», laissant ainsi des données sensibles sur la pile en sortie de fonction...
    • [^] # Re: Je ne comprends pas

      Posté par  . Évalué à 2.

      En fait, le problème de base c'est que le code est buggé. Ce n'est pas vraiment un problème d'optimisation.
      Déréférencer un pointeur NULL est une "undefined behavior", autrement dit l'implémentation est libre de faire _ce qu'elle veut_. Crasher, générer du code foireux, imprimer "42", etc.
      Définition de "undefined behavior" :

      behavior, upon use of a nonportable or erroneous program construct, of erroneous data, or of indeterminately valued objects, for which this International Standard imposes no requirements
      NOTE Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message).


      En l'occurrence, gcc supprime le test puisqu'il "suppose" que le programme aura crashé.
      C'est un choix comme un autre, par contre je ne comprends pas pourquoi il ne lève pas un warning à la compilation, s'il _pense_ que le code va crasher...
      • [^] # Re: Je ne comprends pas

        Posté par  . Évalué à 1.

        gcc supprime le test parce que ayant vu le code precedent ou la variable est dereferencee, il se dit que la valeur ne sera jamais NULL, et que donc le test ne sert a rien.
        • [^] # Re: Je ne comprends pas

          Posté par  . Évalué à 1.

          Et donc il estime qu'il est plus probable que le programmeur ait pris la peine de tester qu'un pointeur n'est pas NULL par erreur, plutôt que l'inverse, à savoir que le pointeur ait été déréférencé par erreur avant d'être testé non NULL ?
          Je suis curieux de voir un exemple de telle utilisation volontaire...
          Je dirais que dans 99% des cas, un tel code est très très douteux, le choix fait par gcc me paraît foireux...
          • [^] # Re: Je ne comprends pas

            Posté par  . Évalué à 2.

            Et donc il estime qu'il est plus probable que le programmeur ait pris la peine de tester qu'un pointeur n'est pas NULL par erreur, plutôt que l'inverse, à savoir que le pointeur ait été déréférencé par erreur avant d'être testé non NULL ?

            Si la valeur est nulle, la variable a ete dereferencee avant, donc le test ne s'executera jamais vu que le systeme crashera avant.

            Ce test est dans tous les cas inutile et gcc a tout a fait raison de l'enlever.

            gcc ne peut pas non plus savoir si la variable est potentiellement nulle ou pas, et il ne peut pas mettre un warning a chaque cas ou il n'est pas sur, sinon tu aurais 35222 warnings a chaque compilation.
            • [^] # Re: Je ne comprends pas

              Posté par  . Évalué à 4.

              Justement, il peut le savoir, puisque le programmeur compare explicitement le pointeur à NULL !
              C'est la toute la différence...
          • [^] # Re: Je ne comprends pas

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

            Ce n'est pas un choix de GCC car le flag est passé explicitement quand tu utilises -O2 -O3 ou -Os. GCC estime donc rien du tout, il fait ce qu'on lui demande.

            Néanmoins, ce problème est peut être une bonne occasion d'ajouter un flag d'avertissement (actif également avec -Wall ?) si GCC applique cette optimisation?!
            Bien que dès le moment qu'on la lui demande directement il n'y a pas vraiment de raison de créer un warning. Quand on passe des flags à GCC on est sensé savoir ce qu'on fait et accepter les conséquences.
  • # L'avis de Mingo

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

    Un excellent commentaire d'Ingo Molnar à propos de la chronologie de cet exploit et surtout à propos de la personnalité (tordue) de Brad et des créateurs d'exploits.
    Vraiment très intéressant à lire :

    http://lwn.net/Articles/342163/
    • [^] # Re: L'avis de Mingo

      Posté par  . Évalué à 0.

      Perso quand je lis ca, ca me dit un truc : Ingo Molnar est un gros con.

      Sa maniere de decrire les chercheurs en securite est honteuse et montre qu'il n'y connait foutrement rien, c'est le moins qu'on puisse dire.
  • # SELinux

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

    Il a l'air de dire que SELinux c'est pourri mais son exploit ne marche que parseque il est executé en contexte unconfined_t, ce qui n'arriverais pas si SELinux était "vraiment" utlisé (aka utilisateur en user_t, pulseaudio en pulseaudio_t etc... )
    (information confirmé sur #selinux)

    PS: unconfined_t ca veux dire "pas confiné par SELinux", pour ceux qui n'en ont jamais fait.


    UPDATE: not just that, SELinux lets any user in unconfined_t map at
    0, overriding the mmap_min_addr restriction! pulseaudio is not
    needed at all! Having SELinux enabled actually *WEAKENS* system
    security for these kinds of exploits!

  • # Coccinnelle

    Posté par  . Évalué à 1.

    Un seul n à coccinelle (et non "coccinnelle")
  • # TUN

    Posté par  . Évalué à -3.

    Bin j'ai un 2.6.30 mais j'ai pas tun de monté... en fait même pas compilé.
    D'ailleurs pour le monter, il faut un programme SUID root genre pulseaudio (d'ailleurs à quand un mixer en C pour lui, qui ne descent pas tout gnome?)
    Et puis il faut rappeler qu'aucun système n'est sûr. Certains sont justes de notoriété plus sûrs, c tout. Donc à partir de là autant privilégier des systèmes (A)GPL pour favoriser la publication de code correctifs de failles.

Suivre le flux des commentaires

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