Journal Faille de sécurité sous Linux : deni de service local

Posté par (page perso) .
Tags : aucun
11
10
déc.
2008
Une faille de sécurité a été découverte pour les versions du noyau Linux inférieures ou égales à la 2.6.27.8. L’exploit permet à un simple utilisateur d’une machine Linux quelconque de créer un déni de service local (kernel infinite loop).

La seule solution pour contrer ce type d’attaque est de mettre à jour votre système.

La faille est vue en détail ici :
http://www.tux-planet.fr/linux-atmsvc-local-denial-of-servic(...)

L'exploit à été publié ici :
http://www.milw0rm.com/exploits/7405
  • # Fork bomb

    Posté par (page perso) . Évalué à 4.

    C'est quoi la différence avec un fork bomb du type «:(){ :|:& };:» en bash ?

    C'est le fait que ce soit au niveau du kernel et que c'est encore pire ?

    Envoyé depuis mon lapin.

    • [^] # Re: Fork bomb

      Posté par (page perso) . Évalué à 10.

      la fork bomb ça se cantonne avec un simple ulimit...

      Sinon je n'ai rien vu de détaillé sur le blog tux-planet, mieux vaut se référer à la référence
      http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5(...)
      et notamment http://secunia.com/advisories/32913
    • [^] # Re: Fork bomb

      Posté par . Évalué à 3.

      Je pense que c'est surtout que c'est pas facilement contrôlable par des trucs du genre ulimit
    • [^] # Re: Fork bomb

      Posté par . Évalué à 3.

      Ça n'a juste rien à voir avec une fork-bomb : il ne fork que 8 processus par défaut, pas plus. L'important, c'est de listen(2) 2 fois le même socket ATM. Après, je ne connais pas vraiment la raison du fork, peut-être que c'est une histoire de corruption qui n'arrive que une fois que le processus a été schedulé au moins une fois, ou un truc dans le genre ...
  • # ATM

    Posté par . Évalué à 6.

    Si je comprends bien, c'est un exploit au niveau de la couche réseau ATM, si on n'a pas ce support compilé dans le noyau on est pas vulnérable non ?
    • [^] # Re: ATM

      Posté par (page perso) . Évalué à 7.

      Ce qui montre une fois de plus les limites des gros noyaux "generic" fournis par les distributions.
      • [^] # Re: ATM

        Posté par (page perso) . Évalué à 5.

        ... ou pas puisqu'il suffit de blacklister le module ATM dans ce cas.
        • [^] # Re: ATM

          Posté par . Évalué à 6.

          Si tu commences à blacklister tout les modules qui ne te servent pas, autant compiler ton propre noyau et on en revient à ce que l'on disait au dessus.
          • [^] # Re: ATM

            Posté par . Évalué à 2.

            L'un met juste un peu moins de temps que l'autre et est un peu moins l'artillerie lourde.
      • [^] # Re: ATM

        Posté par . Évalué à 2.

        Certes, mais tu proposes quoi?
        Une interface graphique conviviale et simple qui propose au tout nouvel utilisateur fraîchement arrivant de Windows de... se recompiler un noyau personnalisé? (gasp!)
        • [^] # Re: ATM

          Posté par (page perso) . Évalué à 2.

          Je dis pas que les noyaux génériques c'est nul, je dis juste que ça a ses limites. D'ailleurs, j'utilise moi même un noyau générique.
          • [^] # Re: ATM

            Posté par (page perso) . Évalué à 3.

            Il y a encore des utilisateurs qui compilent eux-mêmes leur noyau ? Je l'ai fait autrefois parce que j'en avais besoin pour je ne sais plus quoi. J'ai réessayé récemment et je ne sais plus faire (et je me décourage au bout de moins d'essais vu que config + compilation prend de plus en plus de temps) et les noyaux génériques font suffisamment bien ce dont j'ai besoin.
            • [^] # Re: ATM

              Posté par (page perso) . Évalué à 1.

              C'est vrai qu'il ne suffit malheureusement pas des trois ou quatre commandes toutes bêtes pour compiler un noyau. Même moi qui sait ce que je fais, je suis obligé d'aller voir mon mémo pour copier/coller les commandes.

              Des personnes qui utilisent un noyau qui leur est propre, il y en a beaucoup. Soit pour le plaisir d'avoir le super noyau optimisé à mort (soi-disant), soit tout simplement pour que ça fonctionne :-)
              Debian Etch sur une machine récente nécessite à coup sûr un noyau maison (ou venant des backports peut-être, je n'ai pas testé).

              Sur mes postes perso, j'ai des noyaux génériques et des noyaux perso. Tout dépend de la machine. Dans mon entreprise nous avons uniquement des noyaux perso.
              • [^] # Re: ATM

                Posté par (page perso) . Évalué à 2.



                C'est vrai qu'il ne suffit malheureusement pas des trois ou quatre commandes toutes bêtes pour compiler un noyau.


                la plupart des bonnes distribs proposent des paquets sources faciles à configurer...
              • [^] # Re: ATM

                Posté par . Évalué à 4.

                ?? make-kpkg me sort un .deb en une seule commande ...
                • [^] # Re: ATM

                  Posté par . Évalué à -1.

                  oui, mais comment l'optimiser ?
                  tu ne va pas voir dans le menu avant ,histoire d'optimiser tout ça ?
                • [^] # Re: ATM

                  Posté par (page perso) . Évalué à 1.

                  En une seule commande ? Tient donc !


                  $cd /usr/src/linux
                  $make clean && make mrproper
                  $cp ta_précédente_config-2.xxxxx .config
                  $make oldconfig
                  $make menuconfig
                  $make-kpkg clean
                  $make-kpkg --append-to-version=-xxx --revision=xxx --initrd kernel_image kernel_headers
                  suivi de (car ton source ne vient pas des paquets officiels, sinon pas besoin de recompiler):
                  $make all
                  $make modules_install
                  $make install
                  $cd /usr/src/
                  $dpkg -i kernel-image-xxxxx.deb
                  suivi de (même raisons):
                  $depmod xxxx
                  $mkinitrd.yaird -o /boot/initrd.img-xxxxx xxxx
                  $update-grub
                  Puis vérifier manuellement /boot/grub/menu.lst car il s'embrouille avec le RAID logiciel


                  C'est vrai que c'est simple. Si si.
                  • [^] # Re: ATM

                    Posté par (page perso) . Évalué à 0.

                    Tu es certain que c'est pour Debian ça, pas plutôt pour Ubuntu .....

                    Sinon, tu as oublié de booter ta machine, t'identifier, démarrer un terminal, récupérer les sources du kernel et les décompacter ....

                    Et pour les commentaires doutant de la réelle optimisation d'un noyau configuré et compilé, on peut par exemple choisir son IO Scheduler parmi "Anticipatory I/O scheduler", "Deadline I/O scheduler" et "CFQ I/O scheduler" (par défaut). En regardant l'aide de chacun de ces schedulers, il est bien écrit que Deadline risque d'être le meilleur choix pour les bases de données et CFQ serait le plus adapté à un desktop .... maintenant, si vous considérez que Linux est seulement bon pour le desktop ....
                  • [^] # Re: ATM

                    Posté par . Évalué à 5.

                    Holala, si tu chipottes : t'as dit "3 ou 4 commandes simples", et non, désolé, les cd ne comptent pas vraiment pour moi. Donc, une compil "normale" ça donne :


                    $ cp ta_conf_précédente .config
                    $ make oldconfig
                    $ make menuconfig # eventuellement si tu veux modifier des trucs par rapport à l'ancienne, mais pas obligatoire
                    $ make kpkg --blahblah # et on n'a pas besoin de le faire suivre de quoi que ce soit, même avec un noyau "vanillia"
                    $ dpkg -i linux-image-xxx.deb

                    Et c'est tout. Soit, pour enculer les mouches, puisque tu parlais uniquement de _compilation_, une seule commande...
                  • [^] # Re: ATM

                    Posté par . Évalué à 1.

                    Là, tu évoques des manip Debian bien poilues et tu as bien raison. Sinon il y a des distributions où c'est plus pratique et cohérent (Slackware, Gentoo...)
                    Aller dans les sources
                    $ cd /usr/src/linux
                    importer son ancienne configuration
                    $ make oldconfig
                    vérifier/personnaliser la configuration
                    $ make menuconfig
                    compiler le tout sous la forme d'une archive tar compressé (noyau et modules)
                    $ make tarbz2-pkg
                    installer le tout en décompressant l'archive
                    $ tar xf linux-X.Y.***tar.bz2 -C /

                    Pas de mauvaises graisses : que le strict nécessaire. On pourrait se passer d'initrd en compilant les pilotes concernés en dur. La configuration de Grub à la mano est un mal necéssaire. Contrairement aux multiples formes d'assistanat généralisé, via de sombres automatisations, de Debian...par exemple.
            • [^] # Re: ATM

              Posté par . Évalué à 3.

              Oui ça m'arrive encore, souvent pour sélectionner des options tarabiscotées dans la partie networking ou pour appliquer des patchs spécifiques.
        • [^] # Re: ATM

          Posté par . Évalué à 4.

          Se serait super, un truc qui boot avec un noyau générique, qui détecte ton matos, et qui te fourni le .config qui va bien ;-)

          On peut rêver.
          • [^] # Re: ATM

            Posté par (page perso) . Évalué à 4.

            Salut

            Ce serais encore mieux un script (ou une target du makefile du kernel) qui génère une config de noyau à partir du résultat de la commande "lspci" et "lsusb" (si un contrôleur USB est détecté).

            Quelqu'un connait-il un moyen de trouver dans les sources du kernel les drivers qui sont associés aux VID/PID des périphériques PCI et USB? ça pourrait être possible à coup de grep ou awk dans les sources et fichiers de build.

            A+
          • [^] # Re: ATM

            Posté par (page perso) . Évalué à 4.

            Ca serait "cool", mais quand tu ajoutes du matos (webcam ?) ou en remplace (genre la carte graphique), tu fais comment ?

            Quand c'est une bécane qui ne bouge pas d'un poil (cas d'un serveur), c'est bon, sinon c'est la galère.
            • [^] # Re: ATM

              Posté par . Évalué à 2.

              Ben pour du matos, c'est pas la mort: un script te compile ton module à la volée.
              (oui, je préfère un module compilé à la volée que tout le noyau, sinon faut rebooter tout le temps comme avec un système que j'exècre, suivez mon regard...)

              Pour la carte graphique, certes... faut que le noyau maison les gardent toutes!!
              • [^] # Re: ATM

                Posté par . Évalué à 2.

                (oui, je préfère un module compilé à la volée que tout le noyau, sinon faut rebooter tout le temps comme avec un système que j'exècre, suivez mon regard...)

                Dans ce cas là, kexec est ton ami ;)
            • [^] # Re: ATM

              Posté par . Évalué à 3.

              Comme je fais actuellement, tu gardes un noyau générique dans un coin.
          • [^] # Re: ATM

            Posté par . Évalué à 2.

            Faute de temps, je n'ai jamais testé

            http://lkml.org/lkml/2008/9/16/290


            mais cela semble fonctionner.
      • [^] # Re: ATM

        Posté par (page perso) . Évalué à 1.

        J'ai pas de module chargé dont le nom contient atm, je suis sous Ubuntu 8.10.
        « Noyau générique fourni par une distribution grand public » != « Noyau avec tout compilé en dur », et « Distribution grand public » != « Distribution qui charge tous les modules histoire de, on sait jamais ».
        • [^] # Re: ATM

          Posté par (page perso) . Évalué à 2.

          Essaye 'sudo modprobe atm' pour voir...
          Je suis quasi-sûr que tu l'as, et le fait qu'il ne soit pas chargé est tout à fait normal, il sera chargé automagiquement par le noyau ou udev lorsque tu en auras besoin (par exemple en ouvrant une socket ATM...) sans intervention de l'administrateur.

Suivre le flux des commentaires

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