• # Un peu de recherche...

    Posté par . Évalué à 10.

    http://marc.theaimsgroup.com/?l=linux-kernel&m=108704809114434&(...) file des explications qui donnent mal a la tete, avec un fix possible a la fin.
    http://marc.theaimsgroup.com/?l=linux-kernel&m=108705064524391&(...) discute des implications dudit fix possible.

  • # x86 only

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

    Pour les utilisateurs de plateformes non x86, ca sert à rien d'essayer, ca compile pas :

    This code only works on x86 Linux machines. This code does not compile (makes no executable) on sparc64 sun4u TI UltraSparc II (BlackBird). This doesn't affect NetBSD Stable.


    Y a de l'assembleur dedans.

    • [^] # Re: x86 only

      Posté par . Évalué à 1.

      This code only works on x86 Linux machines.[...] This doesn't affect NetBSD Stable.

      Quel est le rapport ? Il dit tout d'abord que ça ne concerne que des machines sous Linux et parle de netbsd par la suite ... moi y en a pas trop comprendre ?

    • [^] # Re: x86 only

      Posté par . Évalué à 2.

      > This doesn't affect NetBSD Stable.

      Ni windows. Super !

      • [^] # Re: x86 only

        Posté par . Évalué à -2.

        Bof pour win ça se télécharge aussi ce genre d'exploits...
        Par contre pour OpenBSD c'est plus rare ce genre de trucs non ?
        (Vu qu'ils se targuent d'être les plus sécurisés, y'a bien des raisons, non ?)

  • # Re: Crashez votre noyau

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

    Il faut toujours cracher les noyaux. Si tu les avales, après, tu risques d'avoir un cerisier qui te pousse dans le ventre.

  • # Mais comment font-ils ?

    Posté par . Évalué à 2.

    Mais où vont-ils chercher tout ça ? Comment ont-ils trouvé cet exploit ?

    • [^] # Re: Mais comment font-ils ?

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

      while 1 do
      dd if=/dev/random of=test.c bs=1k count=1
      gcc -o test test.c && ./test
      done
      Ou alors c'est une machination pour qu'on passe tous à Gentoo.

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

    • [^] # Re: Mais comment font-ils ?

      Posté par . Évalué à 8.

      A priori c'est un gars qui voulait coder un truc et qu'était pas très doué donc qu'a fait qqchose de pas super propre et de buggé, et manque de bol il s'est bouffé un bug du noyau ;)

  • # Oui...

    Posté par . Évalué à -7.

    J'en avais découvert un une fois par moi meme (un while(fork())) qui est apparament assez connu...
    Je trouve étonnant le fait que le code soit diffusé comme ca...
    J'espere qu'un patch sera bientot mis à disposition.

    • [^] # Re: Oui...

      Posté par . Évalué à -1.

      oui, on appele ça une fork-bomb. Soit dit en passant, les 2.6.* y résistent.

      • [^] # Re: Oui...

        Posté par . Évalué à 1.

        Ca se règle avec ulimit tout ça aussi... (enfin avec bash tout du moins)

      • [^] # Re: Oui...

        Posté par . Évalué à 7.

        > Soit dit en passant, les 2.6.* y résistent.

        N'importe quoi. La mémoire est de taille finie, le CPU a une puissance donnée tu peux faire ce que tu veux ca sera toujours vulnerable. Ce qu'il y a c'est

        1/ Ulimit / un module pam qui permettent de limiter le nombre de processus pour un utilisateur/session

        2/ Mettre une limite au nombre de processus creables dans le système (FreeBSD par exemple). Et garder les 10 derniers pour que le root puisse se logger et botter le cul au jeuno tout content de sa découverte.

        Le 2.6 aussi nouveau et super fort qu'il soit ne changera rien a ce probleme. Dans la serie DoS on a aussi

        * Allouer trop de mémoire => SWAP, trashing
        * S'amuser a lire le code du noyau trouver tout les algos en O(n) et plus et s'amuser a les appeler de facon pathologique pour ralentir le système le plus possible. objrmap reintroduit un scan des vma et un code de 5 lignes te fait geler la machine assez rapidement. Mais il doit y en avoir plein d'autre.

        A partir du moment ou les ressources sont limitées le DoS arrive quand tu demandes plus qu'il n'y a. La seul chose est d'essayer d'empecher un utilisateur de demander trop.

        • [^] # Re: Oui...

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

          N'importe quoi. La mémoire est de taille finie, le CPU a une puissance donnée tu peux faire ce que tu veux ca sera toujours vulnerable.
          A partir du moment ou le système de gestion des droits refuse les forks, ont peut affirmer que le système n'est pas vulnérable.
          Sinon, c'est comme dire que tout les systèmes sont vulnérables au rm -Rf /...
          Allouer trop de mémoire, ouvrir trop de fichiers, tout ça se limite (/etc/security/limits.conf)... et j'ai cru comprendre que certains systèmes permettaient une gestion encore plus fine des droits (par contre je connais pas objrmap).

          • [^] # Re: Oui...

            Posté par . Évalué à 1.

            C'est pas dans les cordes de SELinux ce genre de boulot ?

          • [^] # Re: Oui...

            Posté par . Évalué à 6.

            > A partir du moment ou le système de gestion des droits refuse les forks,

            Tout à fait excuse moi de cette imprécision/faute (cf la suite de mon commentaire).

            Le n'importe quoi se rapportait à la remarque sur le 2.6 d'ailleur qui ne change rien par rapport à ce qu'il y avait avant.

            Pour te dire à quel point il est difficile d'empecher des DoS locaux (hormis les cas triviaux comme la fork() bombe) FreeBSD n'emet plus d'adviso pour ceux ci. A partir du moment ou tu connais le système et le code qu'il y a derriere tu as presque toujours moyen (en pratique) de trouver comment plomber la machine. Le problème c'est qu'il y a une différence entre ralentir très fortement une machine ou lui faire bouffer de la RAM à gogo par les structures noyaux par exemple et un joli crash sauvage. Le deuxieme étant plus grave.

            Effectivement certains système permettent des gestions plus fines, je pense a systrace d'openbsd, cerberNG de FreeBSD (patch non officiel et plutot désuet) ou MAC d'encore FreeBSD ou il est possible de faire plein de choses interessantes.

            Pour objrmap (mémoire virtuelle) grosso modo le problème est qu'il y a quelques "foreach(vma)" qui trainent. Hors a chaque mmap() tu cree une VMA... Des trucs comme ca il y en a un peu partout si tu cherches et ca se limite pas si facilement que ca.

            • [^] # Re: Oui...

              Posté par . Évalué à 2.

              * Free Open Source (GPL) Linux kernel security extension
              * Independent of governments and big companies
              * Several well-known and new security models, e.g. MAC, ACL and RC
              * Control over individual user and program network accesses
              * Any combination of models possible
              * Easily extensible: write your own model for runtime registration
              * Support for current kernels
              * Stable for production use


              http://www.rsbac.org/(...)

              http://forums.grsecurity.net/viewtopic.php?t=347&start=0(...)

              • [^] # Re: Oui...

                Posté par . Évalué à 5.

                Tu parles certainement de la chose dans laquelle spender à trouvé une faille en 12 heures ? :-)

                Bon pour pas trop faire dans la provocation sur le papier RSBAC est très bien, les papers sont pas mal. Il en reste que comme dit spender ce n'est actuellement qu'une boite a outil tout comme MAC si l'on a besoin de developper de son module. Aussi puissant que complexe et donc vecteur de faille que se soit du developpeur ou de l'administrateur (oui je parle entre autre des hiddeux menu de conf d'RSBAC ou il est si facile de se planter).

                Après dans la pratique c'est un patch intrusif qui n'a pas été largement relu et audité. Le problème de ce type de patch c'est qu'en voulant augmenter la sécurité ils peuvent très facilement introduire autant de failles qu'ils n'en resolvent (cf systrace). Donc dans la vraie vie c'est pas encore ca comme en temoigne la jolie intervention de spender un patch de sécu dans lequel tu trouves une faille aussi rapidement (l'histoire ne dit pas s'il l'avait sous le coude ou non) c'est assez flippant.

                Tant que les solutions de sécurité resterons des patchs externes tout le temps en train de se synchroniser sur l'arbre officiel ca me fera un peu peur. L'approche FreeBSD est beaucoup plus saine de ce côté.

                De plus j'attend que tu me presente tes modules RSBAC pour m'empecher de plomber une machine et que je puisse quand meme travailler. C'est sans doute faisable mais je demande a voir :-) Les fonctionalités sont géniales mais peu appliquées et applicables....

              • [^] # subliminal!

                Posté par . Évalué à -1.

                * Free Open Source (GPL) Linux kernel security extension
                * Independent of governments and big companies
                * Several well-known and new security models, e.g. MAC, ACL and RC
                * Control over individual user and program network accesses
                * Any combination of models possible
                * Le pierre tramo se nourrit de quarante deux
                * Easily extensible: write your own model for runtime registration
                * Support for current kernels

                acrostiche ? sens caché? subliminiminiminal ?

            • [^] # Re: Oui...

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

              En fait... ce qu'il faudrait ça serait un moyen de faire que les ressources utilisées à cause d'appels systèmes soient comptée dans les ressources utilisées par le programe non ? Ça devrait permettre d'appliquer les méthodes quivontbien (kill si plus de 95% de cpu pendant 2 minutes etc) dans les cas qui posent problèmes.
              Allez, où qu'il est joe que je code ça lol -_^ (et après, j'irais sur Mars...)

          • [^] # Re: Oui...

            Posté par . Évalué à 2.

            Allouer trop de mémoire, ouvrir trop de fichiers, tout ça se limite (/etc/security/limits.conf)... et j'ai cru comprendre que certains systèmes permettaient une gestion encore plus fine des droits (par contre je connais pas objrmap).

            Oui..., sauf que si tu fais un calcul simple limite de processus, limite de memoire par processus, tu te rendra vite compte que limits.conf est completement inefficace....

            cf http://linuxfr.org/~mat_/9348.html(...) et notament http://linuxfr.org/comments/346573,1.html(...) pour le calcul...

            • [^] # Re: Oui...

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

              Si j'en crois ma doc (enfin, ma compréhension approximative de la doc), les comptes sont faits au niveau de l'utilisateur pas du programe.

              • [^] # Re: Oui...

                Posté par . Évalué à 2.

                essaye et tu veras bien ;)

Suivre le flux des commentaires

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