Nouvelle faille dans les noyaux 2.4 et 2.6

Posté par  (site web personnel) . Modéré par Mouns.
Étiquettes :
0
10
jan.
2005
Noyau
Une nouvelle faille vient d'être découverte dans les noyaux 2.4 et 2.6. La fonction système uselib() (qui permet de sélectionner une bibliothèque partagée d'après son fichier binaire) contient une faille qui permet à un utilisateur mal intentionné de s'approprier les privilèges de l'utilisateur root. Cette faille n'est pas exploitable à distance, mais seulement par une personne possédant déjà un compte sur la machine. Cette faille concerne les noyaux de version 2.4 (<= 2.4.29-pre3) et 2.6 (<= 2.6.10). La faille a été corrigée dans le noyau 2.4.29-rc1, et n'apparaît pas dans les noyaux 2.6-ac. La plupart des distributions proposent déjà des noyaux patchés ; pour les autres, il est conseillé de patcher au plus vite.

Aller plus loin

  • # La faille ou le Patch ?

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

    et n'apparaît pas dans les kernel 2.6-ac

    Qu'est-ce qui n'apparaît pas dans les 2.6-ac ?

    • [^] # Re: La faille ou le Patch ?

      Posté par  . Évalué à 8.

      Le patch http://dev.gentoo.org/~dsd/gentoo-dev-sources/release-10.03/dist/11(...) ( "Le patch (fourni par gentoo)" ).

      Pour info, 2.6-ac c'est :
      http://www.fr.kernel.org/pub/linux/kernel/people/alan/(...)

      Ce patch n'est pas en upstream (ou chez Alan) car le patch a été discuté. La méthode utilisée n'est pas appréciée par Linus et Alan notament.

      • [^] # Re: La faille ou le Patch ?

        Posté par  . Évalué à -1.

        Pourquoi faire un patch aussi long ?

        sed -i "s/do_brk/do_brk_locked/" *

        :)

        Dam

        • [^] # Re: La faille ou le Patch ?

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

          Il faut aussi penser a définrii la fonction avec activation d'un sémaphore, appel a do_brk, désactivation du sémaphore ;)

          Ceci dit : avec des amis, on a testé l'exploit sur beaucoup de machines, il n'a fonctionné sur aucune, alors que tous les noyaux étaient sensé être vulnérables....

          • [^] # Re: La faille ou le Patch ?

            Posté par  . Évalué à 3.

            Je viens de tester l'exploit sur deux machines différentes potentiellement vulnérables :

            Sur une Debian sid avec noyau 2.6.8.1 et gcc 3.3.5 (testé aussi sur gcc-2.95 et gcc-3.0 : erreurs similaires)
            $ gcc -O2 -fomit-frame-pointer exploit.c -o exploit
            exploit.c: Dans la fonction « scan_mm_start »:
            exploit.c:426: error: storage size of `l' isn't known
            exploit.c:426: error: storage size of `l' isn't known
            exploit.c: Dans la fonction « check_vma_flags »:
            exploit.c:546: attention : utilisation obsolète d'étiquette à la fin d'une déclaration composée

            Bref, ça ne compile pas...

            Sur une RedHat 8.0 avec noyau 2.4.18-14 et gcc 2.96 la compilation s'effectue sans warning mais l'exploit ne "fonctionne" pas :
            [+] SLAB cleanup
            child 1 VMAs 65526
            child 2 VMAs 65526
            child 3 VMAs 65526
            child 4 VMAs 65526
            child 5 VMAs 65526
            child 6 VMAs 65526
            child 7 VMAs 64593
            [+] moved stack bfffe000, task_size=0xc0000000, map_base=0xbf800000
            [+] vmalloc area 0x3e400000 - 0xbc4c1000
            Wait... \
            [-] FAILED: try again (Cannot allocate memory)
            Killed

            Bref, avez vous trouvé une machine où l'exploit fonctionne ?
            Pas très concluant à mon avis, enfin je ne suis pas développeur donc je ne me prononcerai pas sur l'efficacité réelle de ce code.

            • [^] # Re: La faille ou le Patch ?

              Posté par  . Évalué à 6.

              Sous debian un nom de structure a changé dans le fichier include /usr/include/asm/ldt.h :

              i.e. modify_ldt_ldt_s est à remplacer par user_desc (ligne 430 de l'exploit ) .

              Mais cela n'enlève rien à la pertinence du commentaire suivant....

              W.

              • [^] # Re: La faille ou le Patch ?

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


                nico@xavia:~/Documents $ ./test

                child 1 VMAs 0
                [+] moved stack bfffe000, task_size=0xc0000000, map_base=0xbf800000
                [+] vmalloc area 0xe0000000 - 0xffffd000

                [-] FAILED: try again (-f switch) and again (Cannot allocate memory)
                Processus arrêté


                Sous ubuntu avec la correction pour la variable renommer.
                La charge est montée a 8 (ce qui n'a pas deranger xmms qui a continuer de lire un flux internet) et le processus s'est fait jeter.

                • [^] # Re: La faille ou le Patch ?

                  Posté par  . Évalué à 7.

                  "Les États-Unis sont le seul pays à être passé de la barbarie à la décadence sans connaître la civilisation." -- Albert Einstein

                  Ce n'est pas de Einstein, ça date d'avant et c'est de George Bernard Shaw (un écrivain irlandais), et parfois attribué à Oscar Wilde (un anglais) !

                  Ca craint, les fausses citations...

                  • [^] # Re: La faille ou le Patch ?

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

                    Bon, je vais mettre le quatuor d'auteur comme ça, il n'y aura personne qui me repetera ça 2 milliard exposant 9999999999 trilliard de fois !

                    • [^] # Re: La faille ou le Patch ?

                      Posté par  . Évalué à 4.

                      Einstein, Shaw, Wilde : ça ferait pas plutôt un trio ?

                      Sinon, Einstein étant légèrement postérieur aux deux autres, je subodore que ces derniers ont de meilleures chances. Ensuite, Shaw semble plus enclin à ce genre de remarque. Mais bon, Wilde et Shaw sont aussi tous deux très prolifiques en aphorismes.

                      À la limite, écrit le en latin, ça pourra passer pour du Jules César...

                  • [^] # Re: La faille ou le Patch ?

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

                    Oscar Wilde (un anglais) !

                    Comment ! Non je m'insurge, Oscar Wilde était lui aussi irlandais comme James Joyce ou Samuel Beckett pour ne citer ques plus connus. Tu sais que tenir ce genre de propos pourrait aux yeux d'un irlandais être assimilé à un troll ? :o)

                • [^] # Re: La faille ou le Patch ?

                  Posté par  . Évalué à 2.

                  Bon, c'est juste une idée :

                  sur ce forum (http://forums.arenhack.com/viewtopic.php?p=16466(...)) le posteur a mis des petits smileys près de chaque boucle (qui ont l'air infinies). C'est peut être les fameuses protections anti script kiddies ?

                  W.

                • [^] # Re: La faille ou le Patch ?

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

                  Mandrake 10.2 cooker avec kernel 2.6.9, j'ai ceci :

                  [rapsys@phoenix-team tmp]$ ./test

                  child 1 VMAs 0
                  [+] moved stack bfffe000, task_size=0xc0000000, map_base=0xbf800000
                  [+] vmalloc area 0xf0000000 - 0xffffd000
                  Segmentation fault (core dumped)
                  [rapsys@phoenix-team tmp]$

                  ça marche même pas c pas drôle...

                • [^] # Re: La faille ou le Patch ?

                  Posté par  . Évalué à 1.

                  Vous avez jamais pensé que les proof of concept sont pas forcément efficaces mais juste la pour donner l'idée de la faille et comment elle fonctionne ?

          • [^] # Re: La faille ou le Patch ?

            Posté par  . Évalué à 10.

            D'habitude les gens qui releasent une vulnerabilite avec un exploit attache changent 2-3 trucs dans l'exploit pour que les gens qui veulent vraiment comprendre se rendent compte que la faille est bien la(ils trouveront les 2-3 erreurs), mais en meme temps empecher que les script kiddies qui n'y comprennent rien n'en profitent pour mettre le bordel.

            Donc ce n'est pas si etonnant que ca si tu as simplement compile l'exploit fourni et essaye de le lancer.

            • [^] # Re: La faille ou le Patch ?

              Posté par  . Évalué à 8.

              Merci pour "script kiddies qui n'y comprennent rien" ça fait toujours plaisir :)
              Et merci aussi pour l'info, j'ai toujours pensé qu'un exploit devait être fonctionnel pour pouvoir tester si la machine est vulnérable ou si le patch que l'on vient d'appliquer a résorbé la faille... enfin apparemment je me trompe.
              C'est dommage pour les admins (comme moi) qui font leur possible pour que les machines de prod soient le plus "blindées" possible mais qui n'ont pas assez de compétences pour décrypter tout le code d'un exploit aussi complexe.

              • [^] # Re: La faille ou le Patch ?

                Posté par  . Évalué à 10.

                Merci pour "script kiddies qui n'y comprennent rien" ça fait toujours plaisir :)

                T'etais pas vise, je parlais de la raison pour laquelle les auteurs d'exploit font cela. Tous les gens qui ne comprennent pas ce code ne sont pas forcement des script kiddies ne comprenant rien, mais les script kiddies en font partie.

                Et merci aussi pour l'info, j'ai toujours pensé qu'un exploit devait être fonctionnel pour pouvoir tester si la machine est vulnérable ou si le patch que l'on vient d'appliquer a résorbé la faille... enfin apparemment je me trompe.

                Ben oui tu te trompes, ces exploit sont la pour montrer que le gars ne raconte pas n'importe quoi, qu'il maitrise, etc... et convaincre les developpeurs du code qu'il y a vraiment un probleme. Les administrateurs ne sont pas la cible de ce code.

            • [^] # Re: La faille ou le Patch ?

              Posté par  . Évalué à -7.

              Avec windows, il n'as pas de scripts kiddies pour les "neuneux" car ...
              T'as un beaucoup virus.

              C'est bien Windows pour la sécurité, ce n'est pas élitiste.

  • # Bugs et noyau

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

    Vu que généralement avec ce genre de sujets on va vite gloser sur les vulnérabilités d'Internet Explorer et défendre le modèle de sécurité supérieur de Linux, je vous laisse apprécier la petite histoire de Brad Spengler (mainteneur de grsecurity) postée sur bt. A mon avis cela montre deux choses: il n'y a pas vraiment de prise de conscience sécurité dans le noyau Linux. Et ensuite que le modèle "bazar" de Torvalds - "distribuez vite et souvent " , je cite Eric S. Raymond - ne convient pas trop à des kernels sécurisés à leur sortie (je parle bien des toutes dernières versions du noyau).


    Let me begin by giving you a timeline:

    December 15th: I send Linus a mail with a subject line of
    "RLIMIT_MEMLOCK bypass with locked stack" December 27th: The PaX team sends Linus a mail with a subject line of "2.6.9+ mlockall/expand_down DoS by unprivileged users" January 2nd: The PaX team resends the previous mail to Linux and Andrew Morton

    Between December 15th and today, Linus has committed many changes to the kernel. Between January 2nd and today, Andrew Morton has committed several changes to the kernel. 3 weeks is a sufficient amount of time to be able to expect even a reply about a given vulnerability. A patch for the vulnerability was attached to the mails, and in the PaX team's mails, a working exploit as well. Private notification of vulnerabilities is a privilege, and when that privilege is abused by not responding promptly, it deserves to be revoked.

    Using 'advanced static analysis': "cd drivers; grep copy_from_user -r ./* | grep -v sizeof", I discovered 4 exploitable vulnerabilities in a matter of 15 minutes. More vulnerabilities were found in 2.6 than in 2.4. It's a pretty sad state of affairs for Linux security when someone can find 4 exploitable vulnerabilities in a matter of minutes. Since there was no point in sending more vulnerability reports when the first hadn't even been responded to, I'm including all four of them in this mail, as
    well as a POC for the poolsize bug. The other bugs can have POCs written for just as trivially. The poolsize bug requires uid 0, but not any root capabilities. The scsi and serial bugs depend on the permissions of their respective devices, and thus can possibly be exploited as non-root. The scsi bug in particular has a couple different attack vectors that I haven't even bothered to investigate. Some of these bugs have gone unfixed for several years.
    The PaX team discovered the mlockall DoS. It has been fixed in PaX for 2 years. I have attached their mail and exploit code.

    I'd really like to know what's being done about this pitiful trend of Linux security, where it's 10x as easy to find a vulnerability in the kernel than it is in any app on the system, where isec releases at least one critical vulnerability for each kernel version. I don't see that the 2.6 development model is doing anything to help this (as the spectrum of these vulnerabilities demonstrate), by throwing experimental code into the kernel and claiming it to be "stable". Hopefully now these vulnerabilities will be fixed in a timely manner.

    • [^] # Re: Bugs et noyau

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

      Un petit lien vers l'original ?

      Merci,

    • [^] # Re: Bugs et noyau

      Posté par  . Évalué à 9.

      En tant que lecteur depuis 5 ans de la liste de diffusion du noyau, je peux dire que la sécurité a toujours été prise très au sérieux par Linus, Alan ou Andrew. Il suffit de regarder l'historique des corrections de trous de sécurité.

      La première chose que pouvait faire ce Monsieur, c'est de poster son message sur la liste de diffusion du noyau, ce qu'il n'a pas fait. Linus et Andrew reçoivent des centaines de mails, dont beaucoup de spam, donc utiliser leur adresse dans ce cas est une erreur.

      Mais quelqu'un a finalement posté ce bug sur la liste le 7 Janvier
      http://marc.theaimsgroup.com/?l=linux-kernel&m=110512844229436&(...) et Andrew a répondu le 7 Janvier
      http://marc.theaimsgroup.com/?l=linux-kernel&m=110513618706433&(...)

      Les corrections sont dans le Kernel d'Alan Cox (2.6.10-ac7), datant du 7 Janvier.

      Donc 1 jour a suffit à la prise en compte du bug, à partir du moment où il a été révélé de façon correcte.

      • [^] # Re: Bugs et noyau

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

        > Linus et Andrew reçoivent des centaines de mails, dont beaucoup de spam, donc utiliser leur adresse dans ce cas est une erreur.

        C'est vrai, ne pas savoir ça est une erreur de débutant...

        Le fait de ne pas avoir suivi la procédure (de notoriété publique) devrait empêcher de se plaindre, a fortiori en public.

        • [^] # Re: Bugs et noyau

          Posté par  . Évalué à 9.

          Pas forcement.

          Le poster sur la ML publique revient a le publier au grand jour, tout le monde aurait ete au courant avant qu'un patch soit sorti, l'envoyer sur leur e-mail (ce qui me semble tout de meme logique, j'ai du mal a imaginer que Linus & Andrew soient inondes de spam au point de ne pas pouvoir lire d'emails) et la methode "normale" selon moi.

          Ou alors ils devraient creer une ML speciale pour les alertes de securite ou tout le monde peut poster, mais seules certaines personnes peuvent lire.

          • [^] # Re: Bugs et noyau

            Posté par  . Évalué à 1.

            On peut en tout cas lui repprocher de sauter directement aux conclusions, il ne sait même pas si son mail a été lu. On dirait plutôt un post "à chaud"...

            • [^] # Re: Bugs et noyau

              Posté par  . Évalué à 2.

              Si tu lis ce qu'il a ecrit, il y a eu plusieurs mails d'envoye, c'est pas comme si il n'en avait envoye qu'un et attendu une reponse.

        • [^] # Re: Bugs et noyau

          Posté par  . Évalué à 9.

          > Le fait de ne pas avoir suivi la procédure (de notoriété publique) devrait empêcher de se plaindre, a fortiori en public.

          Aigri ou pas ce bonhomme est assez clair dans sa démarche : il a considéré qu'il faisiti une faveur ("privilege") en envoyant un courriel avec une proposition de patch jointe.

          Schizo douce, quand tu nous tiens...
          D'un coté, "on" (je ne m'inclus pas, je suis complétement tiers par rapoport aux enjeux de programmation) râle quand des chtis gars balance des exploits au grand jour tout-à-trac, et là, un gars qui adresse un mél privé se voit opposer une fin de non-recevoir....
          De l'autre, "on" (je m'inclus un peu plus : je me considére comme un prosélyte mesuré) se rengorge de nos filtres heuristico-bayesizns sur les plate-formes libres, c'est bien pour continuer à pouvoir lire le flux pertinent, non ?

          La KLM ou MLK pemet-elle d'adresser des patches en pièce sjointes ? chuis pas sûr ! (mieux : chen chais rien ?!)
          de plus, c'est peut-être la seule option pour qu'un développeur non-identifié par BitKeeper puisse adresser des patches en direct.

          Par ailleurs ce qu'il dit du traitement expérimental de la branche 2.6 me conforte un peu dans ce que je pense : c'est une 2.7 innommée et je vais m'accrocher aux branches de mon 2.4 jusqu'à ce que soit mieux en ordre ce machin là... (..;e ttant pis pour udev ;-)


          Yojik
          --
          Les Hommes se sont inventés des idôles pour cesser de réflechir.

          • [^] # Re: Bugs et noyau

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


            La KLM ou MLK pemet-elle d'adresser des patches en pièce sjointes ? chuis pas sûr ! (mieux : chen chais rien ?!)
            de plus, c'est peut-être la seule option pour qu'un développeur non-identifié par BitKeeper puisse adresser des patches en direct.

            Oui. Inférieurs en taille à 100ko. Cependant, les patches sont préférés in-line (dans le corps du message) ou à la limite, en pièce jointe ASCII 7bits, text/plain.

      • [^] # Re: Bugs et noyau

        Posté par  . Évalué à 7.

        Je me permet de compléter mon message: il y a une discussion intéressante sur linux weekly news:
        http://lwn.net/Articles/118251/(...)

        On y apprend entre autres, de la bouche de ce groupe de personne qu'ils savaient à qui envoyer l'annonce (vendor-sec, voire Alan Cox), mais qu'ils ont décidé de ne pas leur envoyer le message. Bref, il sont passés outre les responsables de la sécurité, et se plaignent après de ne pas avoir été écouté.

        • [^] # Re: Bugs et noyau

          Posté par  . Évalué à 2.

          Oui enfin la justification pour ne pas l'avoir envoye a vendor-sec est qu'apparement il y a eu une fuite sur un rapport de securite: "uselib() bug leak".

          Je pense que c'est la le vrai probleme..

          Quand a AC, officiellement ce n'est plus lui qui prend en compte les bugs de securite.

      • [^] # Re: Bugs et noyau

        Posté par  . Évalué à 3.

        > La première chose que pouvait faire ce Monsieur, c'est de poster son
        > message sur la liste de diffusion du noyau, ce qu'il n'a pas fait.

        En même temps ça se comprends qu'il n'ait pas voulu divulguer la faille avant que son fix ait été approuvé. Peut-être que la solution pour rapporter les failles de sécu est plus à chercher du côté de bugzilla.kernel.org ? Enfin j'ai pas de compte là bas donc je sais pas comment il est fichu, mais sur celui de gentoo par exemple on peut marquer un rapport comme concernant la sécurité, auquel cas il ne sera il me semble pas lisible publiquement jusqu'à résolution, ce qui est plutôt raisonnable.

    • [^] # Re: Bugs et noyau

      Posté par  . Évalué à 6.

      Joli score pour un post bien joli mais limite FUD.

      Tu prends un cas particulier et conclus que c'est globalement le "bordel" pour Linux. Or linux est sûr dans la pratique.

      Pour le problème mlockall, je ne sais pas pour toi mais je ne mets pas en place des serveurs où n'importe qui peut être root comme je ne donne pas de droit RLIMIT_MEMLOCK au premier utilisateur venu. De plus, il est inutile d'utiliser mlockall pour faire un DOS. Un "while(1) { fork() } ;" fout le bordel ou si tu n'utilises pas ulimit t'as aussi le bordel. C'est un point faible de Linux et de tous les OS actuellement.
      Notont que RLIMIT_MEMLOCK a été introduit dans Linux 2.6.9. C'est récent et il n'y a pas le feu. RLIMIT_MEMLOCK est pour les processus (jusdicieusement sélectionnés) qui ont besoin de locker de la mémoire (c-à-d non swapable).

      Pour l'autre bug, il faut bien lire :
      - "The poolsize bug requires uid 0, but not any root capabilities. The scsi and serial bugs depend on the permissions of their respective devices, and thus can possibly be exploited as non-root. The scsi bug in particular has a couple different attack vectors that I haven't even bothered to investigate."

      Il y a faille de sécurité et faille de sécurité.
      Corriger le DOS avec mlockall a du sens si tu corriges aussi "while(1) { fork() ; }". Sinon c'est sans intérêt.

      Pour ma part, je ne comprend pas pourquoi ce bug passe en première page (ni en seconde) alors qu'il conserne le format a.out, qui n'est presque plus utilisé, et il faut avoir de la chance pour activer l'exploit.

      • [^] # Re: Bugs et noyau

        Posté par  . Évalué à 2.

        Un mail d'Alan Cox :
        De: Alan Cox
        On Fri, Jan 07, 2005 at 05:43:29PM -0500, Will Backman wrote:
        > Anyone tried the recently announced local root exploits against Fedora
        > Core? Do the stack protections and other stuff protect the Fedora
        > Kernel?

        Not in this case

        > I've manage a university shell server with many many student accounts.
        > Scared....

        Its fixed in 2.6.10-ac6 along with the following
        - DoS/oops in setsid (user triggerable) <==
        - Coda unverified user data (only if using Coda)
        - XFS unverified user data (only if using XFS)
        - Bridge ioctl (only if using bridge and already net_admin)
        - Rose ioctl (only if using rose and already net_admin)
        - SDLA firmware ioctls (only if net_admin and using sdla)

        Donc c'est déjà fixé dans la branche Alan Cox (mais ce n'est pas le même patch) depuis ac6 (le ac8 est sorti il y a 2 jours).
        On aurait pu passer 6 news en première page de plus et en une semaine seulement.
        Dans Fedora il n'y a pas BINFMT_AOUT de compilé donc il n'y a pas de risque. Je pense que beaucoup de distributions font de même.

    • [^] # Re: Bugs et noyau

      Posté par  . Évalué à 1.

      > The PaX team sends Linus a mail with a subject line of "2.6.9+ mlockall/expand_down DoS by unprivileged users" January

      C'est corrigé en upstream (post 2.6.10).
      Franchement, joli score.
      Ce qui serait intéressant de savoir, c'est si le patch proposé pouvait être utilisé tel que. Et franchement, je doute. Un peu comme le patch proposé par cette news qui n'a pas été retune et une autre "voie" a été utilisé pour trouver/corriger réellement et proprement le bug.

      Pour info, Fedora a sorti un fixe (qui corrige aussi d'autre trou de sécurité) pour FC2 et FC3 basé sur Linux 2.6.10-ac8. C'est pour les parano :
      https://www.redhat.com/archives/fedora-announce-list/2005-January/ms(...)
      https://www.redhat.com/archives/fedora-announce-list/2005-January/ms(...)

  • # plus de détails

    Posté par  . Évalué à 7.

    la suite de messages concernant le kernel 2.6 est ici pour les curieux:

    http://marc.theaimsgroup.com/?l=linux-kernel&m=110511388720709&(...)

    Linus, Alan et Marcello cherchent la meilleure façon d'implémenter la correction. On y trouve aussi des infos intéressantes: cette partie de code est très ancienne et n'est plus utilisée (à moins de faire tourner des binaires de 8 ans). Certaines personnes rapportent leur incapacité à faire fonctionner l'exploit sur le noyau 2.6 en outre.

    • [^] # Linux est-il prêt pour les failles de sécurité ???

      Posté par  . Évalué à 7.

      Même faire fonctionner une faille de sécurité sous linux est compliqué ...

    • [^] # Re: plus de détails

      Posté par  . Évalué à 2.

      Et sur le 2.4 aussi :)

      En tout cas en ce qui me concerne, l'exploit ne fonctionne pas, une fois le probleme de compilation corrigé. Comme dit plus haut, il manque peut être une partie du code qui permettrait de le faire fonctionner ... mais je reste sceptique.

      Sur ce...

      Caeies, qui manque de temps ...

      • [^] # Re: plus de détails

        Posté par  . Évalué à 3.

        pareil.
        En lisant rapidement le thread, il semble qu'il faille un 'race condition'. Donc que ca ne marche pas tout le temps..

      • [^] # Re: plus de détails

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

        Je confirne qu'il marche sur un 2.4.2x, (je sais plus quel x, c'est celui d'une fedora core1pas a jour...), sans erreur de compil avec le gcc (2.9x, je me souviens pas de ce x, mais c'est pas le meme que celui d'avant) de la woody, par contre sur un 2.6.8.1 (gentoo) ca a fait monte la charge a 13, mais c'est tout...

        Marche pas avec gcc3, meme en corrigeant l'erreur de compil

        • [^] # Re: plus de détails

          Posté par  . Évalué à -1.

          Ca méritait vraiment une première page cette news ?

          A quand la news sur les warnings à la compilation du noyau !

          2005 l'année de toutes les failles

          • [^] # Re: plus de détails

            Posté par  . Évalué à 7.

            > Ca méritait vraiment une première page cette news ?

            Perso je me demande même si de manière générale les failles méritent des niouzes. Dans l'absolu c'est important biensûr, mais est-ce que c'est le rôle de linuxfr ? Je suis pas persuadé, enfin d'autant qu'on ne peut pas être aussi réactifs que certains autres média spécialisés, ni aussi exhaustifs (des failles dans le 2.6.10, il y en a au moins 5 autres, mois importantes certes, mais quand même...). Si quelqu'un avait la mauvaise idée d'utiliser un noyau "vanilla" plus un patch occasionnel quand linuxfr en parle, il serait presque en permanence vulnérable à des failles connues par ailleurs. Alors puisque ça n'est pas viable, à quoi bon ?
            Enfin bon, ça génère des discussions sympa de temps en temps, l'intérêt est peut-être plus là.

            ...</mon_avis_perso>

  • # -as tree

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

    Pour ceux que ca interesse, pour avoir un kernel patché rapidement contre ce genre de choses plus les petits problemes mineurs de temps en temps, ya maintenant -as, maintenu par Andres Salomon.

    Andres explique notamment que debian utilisera ce patchset. Pour plus d'infos:
    http://kerneltrap.org/node/4545(...)

Suivre le flux des commentaires

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