Root exploit sur les noyaux linux 2.6.38 à 3.8.8

Posté par  . Édité par Nÿco, rootix et Benoît Sibaud. Modéré par patrick_g. Licence CC By‑SA.
44
17
mai
2013
Noyau

Un nouveau root exploit est apparu mardi et concerne les noyaux Linux de 2.6.38 à 3.8.8 ayant CONFIG_PERF_EVENTS activé.

Tapez la commande suivante pour savoir si vous êtes impacté :
zgrep CONFIG_PERF_EVENTS /proc/config.gz

Si zgrep répond cette ligne, vous êtes impacté.
CONFIG_PERF_EVENTS=y

Le patch existe depuis plusieurs semaines mais n'a pas été forcement intégré dans toutes les distributions - cherchez le code CVE-2013-2094 dans les derniers security advisory.

La Debian Wheezy a été patchée ce matin (je mets le lien vers le mail de la liste de diffusion « security » car je ne trouve pas l'annonce de sécurité debian sur le site).

Pour ceux qui ne peuvent pas patcher immédiatement leur noyau, il faut suivre le lien vers l'outil de suivi de bug de redhat qui propose plusieurs solutions temporaires plus ou moins efficaces.

Aller plus loin

  • # /boot/config-* ?

    Posté par  . Évalué à 7.

    Ne serait-ce pas plutôt

    zgrep CONFIG_PERF_EVENTS /boot/config-*
    
    

    Au moins pour Debian.

    • [^] # Re: /boot/config-* ?

      Posté par  . Évalué à -2.

      L'annonce de Debian avec le correctif est datée du 15 avec 17 autres alertes sur le noyau. Relativement banal pour un système très vigilant sur la sécurité ?

      Je ne sais pas pourquoi la old-stable n'est pas corrigée en même temps. Ce n'est pas habituel.

      • [^] # Re: /boot/config-* ?

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

        Parce que c'est un noyau 2.6.32 (donc pas impacté) par défaut sur debian squeeze…

        • [^] # Re: /boot/config-* ?

          Posté par  . Évalué à 0.

          Parce que c'est un noyau 2.6.32 (donc pas impacté) par défaut sur debian squeeze…

          Si par les backports qui sont aujourd'hui en 3.2+46 comme Wheezy, mais je n'avais pas vu qu'ils avaient été corrigés, désolé.

    • [^] # Re: /boot/config-* ?

      Posté par  . Évalué à -1.

      • [^] # Re: /boot/config-* ?

        Posté par  . Évalué à 6.

        L'option CONFIG_IKCONFIG_PROC n'est pas activée sous Debian. donc pas de /proc/config.gz.

  • # HAHA

    Posté par  . Évalué à -10.

    Mon serveur sous Arch Linux est sous Linux 3.9 depuis au moins une semaine.

    Écrit en Bépo selon l’orthographe de 1990

    • [^] # Re: HAHA

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

      Stop aux "Ha Ha" : Le mec qui a écrit l'exploit connaissait le bug depuis au moins deux ans.

      • [^] # Re: HAHA

        Posté par  . Évalué à 5.

        C'est ce que je trouve de navrant, il aurait pus le signaler pour faire corriger le bug.

        Merci aux personnes qui mon aidé a trouvé des solutions pour essayer d’écrire sans faute d’orthographe.

        • [^] # Re: HAHA

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

          Visiblement le mec est un black hat qui vend ses trouvailles à qui veut bien les acheter.
          Il ne dévoile la faille en ouvrant un CVE et en publiant un exploit que lorsque le trou est corrigé sur un dépôt Git.

          Voir le mail ce petit salopard ici : http://article.gmane.org/gmane.comp.security.oss.general/10189

          • [^] # Re: HAHA

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

            Je pense qu'on est en train de détourner la responsabilité de ce mini scandale. Le "salopard" en question ne fait que suivre ce qui est standard dans l'industrie de la sécurité, c'est à dire découvrir des bugs, coder l'exploit pour soi et attendre que ça tombe ailleurs. (Je connais personnellement des dizaines de personnes qui le font, moi y compris)
            Par contre personne ici pour critiquer les deux raisons principales de la publicité de cet exploit:
            1- il y a eu un bug qui permet d'obtenir un local root dans un premier temps
            2- Lorsqu'un développeur a trouvé le bug (une écriture en dehors du buffer !!) ils ont corrigé le bug sans même créer un CVE, sans mettre le fix en quarantaine ni suivre la moindre procédure de backporting du patch. Ces personnes sont les véritables irresponsables, car un bug de sécurité a été publié dans la nature sans que le patch ne soit prêt à être déployé.

            Rapporter la responsabilité de l'absence de CVE et publication de l'exploit à sd est de la mauvaise foi. La véritable responsabilité, c'est l'attitude totalement autruchienne de l'équipe de dev de linux par rapport aux bugs de sécurité. Et je suis convaincu que ce n'est pas le premier bug de sécurité publié ouvertement dans le git sans qu'il y ait le moindre CVE et backporté dans aucune distribution majeure.

            • [^] # Re: HAHA

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

              Le "salopard" en question ne fait que suivre ce qui est standard dans l'industrie de la sécurité, c'est à dire découvrir des bugs, coder l'exploit pour soi et attendre que ça tombe ailleurs. (Je connais personnellement des dizaines de personnes qui le font, moi y compris)

              Ce genre de personne que tu décris est bien un salopard, pas besoin de mettre des guillemets.
              Et non, ce n'est pas standard dans l'industrie de la sécurité, il y en a pas mal qui découvrent des bugs, codent l'exploit pour démontrer aux autres qu'il y a un réel problème, démonstration soit privée (responsible disclosure, la personne attend le patch puis se fais la pub, si ça tarde trop hop en public pour forcer le patch), soit en public lors des meeting de sécurité, et parfois empochent quelques milliers de $ en remerciement, soit un bon gros plaisir sadique de faire du 0-day (irresponsible disclosure).

              2- Lorsqu'un développeur a trouvé le bug (une écriture en dehors du buffer !!) ils ont corrigé le bug sans même créer un CVE

              Le développeur ne savait peut-être pas que ça posait un problème utilisable de sécurité. Si il faut faire un CVE pour chaque patch…

              Ces personnes sont les véritables irresponsables, car un bug de sécurité a été publié dans la nature sans que le patch ne soit prêt à être déployé.

              C'est à ma connaissance la politique de Linus depuis le début, ton irresponsable a quand même un CV en béton.
              Libre à toi de critiquer cette façon de faire, libre à eux de considérer que l'industrie s’accommode très bien de cette façon de faire et de t'envoyer chier. Il te reste à démontrer que ta façon de faire est viable et meilleure. Eux démontrent, pas toi.

              Et je suis convaincu que ce n'est pas le premier bug de sécurité publié ouvertement dans le git sans qu'il y ait le moindre CVE et backporté dans aucune distribution majeure.

              Tant que ce n'est pas exploité, ça ne pose aucun problème. Sans compter que la plupart du temps, c'est non exploitable.

              • [^] # Re: HAHA

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

                Ce genre de personne que tu décris est bien un salopard, pas besoin de mettre des guillemets.
                Et non, ce n'est pas standard dans l'industrie de la sécurité, il y en a pas mal qui découvrent des bugs, codent l'exploit pour démontrer aux autres qu'il y a un réel problème, démonstration soit privée (responsible disclosure, la personne attend le patch puis se fais la pub, si ça tarde trop hop en public pour forcer le patch), soit en public lors des meeting de sécurité, et parfois empochent quelques milliers de $ en remerciement, soit un bon gros plaisir sadique de faire du 0-day (irresponsible disclosure).

                Désolé de te contredire, le standard dans l'industrie c'est de garder les résultats de recherches privés. sd n'a rien fait de mal en gardant pour lui ses résultats. Il n'a rien publié avant que ce soit connu, il ne s'est même pas plaint que ce soit devenu public. Il n'a rien fait d'irresponsable.
                Au contraire, les devs qui ont publié les patches sans faire de review de sécurité sur le bug qu'ils avaient trouvé ont publié un bug de sécurité selon ta vision de l'irresponsible disclosure.

                Le développeur ne savait peut-être pas que ça posait un problème utilisable de sécurité. Si il faut faire un CVE pour chaque patch…

                C'est un problème de processus. Sur les gros projets (et les petits aussi), chaque bug qui est trouvé et dont on soupçonne des répercussions au niveau de la sécurité doit être analysé par une équipe compétente. Mon petit projet y arrive, pourquoi linux n'y arrive pas ? Parce qu'il n'y a pas d'équipe de sécurité.

                C'est à ma connaissance la politique de Linus depuis le début, ton irresponsable a quand même un CV en béton.

                Donc d'après toi, puisque monsieur Linus a un meilleur pédigrée que moi, il a toujours raison. Ton argument d'autorité, tu peux le garder. Et bien non, en terme de sécurité, la vision de Linus (Un bug de sécurité = un bug) est totalement irresponsable. Il se moque totalement de l'impact des bugs de linux au niveau de la sécurité et compte sur les autres pour tenter de regarder le backlog et trouver ce qui est urgent à backporter et ce qui ne l'est pas. Linus le dit lui même, la sécurité de Linux c'est pas son problème. Je refuse de prendre des conseils en sécurité de cette personne.
                Et ce n'est pas juste moi qui le dit, mais Spender (le mec de grsecurity qui s'y connait "un peu" en sécurité linux) [1] premier hit sur "spender linus security"

                Tant que ce n'est pas exploité, ça ne pose aucun problème. Sans compter que la plupart du temps, c'est non exploitable.

                Ce type d'excuse est irresponsable. Tu crois que parce qu'un problème est caché sous le paillasson, il n'existe pas ? Il y a des gens qui passent leur temps à inspecter les commits linux à la recherche de bugs exploitables et crois-moi, ils ne réagissent pas comme sd lorsqu'ils trouvent quelque chose. Tant que ce travail ne sera pas fait de manière systématique par l'équipe sécurité de Linux, on aura ce genre de problèmes de manière récurrente.

                [1] http://www.reddit.com/r/netsec/comments/18qab0/spender_grsecurity_author_linux_approach_to/ https://lwn.net/Articles/538600/

                • [^] # Re: HAHA

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

                  Désolé de te contredire, le standard dans l'industrie c'est de garder les résultats de recherches privés. sd n'a rien fait de mal en gardant pour lui ses résultats. Il n'a rien publié avant que ce soit connu, il ne s'est même pas plaint que ce soit devenu public. Il n'a rien fait d'irresponsable.

                  Garder secret ce type de chose pour un bénéfice personnel et malsain c'est selon moi irresponsable. Même si c'est un standard ou pas sa procédure, cela n’enlève pas qu'il aurait pu le publier pour que tout le monde s'en sorte grandi…

                • [^] # Re: HAHA

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

                  sd n'a rien fait de mal en gardant pour lui ses résultats. Il n'a rien publié avant que ce soit connu, il ne s'est même pas plaint que ce soit devenu public. Il n'a rien fait d'irresponsable.

                  Tu arrives à rester sérieux en écrivant ça?
                  Bon, il sait que ça va exploser un jour, il a de quoi empécher l'explosion, mais il laisse exploser, c'est responsable de ton point de vue, le mec est un salopard du mien.

                  Ton argument d'autorité, tu peux le garder

                  Relit, je ne parles pas d'autorité, rien à faire de l'autorité.
                  Je dis simplement que les autres ont l'air de très bien vivre avec ça, et que personne n'arrive à proposer "mieux".
                  Je ne parle pas d'autorité, je dis juste que ça marche. Ensuite, libre (c'est beau le libre) à d'autres de te proposer une review de sécurité si ça vaut le coup.

                  le mec de grsecurity qui s'y connait "un peu" en sécurité linux

                  Tu es au courant qu'il y a un très faible nombre de gens qui utilisent grsecurity? Il faut croire que la vision de Spender n'attire pas plus foule que ça.

                  L'avantage du libre, c'est que tu peux, toi, proposer ta vision sans problèmes. Faut juste que les autres suivent. grsecurity est un très bon exemple, ses patchs sont jugés foireux, rejetés de la branche principale, et il est bloqué à Linux 3.4.4, ça manque un peu de réactivité…

                  Libre à toi d'avoir une autre politique de sécurité, chacun sa liberté et sa politique de sécurité (vive le libre), mais désolé, je n'accepte pas qu'on balance que ce comportement de salopard (pour reprend ton mot qui a bien sans les guillemets) est ce qu'on peut appeler, même de loin, responsable. c'est au mieux du je m'en foutiste, mais ici ce n'est pas le cas puisque la personne a codé une démo pour se faire mousser, donc la c'est l’irresponsabilité complète et/ou le plaisir de nuire.

                  • [^] # Re: HAHA

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

                    Se boucher les oreilles et crier lalalala n'est pas un argument valide. La politique de sécurité de linux est puante et ce n'est pas parce que l'équipe de dev de linux se complait dans leur médiocrité que c'est comme ça que ça doit fonctionner.

                    • [^] # Re: HAHA

                      Posté par  (site web personnel) . Évalué à 1. Dernière modification le 19 mai 2013 à 11:30.

                      Se boucher les oreilles et crier lalalala n'est pas un argument valide.

                      Tu parles de toi?

                      La politique de sécurité de linux est puante

                      Ce n'est pas parce qu'elle ne te plait pas qu'elle est puante. C'est un choix. Qui a l'air de plaire.

                      La politique de sécurité de linux est puante et ce n'est pas parce que l'équipe de dev de linux se complait dans leur médiocrité que c'est comme ça que ça doit fonctionner.

                      Je t'en prie, propose mieux. En vrai, hein, pas en lalalala, pour démontrer qu'il est possible de mieux faire (en plus, tu dis toi-même que les "méchants" scannent les logs GIT, donc ça doit être aussi possible pour les "gentils").
                      Perso, je constate juste que Linux est sur tous les serveurs ou presque non pas parce que les commerciaux sont doués, mais parce qu'il répond au besoin technique (sécurité comprise, faut voir comparé à d'autres OS).

                      se complait dans leur médiocrité que c'est comme ça que ça doit fonctionner.

                      Je reprend ce bout de phrase, mais l'utilise pour ton "(Je connais personnellement des dizaines de personnes qui le font, moi y compris)".

                      • [^] # Re: HAHA

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

                        Ce n'est pas parce qu'elle ne te plait pas qu'elle est puante. C'est un choix. Qui a l'air de plaire.

                        Le choix ne plait pas, cfr propos de spender (à sortir du contexte grsecurity, son framework ne plait pas forcément pour des raisons techniques.)

                        Je t'en prie, propose mieux. En vrai, hein, pas en lalalala, pour démontrer qu'il est possible de mieux faire (en plus, tu dis toi-même que les "méchants" scannent les logs GIT, donc ça doit être aussi possible pour les "gentils").
                        Perso, je constate juste que Linux est sur tous les serveurs ou presque non pas parce que les commerciaux sont doués, mais parce qu'il répond au besoin technique (sécurité comprise, faut voir comparé à d'autres OS).

                        J'ai expliqué mon point de vue sur les choses à améliorer, suffit de lire. Avoir une vraie team sécurité, des vrais reviews de patches, ne pas considérer la sécurité comme un truc chiant qui ne concerne que les autres.
                        Linux est sur beaucoup de serveurs, y compris les miens, parce qu'il y a beaucoup de fonctionnalités dedans et que ça marche pas mal. Mais j'aimerais bien avoir un OS dont j'ai la garantie que tous les bugs de sécurité qui ont été trouvés dans le passés soient patchés sur mon système. Je n'ai pas encore cette garantie aujourd'hui.

                        Je reprend ce bout de phrase, mais l'utilise pour ton "(Je connais personnellement des dizaines de personnes qui le font, moi y compris)".

                        Je vais ignorer cette basse attaque ad hominem.

                        • [^] # Re: HAHA

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

                          C'est une question de ressources. Soit tu prends un noyau ou les gens auditent tout pour la sécurité, mais ça avance pas aussi vite que tu voudrais, voir ça vire des options que tu voudrais ( exemple, la virtualisation que l'équipe openbsd considère comme mauvaise pour la sécurité, donc ne veut pas intégré ça ). Soit tu prends un truc qui avance et ou le prix du progrès, c'est d'avoir parfois des failles.

                          Sinon, si tu veux une vraie équipe sécurité, y a des boites qui font leur propre OS qui paye des gens pour ça. Exemple, Apple, Microsoft, SunW Oracle mais bien sur, tu doit payer. Y a des boites qui payent aussi des équipes sécu pour le logiciel libre, genre Red Hat, Suse, Canonical, mais pareil, les revues de sécurité, ça tombe pas du ciel.

                          Dernière possibilité, commence à faire des revues de code en même temps que tout le reste de la lkml, lead by example, etc, etc.
                          Poster sur Linuxfr sans rien faire, ça va juste rien faire.

                        • [^] # Re: HAHA

                          Posté par  . Évalué à 7.

                          Mais j'aimerais bien avoir un OS dont j'ai la garantie que tous les bugs de sécurité qui ont été trouvés dans le passés soient patchés sur mon système. Je n'ai pas encore cette garantie aujourd'hui.

                          Si jamais tu en trouve un, ce serait une sacré découverte (et on parle bien de tous les bugs de sécurité, pas uniquement des bugs taggé comme tel).

                          « 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: HAHA

                    Posté par  . Évalué à 1.

                    Tu es au courant qu'il y a un très faible nombre de gens qui utilisent grsecurity?

                    Source ?

                    Faut juste que les autres suivent. grsecurity est un très bon exemple, ses patchs sont jugés foireux,

                    Source ?

                    rejetés de la branche principale

                    Faux, Brad Spengler n'a aucune volonté de pousser grsecurity dans la branche principale.

                    et il est bloqué à Linux 3.4.4, ça manque un peu de réactivité…

                    Encore faux, les patch sont disponibles jusqu'à la version 3.9.2

                    Des fois il faut se renseigner un peu avant de parler…

                    • [^] # Re: HAHA

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

                      Flemme de chercher pour le reste, concentrons-nous la dessus :

                      Encore faux,

                      Effectivement, je me suis trompé, j'ai été trop gentil, c'est que 3.2 (j'avoue avoir mal lu wikipedia trop vite, mauvaise ligne qui est vieille)

                      les patch sont disponibles jusqu'à la version 3.9.2

                      Tu fais de la sécurité avec des versions de tests non jugées stables par les développeurs?

                      • [^] # Re: HAHA

                        Posté par  . Évalué à 3.

                        Brad choisit uniquement certaines version LTS de Linux en tant que branche stable. Cela explique que sa branche stable soit "Bloquée" en 3.2.

                        Tu fais de la sécurité avec des noyaux qui n'ont pas du support à long terme ?

                        Je ne comprends pas ton propos, tu parles de manque de réactivité, on te montre que si c'est réactif, et du coup tu critiques le fait que cela ne soit pas stable ?

                        • [^] # Re: HAHA

                          Posté par  (site web personnel) . Évalué à 1. Dernière modification le 20 mai 2013 à 15:28.

                          Je ne comprends pas ton propos, tu mélanges réactivité et stabilité.
                          Du réactif non stable n'est pas du réactif.
                          Tu confirmes bien donc ce que je disais: tu utilises (ou parle d'utiliser) du test pour de la production.

                          on te montre que si c'est réactif

                          Non, me démontrer ça serait que grsecurity soit en stable avec la 3.9, ce qu'il n'est pas.
                          Pire, à revoir kernel.org, la dernière longterm (ne rigolons pas, ne parlons pas de dernière stable) est la 3.4, pas en stable pour grsecurity, oups… Tu parles d'une réactivité! tu le dis toi-même "certaines LTS de Linux", du coup quand elle n'est pas choisie, ben réactivité à la ramasse.

                          • [^] # Re: HAHA

                            Posté par  . Évalué à 1.

                            Pour être précis dans le choix des stables, ce sont les LTS choisies par les distributions :
                            - 2.6.32 : Debian Squeeze et RHEL 6
                            - 3.2 : Debian Wheezy

                            Tu confirmes bien donc ce que je disais: tu utilises (ou parle d'utiliser) du test pour de la production.

                            Non, je parles d'utiliser pour de la production des versions qui ont du LTS, c'est toi qui n'a pas répondu à ma question, tu utilises des versions non LTS pour de la production ?

                    • [^] # Re: HAHA

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

                      ses patchs sont jugés foireux

                      Source ?

                      http://article.gmane.org/gmane.linux.kernel/774824

                      • [^] # Re: HAHA

                        Posté par  . Évalué à 2.

                        Au temps pour moi, j'avais compris foireux au sens, les fonctionnalités apportées sont foireuses. Si l'on parle de patch foireux au sens non intégrable parce que tros gros, en effet.

                        L'auteur de Grsecurity n'a aucune intention de pousser ses développement mainstream. Il ne fait donc aucun effort pour présenter son code pour qu'il soit intégré. Attention, je ne veux pas dire par la qu'il fait du mauvais code, mais il n'y a aucune découpe des différents patch par fonctionnalité, ce qui permettrai une meilleure intégration.

                      • [^] # Re: HAHA

                        Posté par  . Évalué à 4.

                        Linus n'a jamais dit que ces patches étaient foireux, juste qu'ils sont bien trop spécifiques et trop chiants pour être upstream.

                        Franchement, on peut faire les mêmes critiques à tout les patches que les gens écrivent pour un besoin particulier sans considération pour être intégrés upstream. C'est le cas à chaque fois que des développeurs utilisent le noyau Linux pour faire autre chose qu'un noyau généraliste.

                • [^] # Re: HAHA

                  Posté par  . Évalué à 9.

                  sd n'a rien fait de mal en gardant pour lui ses résultats

                  Il va falloir que tu m'expliques en parlant lentement : pour quelle raison sans visées illégales cette personne garde secrète ce genre d'info ?

                  Si c'est un professionnel « propre » de la sécurité, il n'a aucun bénéfice à attendre pour publier. Sinon il risque de se faire doubler, et son CV sera moins bon.
                  Il faut donc enlever « propre » pour que son attitude soit logique.
                  Vendre des failles de sécurité, c'est la même chose que vendre le code administrateur d'une centrale d'alarme, ou d'une ouverture de porte automobile. Le but est uniquement illégal.

                  • [^] # Re: HAHA

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

                    Il va falloir que tu m'expliques en parlant lentement : pour quelle raison sans visées illégales cette personne garde secrète ce genre d'info ?
                    Si c'est un professionnel « propre » de la sécurité, il n'a aucun bénéfice à attendre pour publier. Sinon il risque de se faire doubler, et son CV sera moins bon.
                    Il faut donc enlever « propre » pour que son attitude soit logique.

                    Ton commentaire touche à un des points assez sensibles en infosec, qui est le grand débat full disclosure/no disclosure. Beaucoup de chercheurs compétents croient au non disclosure et gardent leurs trouvailles pour eux, au risque de se faire doubler comme tu dis. En résumé, leur raisonnement est le suivant:
                    - Ils ne sont pas payés pour faire la recherche donc n'ont pas d'obligation de publication
                    - Les bugs de sécurité sont vu comme des trésors heisenbergiens qui disparaissent lors de la publication. Un exploit 0day, même non partagé, est une sorte de trophée qu'ils conservent précieusement.
                    - Ils n'ont pas besoin de publier pour étoffer leur CV, partant du principe que le CV ne leur intéresse pas ou qu'ils n'ont pas besoin de publier pour être reconnus
                    - Le point le plus important: la publication de découvertes de sécurité est une pratique dangereuse. Cela ne s'applique sans doute pas à linux, mais publier en son nom propre (même en suivant les pratiques de "responsible disclosure") expose le chercheur à des ripostes légales. Parfois prendre ce risque gratuitement ne vaut pas le coup.

                    Vendre des failles de sécurité, c'est la même chose que vendre le code administrateur d'une centrale d'alarme, ou d'une ouverture de porte automobile. Le but est uniquement illégal.

                    J'ai une opinion différente. Certains hackers considèrent que vendre de l'exploit est non éthique (je pense que sd en fait partie), et préfèrent laisser leur exploit moisir sur le disque dur que le divulguer de cette manière. Quoi qu'il en soit, vendre une faille de sécurité n'est pas similaire à vendre un code d'alarme. C'est vendre la primeur sur un problème de sécurité peut-être connu ailleurs pour laisser une chance aux clients de se protéger à l'avance. Je pense que le raisonnement "vendre des vulnérabilités est forcément illégal" tient du même raisonnement fallacieux que "Si tu utilises de la cryptographie, c'est que tu as des choses illégales à cacher".
                    Et vu le nombre de vulnérabilités critiques rapportées par ZDI et autres, qui seraient peut-être restées très longtemps non publiées si il n'y avait pas de contrepartie financière, je pense que la monétisation de rapports de vulnérabilité est positif à long terme. Rechercher des vulnérabilités, ça prend du temps et c'est loin d'être gratuit.

                    • [^] # Re: HAHA

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

                      Lien pertinent à mon message plus haut: http://blog.trailofbits.com/2009/03/22/no-more-free-bugs/

                    • [^] # Re: HAHA

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

                      • Ils ne sont pas payés pour faire la recherche donc n'ont pas d'obligation de publication

                      On parle de responsabilité.
                      Personne ne parle d'obligation.

                      Tu trouves responsable l'idée (si on augmente ton principe) de laisser crever des gens alors que tu aurais pu empêcher ça en informant juste la bonne personne, et tu peux dormir tranquille, pas moi. Ils ne sont pas payés pour faire la recherche? Qu'ils ne la fassent pas. Mais si ils trouvent, c'est de leur responsabilité (non légale) d'informer la bonne personne (et si l'upstream s'en fout, tant pis, ils auront fait ta part). Ils n'en n'ont pas l'obligation légale certes, mais cette non obligation n'enlève pas l'idée que ces personnes sont des salopards (sans les guillemets).

                      Tu as un conscience très sélective.

                      • Le point le plus important: la publication de découvertes de sécurité est une pratique dangereuse. Cela ne s'applique sans doute pas à linux, mais publier en son nom propre (même en suivant les pratiques de "responsible disclosure") expose le chercheur à des ripostes légales. Parfois prendre ce risque gratuitement ne vaut pas le coup.

                      Tu le dis toi-même : ça ne s'applique pas à Linux. Et ici, on parle de?
                      informer seulement l'upstream uniquement n'a jamais fait prendre des risques légaux dans ce milieu. Il y a même des confs dédiées à ça! Au pire on t'ignore (genre Microsoft), au mieux on te récompense nominativement et financièrement (hop, pratique tu perds ton argument "risque gratuit") (genre Mozilla et Google).

                      Les risques sont si tu t'attaques au système d'un autre (accès frauduleux genre si tu t'attaques au GIE carte bancaire, il y en a un qui en a fait les frais), ici tu peux t'attaquer à ton propre système, donc le seul risque et de te prendre un procès de toi-même, risque gérable.

                      Ne te cache pas devant des excuses fallacieuses pour te donner bonne conscience.

                      • [^] # Re: HAHA

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

                        Tu trouves responsable l'idée (si on augmente ton principe) de laisser crever des gens alors que tu aurais pu empêcher ça en informant juste la bonne personne, et tu peux dormir tranquille, pas moi. Ils ne sont pas payés pour faire la recherche? Qu'ils ne la fassent pas. Mais si ils trouvent, c'est de leur responsabilité (non légale) d'informer la bonne personne (et si l'upstream s'en fout, tant pis, ils auront fait ta part). Ils n'en n'ont pas l'obligation légale certes, mais cette non obligation n'enlève pas l'idée que ces personnes sont des salopards (sans les guillemets).

                        Pour reprendre tes propres mots:

                        Tant que ce n'est pas exploité, ça ne pose aucun problème. Sans compter que la plupart du temps, c'est non exploitable.

                        Nous parlons aussi du comportement de l'équipe de dev de linux, qui pour toi n'ont rien fait d'irresponsable alors qu'ils ont aussi l'obligation "morale" de prévenir lorsqu'un bug qu'ils ont réparé était exploitable, selon tes critères.

                        Les risques sont si tu t'attaques au système d'un autre (accès frauduleux genre si tu t'attaques au GIE carte bancaire, il y en a un qui en a fait les frais), ici tu peux t'attaquer à ton propre système, donc le seul risque et de te prendre un procès de toi-même, risque gérable.

                        Malheureusement il y a un paquet de contre exemples, allant de mecs qui montrent que le DRM d'une solution x est inutile (Dmitry contre Adobe), à des mecs qui montrent qu'il est facile de contourner un antivirus (qui tourne sur ta propre machine). Petite liste disponible ici: http://attrition.org/errata/legal_threats/

                        • [^] # Re: HAHA

                          Posté par  (site web personnel) . Évalué à 1. Dernière modification le 19 mai 2013 à 12:28.

                          alors qu'ils ont aussi l'obligation "morale" de prévenir lorsqu'un bug qu'ils ont réparé était exploitable

                          Tu sais, toi, qu'ils savaient que c'était exploitable? Ils avaient codé une démo? Source?
                          C'est la "petite" différence qui change tout… Je l'ai écrit déjà ("faire la recherche").

                          que le DRM d'une solution x est inutile (Dmitry contre Adobe)

                          Tu as lu ce que j'ai écrit? La, on parle de DRM, même pas libre, qui est juridiquement protégé (contourner un DRM est illégal, DMCA aux USA, DADVSI en France).
                          Au passage, tout le monde n'habite pas dans des pays bizarre, et perso je publie depuis des années un crack qui casse des DRM sans être inquiété.

                          Passer root sur ta machine à toi n'est pas illégal à ma connaissance, où sort moi le texte.
                          Il y a parfois des risques, oui, je n'ai jamais nié ça (tu donnes un exemple DRM qui ne t'appartient pas, j'en donne un CB) mais certainement pas pour ce dont on discute, ne te cache pas derrière des exemples différents.

                          • [^] # Re: HAHA

                            Posté par  . Évalué à 3.

                            Passer root sur ta machine à toi n'est pas illégal à ma connaissance, où sort moi le texte.

                            Je sors cette phrase de son contexte car on ne passe pas root sur une machine mais sur un système d'exploitation. Être propriétaire de la machine ne signifie pas avoir les droits sur le ou les systèmes d'exploitations qu'elle fait tourner ; les hébergeurs en savent quelque chose… Il y a bien un risque légal d'intrusion.

                            My 2 cents.

                          • [^] # Re: HAHA

                            Posté par  . Évalué à 2.

                            Il y a parfois des risques, oui, je n'ai jamais nié ça (…) mais certainement pas pour ce dont on discute
                            En France en tout cas, il est interdit de développer et encore plus de publier des outils permettant de trouver et exploiter des failles de sécurité (art 323-3-1 du code pénal).
                            Donc le monsieur qui a publié l'exploit est susceptible de poursuites selon la loi française.
                            Dans d'autres pays (pas forcément des états de droit), ce serait une mise à l'ombre directe par les services spécialisés.

                        • [^] # Re: HAHA

                          Posté par  . Évalué à 6.

                          Nous parlons aussi du comportement de l'équipe de dev de linux, qui pour toi n'ont rien fait d'irresponsable alors qu'ils ont aussi l'obligation "morale" de prévenir lorsqu'un bug qu'ils ont réparé était exploitable, selon tes critères.

                          Ils n'ont pas réparé un bug qu'ils savaient exploitable. Ils ont réparé un bug, qui comme des milliers d'autres est peu etre exploitable, ou peu etre pas. Pour le savoir, il faut passer du temps à essaier de l'exploiter.

                      • [^] # Responsabilité

                        Posté par  . Évalué à 2.

                        On parle de responsabilité.

                        Si on accorde une responsabilité à celui qui cherche des failles et qui en trouve, ne faut-il pas en accorder autant à ceux qui développent en reléguant la sécurité au second plan ?

                        On sait que Linus ne fait pas de distinction entre les bugs (puisqu'un bug qui n'est pas identifié comme étant de sécurité peut s'avérer en être un). Partant de là, ceux qui choisissent d'utiliser linux n'acceptent-ils pas tacitement la situation actuelle du noyau en matière de sécurité ? Quel est le niveau de responsabilité de ces utilisateurs ?

                        • [^] # Re: Responsabilité

                          Posté par  (site web personnel) . Évalué à 5. Dernière modification le 19 mai 2013 à 12:52.

                          Un bug est un bug, c'et un choix, on ne sait pas forcément que c'est de sécurité c'est tout, c'est quoi le problème la dessus?
                          Et je ne vois pas le rapport entre la politique de sécurité de Linux (il y en a une : un bug est un bug) et le fait que quelqu'un ne prévient personne (Si Linus ne veut pas, ok, mais au moins prévenir les distros qui s'interessent à la sécu non?) quand il a une démo, et surtout qu'il balance la démo comme ça quand ça lui chante.
                          Si il ne cherche pas, je ne l'accuse pas de ne pas chercher.
                          Si il trouve mais ne dit jamais rien, passe encore.
                          Si il trouve et balance l'exploit quand la faille est patchée par quelqu'un d'autre qui ne sait pas forcément que c'est un problème de sécurité, désolé de ne pas dégager la personne de son irresponsabilité et/ou intention de nuire.

                          Pour faire une analogie (en admettant que Linux ai une "politique pourrie"), ce n'est pas parce qu'une porte est ouverte (politique de sécurité pourrie) que ça te légitime d'entrer et tout prendre (utiliser ton hack), ou dire aux autres comment faire ("allez y les gars, cassez tout").

                    • [^] # Re: HAHA

                      Posté par  . Évalué à 4.

                      Les bugs de sécurité sont vu comme des trésors heisenbergiens qui disparaissent lors de la publication. Un exploit 0day, même non partagé, est une sorte de trophée qu'ils conservent précieusement.

                      Par définition, un secret jamais partagé ni exploité ne rapporte jamais rien.
                      Vu que c'est issu de son travail, qu'il passe probablement des centaines d'heures à trouver ce genre de truc, alors il exploite ce secret (ou alors il a les fils qui se touchent). Il exploite par lui-même ou en vendant la solution. L'objectif final est forcément de pénétrer des systèmes. Donc des choses illégales, mais surtout vaguement détestables.

                      Je suis peut-être à côté de la plaque, mais je n'ai vu nulle part dans les arguments ici quelque chose qui tienne la route. À part concernant des activités illégales. Et dans ce cas je comprends bien que le mec ne s'en vente pas.

                      • [^] # Re: HAHA

                        Posté par  . Évalué à 2.

                        Donc des choses illégales, mais surtout vaguement détestables.

                        Un informaticien qui divulgue de telles découvertes longtemps après, ne tombe pas nécessairement dans l'illégalité. Son travail peut servir à des activités parfaitement licites. Par exemple dans le cadre des tests d'intrusion, pratiqués par certaines sociétés spécialisées en sécurité informatique, la possession possession d'un tel "outil" peut devenir un avantage commercial.

                        Le fait qu'il ait publié son exploit m'incite à penser qu'il est surtout en quête de reconnaissance plus qu'autre chose.

                  • [^] # Re: HAHA

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

                    Je ne suis plus un professionnel du domaine, mais j'ai pris une douche, donc je m'estime un minimum propre. Parfois, si tu as une faille, tu agrdes parce que tu as pas le temps de t'en occuper. Moi, j'ai trouvé des trucs mineurs en faisant de la lecture de code, j'ai fait un rapport de bug par mail, j'attends le correctif. Depuis janvier.

                    Ensuite, c'est dans l'absolu, si j'avais un truc de ce genre, oui, je tenterais de faire corriger ça assez vite. Et pour ça, c'est simple, au moins pour le logiciel libre. Y a assez de gens sur la liste oss-security pour t'aider à coordonner une release du patch avec un embargo pour que ça soit fait le plus proprement sans faire trop de dégâts.

                    Dans le cas de spencer, chaque fois que je lit ce qu'il écrit, il est souvent agressif et/ou hautain et rarement coopératif. Et c'est en voyant ce genre de mec ( car c'est pas le seul dans le milieu ) que j'ai compris que le monde de la sécurité est mauvais pour l'équilibre psychologique des gens ( et donc que j'ai pas cherché à re bosser dans le domaine à nouveau, si c'est pour trainer avec des mecs dans son genre ( et c'est pas le seul, je précise ), je préfère devenir admin windows au tadjikistan )

                    Et c'est aussi en le lisant que j'ai pigé que le patch grsecurity serait sans doute jamais mergé upstream, donc jamais à l'abri d'un coup de tête du dev principal, donc à éviter pour ma part.

                • [^] # Re: HAHA

                  Posté par  . Évalué à 8.

                  Mon petit projet y arrive, pourquoi linux n'y arrive pas ? Parce qu'il n'y a pas d'équipe de sécurité.

                  Mouais. Ou bien plutôt : parce que ton petit projet est petit. C'est largement plus facile de maîtriser la sécurité d'un petit projet, avec une communauté de développeurs et d'utilisateurs restreinte (et donc une grande facilité à imposer des pratiques homogènes), que sur un des plus gros projets au monde.

                  Et ce n'est pas juste moi qui le dit, mais Spender (le mec de grsecurity qui s'y connait "un peu" en sécurité linux) [1] premier hit sur "spender linus security"

                  S'y connaître techniquement en sécurité, cela ne fait pas de lui une autorité en matière de méthode de développement. Chacun croit son activité plus importante que les autres : les fous de performances vont mépriser n'importe quel programme leur apparaissant comme "bloated", par exemple. Les férus de sécurité essaient en permanence d'imposer un agenda où la résolution des problèmes de sécu prime sur tout le reste (y compris, par exemple, la compatibilité avec l'existant). Discuter avec ce genre de types peut être extrêmement pénible, et peu productif.

                • [^] # Re: HAHA

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

                  la vision de Linus (Un bug de sécurité = un bug) est totalement irresponsable. Il se moque totalement de l'impact des bugs de linux au niveau de la sécurité

                  Ce serait pas mal quand même de prendre le temps de lire et de comprendre ses arguments au lieu de pontifier doctement comme tu le fais.
                  Je t'invite à (re)lire les questions relatives à la sécurité dans son interview qui avait été postée sur LinuxFR : https://linuxfr.org/news/linus-torvalds-l%E2%80%99interview-anniversaire-des-20%C2%A0ans-du-noyau

                  Tu fais un Ctrl+F "GRSecurity" et tu lis les trois questions qui suivent.
                  Tu notera d'ailleurs que ça se termine par une phrase que je t'invite à méditer: "Do security people always agree with me? Hell no. But they don't agree amongst themselves either, so what does that prove?"

              • [^] # Re: HAHA

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

                Ce genre de personne que tu décris est bien un salopard, pas besoin de mettre des guillemets.
                Et non, ce n'est pas standard dans l'industrie de la sécurité

                Laisse moi deviner : tu ne bosses pas dans l'industrie de la sécurité, et tu ne connais pas grand monde qui y bossent. Je me trompe ?

                Parce que le gars que tu qualifies de salopard, c'est peut-être juste un gars qui fait son boulot. Et le comportement décris EST standard, même si ça peut en gêner certains.

                Toutes les boites de sécu que je connais qui pratique des tests d'intrusions connaissent des failles 0-days, et ne les divulguent pas. Tout simplement parce que lors d'un audit, disposer d'un moyen "innovant" pour pénétrer un système, c'est un avantage concurrentiel, et un gros gain de temps.

                • [^] # Re: HAHA

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

                  ça résume bien ce qui va pas dans le monde de la sécurité. Y a plein de pognon à se faire car le processus de décision contourne la rationalité. Le secret autour des affaires fait que les légendes urbaines et les exagérations sont légions ( suffit de voir les histoires de cyberwars ). Le cinéma fait tout pour faire rêver et faire croire que la sécurité et les ordinateurs, c'est magique et/ou compliqué et/ou tout troué. On vends aux gens de la peur basé sur justement de l'imaginaire, donc ça parle directement à un niveau moins rationnel de l'esprit.

                  Comme le dit Linus dans une interview cité plus haut, et comme j'ai pu le constater souvent en bossant dans le domaine et en lisant les MLs de projets, certains gens dans la sécurité sont très manichéen avec une vision tunnelisé.

                  Et comme il y a d'énormes ressources en jeu ( lire pognon ), il y a plein de monde et du coup, le monde de la sécurité est plus dans l'opposition et la compétition que dans la coopération, coopération qui est au coeur du logiciel libre et qui explique le clash des cultures. Et pas opposition juste quand il y a de l'argent, ce qui à la rigueur serait normal. Non opposition du style "je passe des jours à montrer qu'un bug est une faille et en plus,je passe le double du temps à contourner les systèmes de sécurité des autres pour faire une petite pique pour montrer qu'ils servent à rien".

                  Opposition car les "leaders" du monde de la sécurité sont souvent dans un des 2 extrêmes entre "paranoiaque et très discret", ie, on ne lit pas d'interview d'eux, voir connait pas leur vrai nom ( SolarDesigner, par exemple, même si maintenant, on connait son vrai nom ), et "grande gueule et porté sur l'obsession de la sécurité, voir l'exagération". Donc à partir de la, les grandes gueules gagnent la bataille médiatique, donc on a tendance à suivre leurs exemples. Suivre pour la vision tunnelisé, suivre dans l’exagération, voir promouvoir des gens comme expert alors qu'ils ont plus d'une fois parlé de casser AES.

                  Ensuite, je connais plein de gens qui ont une approche plus balancé de la sécurité, je ne nie pas leur existence. Mais eux, on ne les entends pas, ils ont pas une horde de gens prêt à reprendre leurs idées non extrémistes sur le web, donc on prends pas en compte leur point de vue.

                  Et enfin, la question qui se pose, c'est de savoir si c'est le milieu qui transforme les gens, ou si c'est les gens qui transforme le milieu. Et si au final, c'est une bonne chose de voir qu'en France, on a 4 conférences de sécurité international durant ce trimestre. Ou plus audacieux, est ce que la monté du front national en France et la monté de la sécurité informatique ne sont pas liés ( liés dans le sens ou "se méfier des autres" devient une idée de société prédominante )

                  • [^] # Re: HAHA

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

                    Ou plus audacieux, est ce que la monté du front national en France et la monté de la sécurité informatique ne sont pas liés ( liés dans le sens ou "se méfier des autres" devient une idée de société prédominante )

                    Mélange un peu rapide… On peut aussi voir que la sécurité va de pair avec la démocratisation de l'informatique, avec des choses intéressantes à récupérer à nos jours (compte bancaire, secret industriel… Et ce en masse).
                    Et les gens veulent se protéger du vol depuis bien avant l’existence du FN et de l'informatique.
                    Et ce que la démocratisation de l'informatique et la montée de la sécurité informatique ne sont pas liées?

                    • [^] # Re: HAHA

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

                      Ben justement, c'est la question. Bien sur que c'est rapide, c'est un commentaire sur linuxfr, pas guerre et paix ( même si j'ai déjà écrit des romans en commentaire ). On peut en discuter pendant des heures, comme déjà savoir si il y a une montée ou pas.

                      Mais par exemple, on peut comparer avec d'autres pays de taille comparable. Est ce qu'il y a autant de choses autour de la sécurité en espagne, en allemagne ? L'allemagne a toujours eu le CCC, mais c'est pas le même public visé que Hackito Ergo Sum ou d'autres comme le SSTTIC.

                      Est ce que la présence du minitel ( et donc la monétisation des services qui va avec ), le fait d'avoir des accès au net pas cher ( ou plutot moins cher qu'ailleurs ) est aussi une cause de la démocratisation de l'internet, donc de la montée de la sécurité informatique en France ? Peut être.

                      Il est généralement reconnu que ça a fait un bond après les attentats du 11 septembre, parce que l'état américain a financé plein de projets et donc a lancé la machine économique ( et j'aurais tendance à le croire aussi ). Ensuite, une fois les deniers publiques épuisés, la technologie s'est retrouvé dans le civil, vu que la croissance du point de vue des militaire et de l'état était soit bouché, soit illégal ( ie, dictature, etc, ce qui n'a pas empêché ).

                      Mais ensuite, la politique sécuritaire du gouvernement sarkozy, peut être lié aussi aux retombées en occident du 11/09 n'ont pas aidé à instauré cette montée ? La loi HADOPI, le concept d'"internet civilisé", etc, tout ça, c'est aussi des choses qui ont instauré l'idée que l'internet est une source de danger et de non droit.

                      Et mon point, c'est pas qu'il n'y avait pas de sécurité avant, mais qu'il y a en a beaucoup plus maintenant. C'est pas une croissance faible ou un niveau constant, c'est une croissance des plus fortes. ( encore une fois, on passe de 1 conf franchouillarde par an à 4 ce trimestre ). Et ces conférences sont organisés par des personnes locales. Les gens du milieux se plaignent que le STICC est noyauté par l'ANSII et les grosses boites, mais c'est aussi parce que ces groupes ont grossis. Thales, EADS, etc, y a quoi comme équivalent à l'étranger, et est ce qu'il y a une corrélation entre la présence de grand groupe du même genre et d'un milieu de la sécurité vivace ?

                      Peut être qu'il y a une monté de la visibilité des crimes qui irait avec une monté de l'information disponible. Peut être qu'il y a une montée parce que les barrières à l'entrée sont plus basses, que les risques sont moindres, c'est sans doute aussi une explication. peut être qu'il y a juste une montée de la visibilité de la sécurité informatique, je sais pas.

                      Il y a sans doute plus d'une raison, et je ne dit pas que ma proposition est la seule cause, loin de la. La question est de savoir si c'est une cause ou pas. Ou une conséquence. Ou un hasard. Après tout, l'extrémisme politique arrive ailleurs, et pour d'autres raisons. Mais par exemple, ailleurs en europe, je ne croit pas qu'on retrouve les mêmes choses qu'en France ( ie, climat poussant à ne pas croire l'internet, tout en ayant favorisé la montée de l'internet dans les années avant via la mise en place d'infrastructure, et via des initiatives privés ( free par exemple )). Par exemple, je pense que la France est très avance sur le libre ( dans le sens ou on a beaucoup de contributeurs francais ) parce que la DST a coupé une montée des "hackers" dans les années 80, ce qui fait qu'une génération de gens se sont retrouvés à faire du libre au lieu de faire des mouvements comme le CCC comme en Allemagne. Et peut être que cette montée des libristes a permis l'arrivé de FDN, de Free, et une certaine compréhension du fonctionnement du réseau, qui a permis d'avoir plus de libristes, plus d'internet, et à la fin, plus de gens dans le milieu de la sécurité.

                      • [^] # Re: HAHA

                        Posté par  . Évalué à 4.

                        Par exemple, je pense que la France est très avance sur le libre ( dans le sens ou on a beaucoup de contributeurs francais ) parce que la DST a coupé une montée des "hackers" dans les années 80, ce qui fait qu'une génération de gens se sont retrouvés à faire du libre au lieu de faire des mouvements comme le CCC comme en Allemagne

                        Pourtant il y a aussi énormément de contributeurs allemands, peut-être plus que de français.

      • [^] # Re: HAHA

        Posté par  . Évalué à 4.

        2 ans pour écrire l'exploit, ca devait être très complexe.
        ---->[]

      • [^] # Re: HAHA

        Posté par  . Évalué à 2.

        Stop aux "Ha Ha"

        Humour toussa… Vu le titre je pensais que ça serais évident. Et le fait que mon serveur soit sous Arch Linux contrairement à 99,99% des serveurs sous GNU/Linux.

        Le mec qui a écrit l'exploit connaissait le bug depuis au moins deux ans.

        Eh bien ça mérite d'être ajouté à la dépêche, parce que ça touche de vieux noyaux mais ça veut pas dire qu'elle était connue/utilisée.

        Écrit en Bépo selon l’orthographe de 1990

        • [^] # Re: HAHA

          Posté par  . Évalué à 10.

          le fait que mon serveur soit sous Arch Linux contrairement à 99,99% des serveurs sous GNU/Linux.

          C'est très intéressant un serveur que tu dois redémarrer toutes les 2 semaines pour une mise à jour du noyau…

          « I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

          • [^] # Re: HAHA

            Posté par  . Évalué à 3.

            Ce genre d'actu remet régulièrement en cause le choix du mode de distribution : rolling release ou par version longue…

            J'imagine les ressources nécessaires qu'il faut avoir pour de suivre les bugs, trous de sécu et les patcher sur une ancienne version. Mais quand l'upstream ne communique même pas alors ce travail ne sert tout simplement à rien !

            Autant prendre la dernière version.

            • [^] # Re: HAHA

              Posté par  . Évalué à 5.

              En suivant cette logique jusqu'au bout, tu devrais même prendre un nightly build et redémarrer une fois par jour: on ne sait jamais, la correction a peut-être eu lieu dans une branche expérimentale sans que le correcteur réalise que c'est une faille de sécurité exploitable.

              Sérieusement, la question ici, c'est fréquence du redémarrage contre sécurité.
              La "faille" non du noyau, mais du système, c'est que le trou de sécurité n'a pas été rapporté en tant que tel, mais en tant que bug. Et apparemment, c'est souvent le cas.

              Alors, moi je ne suis pas développeur ni admin sys, mais j'aurais envie de poser la question: est-ce qu'il ne vaut pas mieux rapporter en tant que faille de sécurité tout bug que le développeur pense être exploitable comme faille?

              C'est sûr, vu ce qu'explique le dév, ça risque d'augmenter le volume de la liste sécu, mais cette liste ne devrait pas être limitée par autre chose que les considérations purement technique, non? S'il faut vraiment faire des mises à jour plus fréquentes, alors c'est du ressort de l'admin sys que de décider de ces fréquences, par le dév noyau qui ne rapporte pas parce que c'est pas officiellement connu et exploité.

              Mais j'ai peut-être mal compris le fil?

              • [^] # et quid de Ksplice ?

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

                Le module Ksplice permet de faire les mises à jour de kernel à chaud, sans devoir rebooter. J'adorerais voir ce module intégré nativement dans la plupart des distributions, ce qui résoudrait en partie la problématique de la fréquence de mise à jour du noyau.

                Mais je suppose qu'il s'agit d'un problème de Licence, bien que Wikipedia indique que le module est libre.

                alf.life

                • [^] # Re: et quid de Ksplice ?

                  Posté par  (site web personnel) . Évalué à 3. Dernière modification le 18 mai 2013 à 17:15.

                  bien que Wikipedia indique que le module est libre.

                  Ce n'est plus le cas depuis qu'Oracle a pris le contrôle de la chose (merci Oracle…).

                  Perso, ce qui m'étonne est que personne (à ma connaissance) n'a forké la chose (c'était vraiment lire avant?), je me dis que j'en ai clairement pas l'utilité mais qu'il doit bien y avoir du monde qui aime la haute dispo.

                  • [^] # Re: et quid de Ksplice ?

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

                    De ce que je comprends de la définition de la haute disponibilité, même une panne matériel grave ne doit pas impacter les services.
                    Par conséquent, ce n'est pas rebooter qui doit empêcher le service.

                    Je ne vois pas trop comment ça peut marcher ce truc… Car quand je vois les problèmes, pour reloader dynamiquement un simple module python, je me dis que quand il s'agit du noyau, il est plus prudent de rebooter. Surtout si il s'agit d'update de sécurité, non ?

                    • [^] # Re: et quid de Ksplice ?

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

                      De ce que je comprends de la définition de la haute disponibilité, même une panne matériel grave ne doit pas impacter les services.

                      Ce que j'en comprend, c'est que si tout est redondé, mais que pendant 2 minutes tu rebootes, ben tu as volontairement cassé ta redondance et donc tu es en période de danger. Donc toute suppression d'indispo est bonne à prendre, même tout redondé (justement car tu enlèves ta redondance lors du reboot).

                      Après, est-ce que ça vaut le coup de risquer une merde complexe avec ksplice ou tripler le matos… Question à laquelle je ne peux répondre (perso, je vois le matos comme pas cher de nos jours, je voterai pour tripler le matos plutôt, mais c'est 100% subjectif et certain matos est très cher).

                      Car quand je vois les problèmes, pour reloader dynamiquement un simple module python,

                      Troll: après, tu parles d'un langage de prototypage… ;-)

                      Je ne vois pas trop comment ça peut marcher ce truc…

                      Ca change les adresses pour les nouveaux appels, c'est vraiment pas idiot. Mais c'est pas trivial, donc pas fait par tous (genre Python que tu as cité : c'est peut-être pas leur priorité)

                  • [^] # Re: et quid de Ksplice ?

                    Posté par  . Évalué à 2.

                    Ceux qui aiment la haute dispo ont probablement un pool de serveurs derriere un load balancer et rebootent les machines une a une, donc ils voient pas trop la difference.

                    Sans compter qu'il reste toujours des mises a jour soft qui sont plus simple a appliquer avec un reboot: si tu met a jour libssl, t'as le choix entre redemarrer tous les process qui l'utilisaient, ou rebooter la machine. Perso je prefere rebooter la machine: quitte a avoir du downtime, autant etre sur que t'as effectivement tout redemarre.

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

                  • [^] # Re: et quid de Ksplice ?

                    Posté par  . Évalué à 3.

                    Sinon il y a kexec qui permet de charger un nouveau noyau sans redémarrer.

                    • [^] # kexec ?

                      Posté par  . Évalué à -6.

                      Sinon il y a kexec qui permet de charger un nouveau noyau sans redémarrer.

                      kexec ?
                      Vous avez personnellement essayé ?
                      Et… euh… çà marche ?

                    • [^] # Re: et quid de Ksplice ?

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

                      s/sans redémarrer/sans passer par le BIOS/

                      Ce qui est déjà pas mal, je le reconnais, mais tu ne coupes pas au reboot de l'userspace, à la perte de l'état, etc, etc.

                      • [^] # Re: et quid de Ksplice ?

                        Posté par  . Évalué à 3.

                        s/sans redémarrer/sans passer par le BIOS/

                        Ça c'est quand on fait un reboot avec kexec installé.

                        mais tu ne coupes pas au reboot de l'userspace, à la perte de l'état, etc, etc.

                        Pas besoin de couper l'espace utilisateur. En utilisant kexec manuellement, on peut charger un nouveau noyau à chaud tout en gardant l'état des services (plus ou moins).

                        # kexec -l /boot/vmlinuz-linux --initrd=/boot/initramfs-linux.img --reuse-cmdline
                        # kexec -e
                        
                        

                        Bon ça coupera les connexions réseaux (l'option --no-ifdown existe mais je n'ai jamais essayé) mais l'espace utilisateur remarque à peine le changement.

                    • [^] # Re: et quid de Ksplice ?

                      Posté par  . Évalué à 1. Dernière modification le 20 mai 2013 à 12:33.

                      edit : commentaire enlevé, ça m'apprendra à lire.

                • [^] # Re: et quid de Ksplice ?

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

                  Non, le souci n'est pas la licence (en tout cas, ça n'était pas la licence au début), le souci, c'est soit y a des limitations (genre pas le droit de toucher à la taille du code binaire sinon tu décales tout les pointeurs, pas le droit de toucher aux structures, etc, etc), soit tu es obligé de faire des grosses réécritures de la mémoire, et ton kernel est dans un sale état. En fait, quand tu vois que les devs kernels voulait retirer la possibilité de retirer les modules car c'était trop compliqué (à l'époque du 2.6, je crois), c'est bien qu'il y a quelque choses.

                  Donc pour mettre à jour ton kernel, tu dois "juste" changer du code, mais pour change rle code, faut le faire de tel façon que le kernel soit le même du point de vue du layout. Même si pour les failles les plus importantes, ça semble être bon d'aprés wikipedia, il semble que pour une petite partie des failles ( 12% ), il faut faire intervenir un développeur pour bidouiller la mémoire du kernel. Et bien sur, les chiffres ne parlent que de 64 failles sur 3 ans, quid des autres updates que tu voudrait aussi appliquer sans rebooter ?

                  Et ça, ça part du principe que tu part avec un kernel connu dont tu as le code, pas un kernel bidouillé ou avec des modules customs ou ce genre de choses. Et bien sur, chaque modif implique un patch spécifique, et chaque patch spécifique implique des tests poussés (car bon, c'est une chose de tester un soft dans un état connu contre une faille, c'est autre chose de tester un soft dans un état inconnu contre une faille et tout les emmerdes possibles, surtout face à des soucis de processeurs multiples, etc. Et tu veux pas non plus que ton update bloque le kernel trop longtemps pendant que tu fait la mise à jour, vu que le kernel est freezé le temps de magouiller tout)

                  Et je sais pas si tu peux enchainer les updates ksplices advitam eternam.

                  Donc non, en pratique, la plupart des distributions n'ont pas les ressources (en plus maintenant de plus avoir le code à jour). En pratique, Oracle n'a visiblement même pas les ressources suffisante pour faire ça sur les 2 kernels de sa distribution malgré le fait que leur distribution ne soit qu'un rebuild de l'original (ou alors, ils mentent quand ils disent qu'ils sont compatibles de façon binaire, mais Oracle peut pas jouer sur les 2 tableaux à ce niveau la). IE oracle ne propose ksplice que pour son kernel maison, celui qu'ils rebasent sur le 3.0 (vu qu'ils ont pas envie de faire des rebases peut êtrepour des questions de moyens) avec btrfs en production et supporté, voir http://www.h-online.com/open/news/item/Btrfs-ready-for-production-in-new-Oracle-Linux-kernel-1471706.html .

                  Ensuite, peut être que je suis mauvaise langue, c'est vrai, ksplice inc avait réussi à avoir 70 clients en 2 ans d'existence, c'est pas mal.

                  • [^] # Re: et quid de Ksplice ?

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

                    Oracle ne propose ksplice que pour son kernel maison

                    Euh… Je ne connais pas du tout à part le site web, mais sur le site web il y a RHEL, Fedora 2 versions, Ubuntu 4 versions.

                    Ensuite, peut être que je suis mauvaise langue, c'est vrai, ksplice inc avait réussi à avoir 70 clients en 2 ans d'existence, c'est pas mal.

                    Vu le domaine, c'est un marché de niche. Et c'est mieux d'avoir 70 clients à 1 Million que 1 million de client à 10€.
                    Ce nombre seul ne suffit pas dans ce domaine. On ne sait rien de la valorisation de la chose (Le prix d'achat na pas été rendu public à a connaissance)

                    • [^] # Re: et quid de Ksplice ?

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

                      Euh… Je ne connais pas du tout à part le site web, mais sur le site web il y a RHEL, Fedora 2 versions, Ubuntu 4 versions.

                      Ben la doc qu'on trouve sur le web ( https://oss.oracle.com/ksplice/docs/ksplice-quickstart.pdf ) dit qu'il faut le kernel maison d'oracle :

                      Another requirement for the Oracle Ksplice updates, is the use of the Oracle Unbreakable Enterprise Kernel(UEK).

                      Ensuite, la documentation est dite "outdated" ( http://kkempf.wordpress.com/2013/01/24/ksplice-another-reason-to-love-oracle-linux/ ).

                      Donc je pense plus que tu as le support entreprise pour le kernel maison ( ie la partie intéressante ), et que le reste est disponible grâce à une moulinette semi-automatique et moins intensivement testé et sur laquelle y a pas de garantie (notamment pour les drivers tierces). IE, que le support Fedora/Ubuntu est juste la pour servir de demo sur des machines de test afin d'attirer les clients, tout comme leur version d'essai de 30 jours pour RHEL. Bien sur, Oracle ne parle pas du fait que la version d'essai doit sans doute annuler le support RHEL.

                      En fait, au vu des postes de blogs ( https://blogs.oracle.com/ksplice/entry/ksplice_update_for_cve_2013 ), il semble que ksplice oblige à attendre le distributeur de base quand même, et au final, vu qu'il y a assez souvent de mesures qui vont réduire l'impact ( mitigation feature, je suis pas sur de traduire ça comme il faut ), ç'est AMHA mieux de passer par les dites features si ton but est d'être protégé vite fait. Du coup, une fois que tu es protégé sans avoir rebooté, tu as plus besoin de ksplice.

                      Donc oui, comme tu dit, c'est un marché de niche même si 70 clients, c'est déjà pas mal (ie, moi, je connais des boites avec moins de clients en 5 ans) et je pense que plein de gens voudraient ça (mais je connais personne qui utilise ça, alors que le support pour Ubuntu LTS est fourni).

                      La valorisation de la chose, suffit de voir que c'est juste fourni de base avec le support oracle. Donc ils ont fait le calcul sur le fait que vendre ça comme service, ça rapporte moins que comme "cadeau gratuit" à leur clients existants.

                    • [^] # Re: et quid de Ksplice ?

                      Posté par  . Évalué à 4.

                      Vu le domaine, c'est un marché de niche. Et c'est mieux d'avoir 70 clients à 1 Million que 1 million de client à 10€.

                      Ksplice, l'utilité évidente c'est pour les hosting mutualisés, hébergements pourri et assimilés. Bref des environnements exposés ou les solutions techniques des clients est cheap. Ce n'est clairement pas un marché de niche, c'est la majorité du marché.

                      Les marchés de niche qui ont vraiment besoin de dispo, ils s'ent balance. C'est déjà géré ailleurs dans l'archi. D'ailleurs tu passes déjà ton temps à couper des composants pour faire de la maintenance, des upgrades ou simplement pour vérifier que ca marche bien comme prévu. On coupe déjà des data-center entiers volontairement ou non…

                      Et pour les niches encore plus spécifiques (lire hors grosse infra web), c'est souvent tellement spécialisé et cloisonné que t'as moins de pression qu'un hosteur ultra-exposé ou que tu as des fenêtres d'upgrade/maintenance régulièrement.

                      • [^] # Re: et quid de Ksplice ?

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

                        Moi je voyais surtout l'intérêt pour les machines chiantes à rebooter, tels les gros serveurs MySQL : tu flush tous les buffers, et la prod peut mettre des plombes à atteindre à nouveau les mêmes perfs.

                        Maintenant il est vrai que depuis il y a eu quelques avancées à ce niveau :
                        - XtraDB a l'option «innodb_buffer_pool_restore_at_startup» permettant de rapidement recharger le buffer pool.
                        - Galera permet de couper un master sans coupure de la prod

                        Avant ça, c'était parfois problématique de devoir rebooter un serveur MySQL : la réplication asynchrone n'étant pas suffisamment fiable (à mon goût ?), et les solutions disque type DRBD ne règlent pas le problème du buffer pool.

                        Mais oui, c'était peut-être chercher coté kernel une solution à un problème userspace, MySQL en l'occurrence.

                        alf.life

                        • [^] # Re: et quid de Ksplice ?

                          Posté par  . Évalué à 2.

                          Les DB c'est clairement pas mon domaine. Mais si tu as des contraintes de dispo tu as déjà résolu le problème de "mon master par en vrille". Par ce que de toute facon il va exploser, devoir être mis à jour ou être injoignable un jour ou l'autre.

                          C'est exactement ce que j'opposais à zenitram. Ce n'est pas un marché de niche, les marchés de niche ont déjà trouvé leur solution. C'est utile pour tout les autres par contre… Pour qui ça peut être un mieux à pas cher, surtout dans les environnements exposés.

                          Après il faut aussi voir l'exposition de tes services. Une local privilege escalation sur une machine DB on s'en balance un peu à priori ca peut attendre la prochaine maintenance. Même pour un remote tu peux contrer le truc en attendant le slot.

                          • [^] # Re: et quid de Ksplice ?

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

                            Justement, avant les dernières évolutions coté MySQL (Galera & buffer_pool_restore), on avait déjà un failover pour MySQL, mais ce failover avait un coût non négligeable ; donc rebooter un serveur pour une faille locale, clairement on ne le faisait pas, et c'est là que je voyais un intérêt pour les solutions de type Ksplice.

                            Mais je suis d'accord, une fois que tu as passé le cap du cluster, Ksplice perd tout son intérêt.

                            alf.life

              • [^] # Re: HAHA

                Posté par  . Évalué à 3.

                En suivant cette logique jusqu'au bout, tu devrais même prendre un nightly build et redémarrer une fois par jour: on ne sait jamais, la correction a peut-être eu lieu dans une branche expérimentale sans que le correcteur réalise que c'est une faille de sécurité exploitable.

                Belle caricature.

                Il y a une vraie différence entre prendre la dernière release upstream et maintenir des patchs sécu sur une ancienne version. Surtout quand on est sûr de passer à côté. A mettre en parallèle avec le temps passer à maintenir ces patchs, je ne suis pas sûr que ça vaille le coup.

              • [^] # Re: HAHA

                Posté par  . Évalué à 3.

                La "faille" non du noyau, mais du système, c'est que le trou de sécurité n'a pas été rapporté en tant que tel, mais en tant que bug. Et apparemment, c'est souvent le cas.

                C'est souvent le cas, par ce qu'il n'est pas forcement evident en corrigeant un bug que c'est une faille de sécurité exploitable.

                Alors, moi je ne suis pas développeur ni admin sys, mais j'aurais envie de poser la question: est-ce qu'il ne vaut pas mieux rapporter en tant que faille de sécurité tout bug que le développeur pense être exploitable comme faille?

                Le truc c'est que dans le kernel, 90% des bugs sont peu etre exploitables, et il n'est pas souvent simple de dire si oui ou non ca l'est. Alors rapporter tous les bugs en tant que faille, je ne suis pas sur que ca change grand chose, ca va juste rendre invisibles les vraies failles qui sont annoncées comme tel.

            • [^] # Re: HAHA

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

              Bien sur, tu prends en compte le fait que certaines failles sont justes dans les noyaux récents et que ta distro pas-rolling-release n'est pas touché ?

              exemple, CVE-2013-1858 CVE-2013-1979 et CVE-2013-1959 dans le noyau 3.8 uniquement, pour ne citer que les plus récentes qui me viennent à l'esprit. Ou justement la faille dont parle le journal, qui touche pas RHEL5 ou plus vieux. Ou par exemple, CVE-2009-1527 qui touche que le 2.6.29.

              Et j'ai pris juste une paire d'exploit au pif dans la liste des CVEs, j'ai peut être eu de la chance, mais je suis pas sur.

          • [^] # Re: HAHA

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

            C'est très intéressant un serveur où tu laisses un noyau troué pour ne pas avoir à le relancer…

            • [^] # Re: HAHA

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

              C'est très intéressant un serveur que tu redémarres, donc indisponibilité et donc pas terrible du tout, pour mettre à jour un noyau alors qu'il n'y a pas eu de trou de sécurité et que donc c'est inutile pour toi.

          • [^] # Re: HAHA

            Posté par  . Évalué à 0.

            C'est très intéressant un serveur que tu dois redémarrer toutes les 2 semaines pour une mise à jour du noyau…

            Bof, et alors? Il met pas 45 minutes pour redémarrer. Après je le redémarre pas toutes les deux semaines forcément, ça peut être plus ou moins, mais ça apprend plein de choses de faire tout à la main.

            Écrit en Bépo selon l’orthographe de 1990

            • [^] # Re: HAHA

              Posté par  . Évalué à 3.

              ça apprend plein de choses de faire tout à la main.

              Sur un serveur ?
              Je suppose que tu parles d'une machine perso. Dans ce cas effectivement aucun problème. Et dans ce cas on précise « serveur perso » sauf à vouloir embrouiller volontairement les gens.

            • [^] # Re: HAHA

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

              mais ça apprend plein de choses de faire tout à la main.

              Oui, on peut tout faire à la main, même à manger, faire sa maison et son lit, et construire ses moyens de transports.
              Si tu as le temps.

              Perso, je ne sais pas comment tu fais, mais moi je n'ai pas le temps de tout faire à la main.
              Alors quand on peut ne pas le faire… Surtout sur de la prod.
              J'espère qu'on ne te paye pas pour perdre ton temps à apprendre des choses si peu utiles, sinon il y a de quoi râler de la part de celui qui paye si tu ne l'as pas mis au courant de ce que tu fais.

          • [^] # Re: HAHA

            Posté par  . Évalué à 1.

            À moins d’utiliser ksplice.

            • [^] # Re: HAHA

              Posté par  . Évalué à 5.

              De l'utilité de lire les autres messages avant de poster.

              « 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: HAHA

                Posté par  . Évalué à 1.

                Contrairement à l’autre message qui mentionne ksplice, le mien lie vers le paquet de l’AUR. Il était bien question d’Arch en particulier, au début de la discussion, et ce paquet permet de l’y utiliser.

                • [^] # Re: HAHA

                  Posté par  . Évalué à 2.

                  vu les commentaires, ça n'a pas l'air de fonctionner très bien…

                  « I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

    • [^] # Re: HAHA

      Posté par  . Évalué à 0.

      uname -a
      Linux machin 3.9.2 #1 SMP Sat May 18 11:17:11 CEST 2013 x86_64 GNU/Linux
      zgrep CONFIG_PERF_EVENTS /boot/config-*
      /boot/config-3.9.2:CONFIG_PERF_EVENTS=y

    • [^] # Et avant une semaine il était où votre arch linux ?

      Posté par  . Évalué à -6.

      Mon serveur sous Arch Linux est sous Linux 3.9 depuis au moins une semaine.

      Et avant une semaine il était où votre arch linux ?
      Je vous demande çà parce que je pense que pendant tout ce temps là, ils avaient bien le temps de se balader du côté de chez vous…
      (bon c'est vrai qu'il faut avoir un accès à votre machine mais quand même…)

  • # ArchLinux non affecté ?

    Posté par  . Évalué à 2.

    Apparemment mon installation n'est pas impactée, avec un noyau vanilla :

    % uname -r
    3.7.7-1-ARCH

    % zgrep CONFIG_PERF_EVENTS /proc/config.gz
    CONFIG_PERF_EVENTS=y

    gcc --version
    gcc (GCC) 4.8.0 20130502 (prerelease)

    % gcc -O2 semtex.c && ./a.out
    [1] 16558 killed ./a.out

  • # petites precisions

    Posté par  . Évalué à 0.

    Juste pour répondre aux quelques commentaires:

    _La debian est peut être impacté, je ne sais pas, mais elle présente le CVE dans son DSA donc j'imagine que c'est utile.
    _Concernant la solution de regarder /proc/config.gz, ca vient pas de moi, je l'ai lu et la machine que j'ai utilisé pour constater tout ça est une debian squeeze équipé d'un noyau 3.4.4 avec /proc/config.gz présent (un peu de pub pour mon nouveau firewall qui marche très bien http://www.globalscaletechnologies.com/t-dreamplugdetails.aspx )

    Je regarderais sur ma debian stock x86 mais il me semblait que config.gz etait present (sur squeeze en tout cas)

    Voila. Happy patching ;)

    • [^] # Re: petites precisions

      Posté par  . Évalué à -10.

      Le fait de présenter une CVE sous entend que le risque existe. Cela ne veut pas dire qu'il est impacté bien sûr.

      Pour votre pub, c'est de l'ASP.NET votre site ? Non ? :D

  • # Silent patching

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

    Je ne comprends pas vraiment l'histoire.

    1. Les gens qui ont commité le fix en Avril dans le trunk du noyau savaient qu'ils corrigeaient une faille de sécurité ou pas?

    L'article dit que le patch existe depuis quelque temps mais si il n'y a pas d'annonce de faille de sécurité, je comprends que les distributions ne poussent pas les utilisateurs à faire une mise à jour de noyau sur leur version "stable".

    1. Le gars qui soit-disant publie l'exploit car il son joujou est cassé dans le trunk. C'est plus qu'étrange son excuse, puisque la majorité des distributions en production auraient continué à avoir un noyau vulnérable, non ?
    • [^] # Re: Silent patching

      Posté par  . Évalué à 4.

      b) C'est tres frequent dans le monde de la vente d'exploits, il n'a rien fait d'etonnant. VUPEN a fait de meme il y a 2 semaines quand on a corrige 2 bugs trouves en interne mais qu'ils avaient deja trouve il y a longtemps et exploite.

      • [^] # Re: Silent patching

        Posté par  . Évalué à 3.

        Bon je te pose la question à toi mais j'aurais pu plus haut:

        C'est légal le commerce d'exploit??
        Parce qu'on peut toujours parler de simple programme ou démonstration, mais le patch de correction et quelques explications seraient aussi bien, alors comment justifier la non intention de nuire?

        • [^] # Re: Silent patching

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

          C'est légal le commerce d'exploit??

          C'est leur utilisation pour pénétrer ou saboter un système qui ne t'appartient pas qui est illégale. Un peu comme les armes quoi.

          Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

          • [^] # Re: Silent patching

            Posté par  . Évalué à -1.

            Ca depend ou tu vis, en Allemagne par exemple il est interdit de vendre des exploits.

            • [^] # Re: Silent patching

              Posté par  . Évalué à -7.

              Ca depend ou tu vis, en Allemagne par exemple il est interdit de vendre des exploits.

              Et en donner c'est autorisé ?
              (donner ce n'est pas vendre contre rémunération)

        • [^] # Re: Silent patching

          Posté par  . Évalué à 3.

          Même les boîtes comme HP suivent le marché des exploits pour leurs solutions de sécurité comme Fortify, donc j'imagine ça comme une grande Bourse avec d'un côté les éditeurs d'antivirus et autres sociétés et de l'autre, bin les mafias diverses et variées.

          • [^] # Re: Silent patching

            Posté par  . Évalué à 10.

            une grande Bourse avec d'un côté les éditeurs d'antivirus et autres sociétés et de l'autre, bin les mafias diverses et variées.

            Mais y a qui de l'autre côté ? (humour)

        • [^] # C'est légal le commerce d'exploit? J'en doute

          Posté par  . Évalué à 10.

          C'est légal le commerce d'exploit?

          A ma connaissance en France l'usage ou l'incitation à l'usage de moyen permettant de s'introduire dans un système informatique est illégal…

          " Le fait, sans motif légitime, d'importer, de détenir, d'offrir, de céder ou de mettre à disposition un équipement, un instrument, un programme informatique ou toute donnée conçus ou spécialement adaptés pour commettre une ou plusieurs des infractions prévues par les articles 323-1 à 323-3 est puni des peines prévues respectivement pour l'infraction elle-même ou pour l'infraction la plus sévèrement réprimée "
          Code pénal - Article 323-3-1 | Legifrance

          • [^] # Re: C'est légal le commerce d'exploit? J'en doute

            Posté par  . Évalué à 1.

            Me demande pourquoi ce message est moinssé à fond les manettes, vu que pour le coup il est plutôt pertinent.

            • [^] # Re: C'est légal le commerce d'exploit? J'en doute

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

              kadalka est trolleur professionnel (mais contrairement à moi, il tape surtout dans le négatif) et commence à -10 vu la merde (ce n'est pas moi qui le dit, mais les utilisateurs de ce site) qu'il raconte d'habitude. La, en fait, il a déjà eu plein de "pertinent" sur ce commentaire.

          • [^] # Re: C'est légal le commerce d'exploit? J'en doute

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

            Tu as oublié de graisser la partie qui rend légal le commerce d'exploit : sans motif légitime. Toutes boites/labos bossant dans la sécurité, ou disposant d'au moins une personne s'assurant de la sécurité de son SI, peut invoquer un motif légitime pour acheter des exploits.

            • [^] # Re: C'est légal le commerce d'exploit? J'en doute

              Posté par  . Évalué à -10. Dernière modification le 20 mai 2013 à 21:50.

              Tu as oublié de graisser la partie qui rend légal le commerce d'exploit

              C'est volontaire, car je suis vu comme un trolleur professionnel…
              Il faut décourager la légitimité, même chez les antivirus.
              (Faut bien encourager Linux au détriment de windows… :P)
              [Ah oui, c'est vrai que les rootkits…]

              • [^] # Re: C'est légal le commerce d'exploit? J'en doute

                Posté par  . Évalué à 1.

                Il faut décourager la légitimité, même chez les antivirus.

                Je comprend pas bien ce que tu veux dire…

                Écrit en Bépo selon l’orthographe de 1990

                • [^] # Re: C'est légal le commerce d'exploit? J'en doute

                  Posté par  . Évalué à -10.

                  Il faut décourager la légitimité, même chez les antivirus.

                  Je comprend pas bien ce que tu veux dire

                  C'est une vanne : il me reproche de ne pas graisser. [Je lui dit que c'est volontaire :D]
                  Je sous entends que je ne veux pas engraisser les fabricants d'antivirus qui permettent indirectement à M$ Window$ de vivre.
                  Si Window$ est complétement vulnérable, personne n'en voudra…
                  Si il est interdit de faire des recherches dans le domaine des antivirus, et pas d'autre chose, Windows tombera facilement…

                  • [^] # Re: C'est légal le commerce d'exploit? J'en doute

                    Posté par  . Évalué à 2.

                    Si il est interdit de faire des recherches dans le domaine des antivirus, et pas d'autre chose, Windows tombera facilement…

                    Les virus, c'est pas que pour Windows.

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

                    • [^] # Re: C'est légal le commerce d'exploit? J'en doute

                      Posté par  . Évalué à -9.

                      Les virus, c'est pas que pour Windows.

                      LOL
                      J'avais dit que c'était une vanne…

                      Tout système informatique risque d'être infecté par un code malveillant.
                      (rootkit, spyware, backdoor, worms, virus of course, etc.)

          • [^] # Re: C'est légal le commerce d'exploit? J'en doute

            Posté par  . Évalué à -3.

            Ben sachant que VUPEN fait cela de maniere ouverte, avec l'assentiment du gouvernement francais(indice: ils n'ont que des employes francais…), je me permettrai de dire qu'en pratique c'est pas le cas.

        • [^] # Re: Silent patching

          Posté par  . Évalué à 1.

          C'est légal le commerce d'exploit??

          Ca depend a qui tu les vends. Les organisations qui font ca de maniere ouverte bossent generalement avec les gouvernements, ca aide :)

          Et puis on trouve plein de boites de secu qui ne vendent pas l'exploit en lui-meme mais le correctif, juste pour leur clients. On peut trouver ca pas gentil (suivant sa morale) mais ca va etre dur de prouver que c'est illegal.

          • [^] # Re: Silent patching

            Posté par  . Évalué à 3.

            C'est ce que je veux dire: le correctif, même avec explications sur le possible exploit, tu pourrais dire que c'est à valeur éducative. Si tu veux ne le vendre qu'à tes clients, c'est un business comme un autre (moral ou pas, c'est une autre affaire).

            Mais vendre un code qui n'a d'autres utilisations possibles que d'entrer illégalement sur un serveur tierce, je vois difficilement comment on peut justifier ça. C'est pas juste vendre une arme, c'est une tête chercheuse avec cible déjà entrée.

            • [^] # Re: Silent patching

              Posté par  . Évalué à 0.

              C'est discutable.
              Faut bien verifier que le patch corrige le probleme, non? Il te faut l'exploit pour 1) prouver que le probleme existe 2) prouver que le probleme est corrige.

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

              • [^] # Re: Silent patching

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

                Pas forcément : par définition, on sait qu'un buffer non maîtrisé peut amener à tout et n'importe quoi.
                1) est donc de voir que tu tapes pas la où il faut
                2) est donc de voir que tu ne tapes plus
                C'est ce qui a été fait sur le GIT si j'ai bien compris (la personne ne savait pas forcément que c'était utilisable en vrai)

                Pas besoin de prouver que tu passes root pour devoir corriger ce type de problème, il faut le corriger dans tous les cas.
                Par contre, pour sortir un CVE, il faut prouver que ça craint sinon on ne s'en sort plus (c'est simple, tu rebootes toutes les heures à partir du GIT, ou alors tu es noyé dans le flot et ne regardes plus), et donc la il faut ton 1) et 2).

                Le hic est que ça prend 1000x plus de temps, et que pendant que certains s'amusent à faire un OS blindé inutile car le temps passé est sur l'écriture de CVE pour chaque patch, d'autres font un OS utile et utilisé avec parfois une faille mais pas tant que ça en fait.
                Ca s'appelle un compromis (entre sécurité et fonctionnalité).

                • [^] # Re: Silent patching

                  Posté par  . Évalué à 1.

                  Pas besoin de prouver que tu passes root pour devoir corriger ce type de problème, il faut le corriger dans tous les cas.

                  Ben si. Si tu veux vendre un patch comme resolvant une elevation de privilege, faut bien prouver qu'il ya une elevation de privilege. Si ca fait juste un segfault, personne ne va acheter le patch.

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

                  • [^] # Re: Silent patching

                    Posté par  (site web personnel) . Évalué à 2. Dernière modification le 20 mai 2013 à 08:17.

                    J'ai zappé la partie "vente" du thread, forcément du coup je raconte n'importe quoi ou plutôt je te rejoins. Je nuancerai juste en disant que si tu es responsable, tu fais alors un logiciels closed-source avec obfuscation qui fait juste un appel root à la con pour démontrer en essayant d’empêcher le client de pouvoir l'utiliser pour autre chose.

                  • [^] # Re: Silent patching

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

                    Un segfault peut aussi induire un DoS, et un DoS est un souci de sécurité. La sécurité vise à assurer la disponibilité et l'intégrité du SI entre autres choses. Si ton SI ( on va dire celui d'une agence de recrutement ) ne marche pas car un petit malin a mis un cv qui fait planté ton système, tu perds la disponibilité, don cdu pognon. Et ça, c'est pas bon(tm). Ensuite, bien sur, une elevation de privilége en root, ça fait tout de suite plus peur. "oh attention, quelqu'un va devenir root et à partir de la, envoyer du spam, ou piquer votre base de données de cv".

                    Curieusement, ce genre d'argument pour windows xp ne marche pas pour faire migrer les gens vers un autre OS bureautique, ce qui montre que les gens ont un modèle mentale spécifique des attaques.

                  • [^] # Re: Silent patching

                    Posté par  . Évalué à -4.

                    Bien souvent tu sais sans devoir le faire si le probleme est une elevation de privilege. Tu regardes la primitive que le bug te donne (disons par exemple la possibilite d'ecrire 4 bytes n'importe ou dans le processus) et tu sauras deja dans 90% des cas ce que tu as, sans avoir besoin d'ecrire une ligne de code.

              • [^] # Re: Silent patching

                Posté par  . Évalué à -4.

                Faut comprendre ce qu'est un exploit :

                • Pour une elevation de privilege, un exploit te fera executer du code a toi sur la cible
                • Pour un DoS un exploit crashera le systeme

                Pour verifier le patch, tout ce dont tu as besoin est d'un bout de code qui cause le probleme, typiquement pour une elevation de privilege t'auras un crash. T'as pas besoin d'avoir un exploit complet qui s'occupe de gerer ASLR, NX, faire du ROP et executer ton code.

    • [^] # Re: Silent patching

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

      Les gens qui ont commité le fix en Avril dans le trunk du noyau savaient qu'ils corrigeaient une faille de sécurité ou pas?

      C'est assez délicat de savoir si tu as un truc exploitable ou pas dans la plupart des cas. Même sur des failles simples ( genre usage de /tmp avec un nom un peu prévisible ), tu passes du temps à essayer de voir si tu as un scenario pour monter une attaque pour pas apparaitre comme celui qui dit de la merde et qui s'affole sans savoir de quoi il parle.

      Et les attaques les plus simples ( genre buffer overflow ) sont de nos jours assez bien comprises et anticipés ( au moins dans le code du kernel ), donc il reste que les cas les plus compliqués qui sont dur à évaluer.

  • # Quel est le risque ?

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

    Est-ce que la vulnérabilité est depuis une session locale ou distante ?
    Est-ce qu'un firewall qui bloque tous les services permet de protéger la machine depuis internet ?
    Dans ce dernier cas, on a quelques répits avant d'être obligé de faire une (grosse) mise à jour.

  • # Hoax ?

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

    C'est marrant,on dirait que cette annonce est un Hoax… Désolé, mais c'est la première impression que j'en ai.

    Pas besoin d'être un pro pour aider la communauté Débiane : utilisez simplement apt-p2p

    • [^] # Re: Hoax ?

      Posté par  . Évalué à 9.

      pour ma part, ca marche : wget … ; gcc -O2 machin.c ; ./a.out ; id -> root ; ca n'a rien d'un hoax.

      • [^] # Re: Hoax ?

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

        Ta distro n'a pas encore publié un noyau patché ? Tu utilises quoi ?

        • [^] # Re: Hoax ?

          Posté par  . Évalué à 2.

          c'est une debian wheezy 64 bits ; pas tout a fait à jour. Ne me demande pas trop pourquoi, ca m'étonne moi-même.

      • [^] # Re: Hoax ?

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

        ...$ grep CONFIG_PERF_EVENTS /boot/config-3.5.0-30-generic 
        CONFIG_PERF_EVENTS=y
        
        

        … mais …

        ...$ wget http://fucksheep.org/~sd/warez/semtex.c && gcc -O2 semtex.c && ./a.out
        ...
        a.out: semtex.c:51: sheep: Assertion `!close(fd)' failed.
        
        

        Cela signifie-t-il que mon noyau … "est cool" ? :)

        ...$ uname -a
        Linux auroid 3.5.0-30-generic #51-Ubuntu SMP Tue May 14 18:47:48 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux 
        
        
  • # Dépêche bookmark

    Posté par  . Évalué à 10.

    Merci pour l'info mais je trouve la dépêche un peu vide : « Ah! Au fait il y a un exploit root sur Linux… » Il n'y a pas vraiment de détails sur la nature de la faille ni son histoire…

    • [^] # Re: Dépêche bookmark

      Posté par  . Évalué à 5.

      À la décharge de l'auteur et les modérateurs, il y a justification à publier plus vite: la faille est mal rapportée mais déjà exploitée.
      "La plupart des distros" ne couvre peut-être pas tout le monde ici, et je pense qu'il faut voir plutôt une manière de donner une alerte plutôt qu'un article technique.

    • [^] # Re: Dépêche bookmark

      Posté par  . Évalué à 10.

      On va appeler ca un "choix éditorial":
      * Soit tu publies la news au plus vite avec le minimum d'informations (savoir si on est impacté, le numéro du CVE pour surveiller les security advistory de sa distrib)
      * Soit tu fais un papier détaillé, sachant que je ne peux pas (légalement) traduire bêtement le papier de ars pour le publier ailleurs (j'avais posé la question lors du dossier hb gary et… c'est compliqué…), qui sera plus long et plus intéressant pour les spécialistes du noyau mais qui fera chier la majorité des gens

      Je fais donc un papier pour la majorité des gens sachant que:
      * Les spécialistes sont a 99% sur la liste lkml et sont déjà au courant
      * Les 1% restant sont capable de suivre les liens de ars pour avoir plus d'infos.
      * La majorité des gens (et aussi un peu moi) se foutent des détails du bug en fait, on a juste besoin de savoir qu'on est POWNABLE.

      Sinon pour un autre commentaire, je ne fais pas une news sur chaque CVE (vu le nombre…), il y a un certain nombre de conditions:
      * uniquement root exploit local ou remote
      * un exploit est dispo et LIVE
      * Le patch n'existe pas encore
      * Ou le patch existe mais n'est pas forcement backporté sur toute les distrib.

      Ça reste relativement rare d'avoir toutes ses conditions, et je n’hésiterais pas a refaire une news si le cas se représente :)

      Voili!

  • # résolu dans Mageia

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

    Après vérification auprès de l'équipe, ce problème n'atteint pas la Mageia 3, qui vient de sortir, car fonctionnant sur un kernel 3.8.13, et pour la Mageia 2, kernel 3.4.* un patch a été publié dans les mises à jour.

  • # root-exploit-sur-les-noyaux-linux

    Posté par  . Évalué à -3. Dernière modification le 20 mai 2013 à 01:35.

    gzip: /proc/config.gz: No such file or directory

    • [^] # Re: root-exploit-sur-les-noyaux-linux

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

      Sur des Debian GNU/Linux ou Ubuntu Server :

      $ grep CONFIG_PERF_EVENTS /boot/config*
      CONFIG_PERF_EVENTS=y

      (sur des 2.6.32-5-686, 2.6.32-5-686-bigmem, 2.6.38-*-server, 3.0.0-*-server, 3.2.0-*-686-pae, 3.2.0-*-generic, 3.8-2-686-pae, …)

      • [^] # Re: root-exploit-sur-les-noyaux-linux

        Posté par  . Évalué à 1.

        http://packages.qa.debian.org/l/linux.html

        old-bpo    3.2.41-2+deb7u2~bpo60+1 
        stable     3.2.41-2 
        stable-sec 3.2.41-2+deb7u2 
        testing    3.2.41-2 
        unstable   3.8.13-1 
        
        

        Apparemment, en debian stable c'est corrigé mais en testing ? Pourquoi est-ce que le fix n'est pas présent sur la branche testing ?

        Parce qu'on attend la 3.8 de unstable qui arrive pas ?

        Parce que quand on est en testing on doit aussi avoir une référence à stable-sec dans son sources.list de sorte que le paquet corrigé a priorité ? C'est quoi la ligne qui correspond ? Moi, j'ai ça, et je vois pas de 3.2.41-2+deb7u2 dans aptitude.

        deb http://mirrors.ircam.fr/pub/debian/ testing main non-free
        deb http://security.debian.org/ testing/updates main non-free
        deb http://ftp.debian.org/debian experimental main
        
        
  • # root-exploit-sur-les-noyaux-linux

    Posté par  . Évalué à -6.

    gzip: /proc/config.gz: No such file or directory

  • # Rien à foutre

    Posté par  . Évalué à 2. Dernière modification le 20 mai 2013 à 11:41.

    J’ai un kernel GRSec de Nazi, l’exploit se fait démonter la gueule :

    May 17 08:13:48 xxxx kernel: [2906887.474305] grsec: From 178.23.33.193: denied untrusted exec (due to not being in trusted group and file in non-root-owned directory) of /home/arcaik/a.out by /home/arcaik/a.out[zsh:2727] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/zsh4[zsh:2717] uid/euid:1000/1000 gid/egid:1000/100
    
    
    • [^] # Re: Rien à foutre

      Posté par  . Évalué à 10.

      Tu aurais monté ton /home en noexec, tu aurais eu un résultat similaire, ça ne montre pas grand chose.

      « 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

Suivre le flux des commentaires

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