Vulnérabilité de tous les noyaux 2.4.x / 2.6.x

Posté par  (site web personnel) . Modéré par rootix.
Étiquettes :
0
15
juin
2004
Noyau
Une nouvelle vulnérabilité a été découverte le 09 juin 2004 concernant tous les noyaux 2.4.x et 2.6.x (détails des noyaux non vulnérables dans l'annonce en anglais).

Cette faille nécessite un accès local à la machine et peut s'exécuter par la compilation d'un simple programme en C. Le bug a été également reporté dans le bugzilla de GCC (versions affectées 2.96, 3.0, 3.1, 3.2, 3.3 et 3.3.2).

Le patch concerne un simple changement de ligne sur la fonction clear_fpu() changeant l'appel asm volatile de ("fwait") vers ("fnclex ; fwait").

Le lien comporte un patch pour 2.4.x, 2.6.x et le test permettant de tester votre système, il est recommandé de synchroniser les systèmes de fichiers avant de tenter l'exploit.

Aller plus loin

  • # Le patch ne suffit pas

    Posté par  . Évalué à 10.

    "Evil can not do any damange once this patch is applied, but it will keep running at 99% CPU until it is killed (like any other process)."

    En gros, le code malfaisant ne peut plus endommager votre système une fois que vous avez appliqué le patch (et recompilé le noyau), mais l'application tournera, occupant 99% du CPU jusqu'à ce que vous la tuiez.

    Moralité : comme toujours, patch ou pas, faille ou pas, ayez toujours un oeil sur votre système!

    • [^] # Re: Le patch ne suffit pas

      Posté par  . Évalué à 7.

      tu as oublié le " like any other process"
      Car oui, quelqu'un qui peut lancer des process sur ta machine peut toujours la ralentir (sauf si tu utilises ulimit, donc pas besoin de nouveau patch pour ce type de probleme déjà bien connu)

      help ulimit

      • [^] # Re: Le patch ne suffit pas

        Posté par  . Évalué à 2.

        pardon, il vaut mieux faire quand on est root:
        man setrlimit
        http://www.die.net/doc/linux/man/man2/setrlimit.2.html(...)

        car ces limites ne peuvent plus etre augmentées par un utilisateur ensuite

      • [^] # Re: Le patch ne suffit pas

        Posté par  . Évalué à -1.

        Nous sommes d'accord : ce que je veux dire c'est que, faille ou pas, quelqu'un pouvant lancer un processus quelconque peut poser un problème (éventuellement, sans mauvaise intention).

      • [^] # Re: Le patch ne suffit pas

        Posté par  . Évalué à 2.

        suaf que ulimit est totalement inutile des que tu veux offrir une connection graphique (cf http://linuxfr.org/comments/429463,1.html(...))

        En effet la limite memoire ce faire par process et non par par user, et pour les connexions graphiques il faut entre 50-100Mo par process (mozilla, OOO) et au moins une 20 process, donc au total un utilisateur pourra allouer 1 a 2 Go de memoire...

        Donc un petit programme a base de malloc de et fork peut faire pas mal de degat (si mes souvenir sont bon quand le kernel manque de memoire, il tue des process aleatoirement, par contre je sais plus si ceux en root son protege...)...

        • [^] # Re: Le patch ne suffit pas

          Posté par  . Évalué à -1.

          c'est pour ca que linux peut gerer 64 tera de ram !

          --> []

        • [^] # Re: Le patch ne suffit pas

          Posté par  . Évalué à 1.

          Jusqu'au 2.4.26, linux utilisait le OOM (Out Of Mémory)- killer, qui essayait de trouver le "bon" process à killer. Ca a été assez décrié, car dans certains cas, il killait des "mauvais" processus...

          Depuis, c'est une option de config désactivée par défaut, le comportement par défaut étant de killer l'appli qui est demandeuse de mémoire au moment où il n'y en a plus.

          Ceci dit, c'est du hors-sujet, on parle pas du tout de mémoire ici normalement :)

          • [^] # Re: Le patch ne suffit pas

            Posté par  . Évalué à 3.

            En même temps si ton but est de nuire tu malloc() pas comme un débile tu t'arretes juste avant d'épuiser la quantité RAM + swap. Du coup sur les noyaux sans OOM-killer la charge va s'envoler et la machine devient souvent irrecuperable, et sur les nouyaux avec alors il va tuer les process demarrant.

            Le problème c'est que dans les solutions offertes actuellement et accessible par le plus grand nombre tu as le choix entre ne rien permettre a l'utilisateur (restrictions tres forte) ou alors lui permettre le DoS.

  • # FEDORA CORE 2 USER

    Posté par  . Évalué à 4.

    pour ceux qui comme moi utilisent la fedora Core 2,
    le kernel 2.6.6-1.435 est à jour et disponible depuis hier soir.

    messieurs à vos compilo

    N.B: le kernel source code pour le 2.6.6-1.435 n'était pas disponible sur le mirroir de rpmfind.

    y'a pas à dire yum est tous simplement génial ;)

  • # Comment découvre-t-on de telles failles ?

    Posté par  . Évalué à 7.

    Comment découvre-t-on de telles failles ? C'est une question que je me suis toujours posée lorsque sont rendues publiques des failles aussi tordues ?
    "discovered by Stian Skjelstad while he was doing some code tests.", dit le premier lien. Mais qu'essayait-il de tester ?

    Ca me laisse quand meme perplexe, surtout que, le gars qui a découvert ça, il n'était pas à priori mal intentionné, mais ensuite, une fois la nouvelle répandue, plein de script kiddies ont fait tomber des serveurs honnètes. (non, je ne suis pas en train de relancer le troll sur la non-divulgation des failles)

    • [^] # Re: Comment découvre-t-on de telles failles ?

      Posté par  . Évalué à 5.

      Bah on peut auditer certaines parties sensibles, on peut rechercher certains modèles ou fonctions connues pour poser des problèmes et regarder si tout à été prévu, on peut aussi tomber par hasard sur une faille.

      On code un truc, on se trompe (oui oui, ca arrive :D ), et le comportement deviens bizare (core dump d'un daemon, blocage système, code de retour de la fonction système bizare...). Alors on fouille pour trouver d'où cela viens.

      Il y a trop de moyen de tomber sur une faille pour les ennumérer de facon exhaustive...

      • [^] # Re: Comment découvre-t-on de telles failles ?

        Posté par  . Évalué à 4.

        ou core dump de bash quand on lui fait faire:
        eval 'toto=('

        J' ai découvert ça par hasard pendant l' écriture d' une librairie bash (oui oui j' ai bien dit bash ...)
        Je ne sais pas si ça peut être exploité à des fins néfastes mais un collègue à eu la gentillesse de soumettre le rapport de bug pour moi.

    • [^] # Re: Comment découvre-t-on de telles failles ?

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

      Ben comme l'indique le premier lien, le développeur l'a découverte par hasard alors qu'il était en train de tester du code qu'il venait de compiler. Donc généralement, soit par hasard, soit en optimisant du code.

      Steph

      • [^] # Re: Comment découvre-t-on de telles failles ?

        Posté par  . Évalué à 3.

        Et son code peut paraître tordu vu qu'il l'a peut être simplifié au maximum pour cerner que la partie de code incriminer.
        La cause du problème aurait été peut être trouvé moin rapidement
        si il avait publier sous la forme d'un programme faisant plusieurs Ko ou Mo.

    • [^] # Re: Comment découvre-t-on de telles failles ?

      Posté par  . Évalué à -2.

      Ce qui fait la difference entre un bon admin et un mauvais admin....:-)
      (please no troll)

      Bon apres, faut avoir un acces local pour cette faille....

  • # Explications

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

    Pour ceux que cela intéresse et veulent savoir pourquoi le noyau freeze, lisez ce mail dans le thread pointé par le journal ( https://linuxfr.org/~ange_thom/13734.html(...) ) :
    http://marc.theaimsgroup.com/?l=linux-kernel&m=108704809114434&(...)

    Ok, le patch du mec est un peu light ;-)

    Bonne journée.
    --
    Christophe

  • # Crash et non root access

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

    Moi quand je lis "vulnérabilité" je pense tout de suite à "méchant hacker^Hcracker qui a accès root à une machine sans y être normalement autorisé". Je suis le seul ou non ?

    Bref, une vulnérabilité qui crash le kernel saipabien(tm) mais c'est quand même largement moins grave qu'un root access.

    D'ailleurs c'est amusant, chez d'autres OS propriétaires il y a plusieurs vulnérabilités par an qui donne un root access, sous linux c'est quand même pas si souvent (le bug ptrace est déjà vieux... date des alentours du 2.4.20 IIRC).

    • [^] # Re: Crash et non root access

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

      Sur un serveur en production avec 10000 utilisateurs, ça peut être embêtant de devoir rebooter une machine...

      "Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier

      • [^] # Re: Crash et non root access

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

        Je ne suis pas sûr que ce soit 100% sûr , mais bon il suffirait en théorie d'utiliser le patch "kexec" pour ne pas rebooter ;-) , mais pour l'instant attention à la casse.

        Quelqu'un a une expérience sur l'utilisation de kexec ??


        http://www-106.ibm.com/developerworks/linux/library/l-kexec.html(...)
        http://developer.osdl.org/rddunlap/kexec/(...)

        Bonne journée.
        --
        Christophe.

        • [^] # Re: Crash et non root access

          Posté par  . Évalué à 6.

          k-exec, ca évite le reboot hard (détection des matériels Scsi, raid...) mais pas le reboot soft, ca permet juste de tester son nouveau noyau plus vite. (presque tout les process sont tués, et donc, pour les 10000 utilisateurs, il y a perte du service)

      • [^] # Re: Crash et non root access

        Posté par  . Évalué à 1.

        > Sur un serveur en production avec 10000 utilisateurs

        Il faut un accès ssh. Dans 99 % des cas, les serveurs ont un accès ssh uniquement pour les personnes de confiance.

        • [^] # Accès SSH ? Ou seulement la possibilité d'exécuter un programme ?

          Posté par  . Évalué à 4.

          C'est sans compter, par exemple, sur un script php mal sécurisé, qui permettrait d'exécuter des commandes shell (donc uploader et exécuter un programme dans /tmp). Le safe-mode n'est pas toujours pratiquable, selon les applications.
          Ça peut aussi être un service non privilégié, mais vulnérable. Même dans un chroot très restrictif, on peut exploiter ce bug kernel directement dans un shellcode.
          Il ne faut pas minimiser l'importance d'une vulnérabilité parce qu'elle n'est exploitable qu'en « local ».

          • [^] # Re: Accès SSH ? Ou seulement la possibilité d'exécuter un programme ?

            Posté par  . Évalué à 1.

            Tous les trous de sécurité doivent être pris au sérieux. C'est une question de principe. Mais il faut relativer. A distance pour exploiter ce trou de sécurité il faut déjà un autre très gros trou de sécurité qui permet d'exécuter n'importe quel programme sur la machine distante. Donc...

          • [^] # Re: Accès SSH ? Ou seulement la possibilité d'exécuter un programme ?

            Posté par  . Évalué à 1.

            btw : même si tu n'es pas en "safe mode" ça veux dire qu'il y a un system() ou exec() qui traine dans ton code php qui peut exécuter n'importe quelle commande. T'as un gros trou de sécurité à corriger :-)

        • [^] # Re: Crash et non root access

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

          > Il faut un accès ssh. Dans 99 % des cas, les serveurs ont un accès ssh uniquement pour les personnes de confiance.

          C'est ce que pensaient les admins de ftp.gnu.org en ne patchant pas leur noyau. "Naaan, c'est pas grave, c'est qu'une faille locale ..."

          • [^] # Re: Crash et non root access

            Posté par  . Évalué à 0.

            Attention, je vais démontrer que je suis super intelligent :
            - Ce n'est pas parce que ça arrive rarement que ça n'arrive jamais

            Fichtre. Trop fort je suis.

            Sinon j'ai parlé de "personnes de confiance".
            Si finalement ce ne sont pas des "personnes de confiance"...

            Puis je ne dis pas qu'il faut rien faire. D'ailleur sur ma bécane où il n'y a que moi comme utilisateur, c'est corrigé. Comme je le dis ailleur, la sécurité c'est une question de principe. Mais ce n'est pas une raison pour affoler les foules dès que le noyau à le hoquet car il a avaler un patch de travers et sortir le plan ORSEC et appeler le GIGN.

            On est pas aussi --- que G. Bush ?
            "Il faut raison garder" comme on dit dans la vieille Europe.

          • [^] # Re: Crash et non root access

            Posté par  . Évalué à 1.

            Le problème qu'ils ont, c'est qu'ils croient qu'il suffit de couper l'accès à tout le monde pour être en sécurité. Apparement ce ne fut pas efficace pour ftp.gnu.org mais cette logique est maintenant appliqué sur toutes les machines de GNU.
            Le problème, c'est que ça ne donne plus aux bonnes volontés l'opportunité de trouver et régler des failles, ça met tout entre les mains des sysadmins employés de la FSF USA (une seule personne jusqu'en novembre 2003, deux depuis) qui sont, de manière notoire, tout le temps surchargé de boulot.

      • [^] # Re: Crash et non root access

        Posté par  . Évalué à 2.

        > Sur un serveur en production avec 10000 utilisateurs, ça peut être embêtant de devoir rebooter une machine...

        Certainement... Ça va donc être très dur d'installer un nouveau kernel, non ? ;)

        • [^] # Re: Crash et non root access

          Posté par  . Évalué à 1.

          En general quand tu as 10.000 utilisateurs sur un serveur tu en as un de secours. enfin c´est quand meme la moindre des choses

    • [^] # Re: Crash et non root access

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

      > D'ailleurs c'est amusant, chez d'autres OS propriétaires il y a
      > plusieurs vulnérabilités par an qui donne un root access, sous
      > linux c'est quand même pas si souvent (le bug ptrace est déjà > vieux... date des alentours du 2.4.20 IIRC).


      c'est beau de rêver.

      Si on prend seulement les adviso de isec.pl durant la période janvier à avril de cette années, on a arrive à 4 local root sur le kernel Linux. C'est peu glorieux et aucun autre kernel n'a eu un aussi piètre palmarès durant la même période.

      A décharge de Linux toutefois, si les autres OS profitaient de la même attention des hackers, il y aurait certainement autant de bug de sécurité de leur côté.

      • [^] # Re: Crash et non root access

        Posté par  . Évalué à 2.

        > A décharge de Linux toutefois, si les autres OS profitaient de la même attention des hackers, il y aurait certainement autant de bug de sécurité de leur côté.

        Ajoutons que parmis les noyaux "open source", Linux est le plus complexe et aussi celui qui évolue le plus. Pour comparaison OpenBSD vient d'introduire SMP alors que c'est dans Linux depuis le 2.0.
        Même si tout n'est pas parfait, on n'a pas vraiment à se plaindre côté sécurité.

  • # Trollons...

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

    Encore un bug/faille qui nous pousse à patcher le noyeau !

    C'est nul ce système !

    BSD, c'est Mieux !

    :-)

    • [^] # Re: Trollons...

      Posté par  . Évalué à 7.

      Ratai !

      Name: NetBSD kernel swapctl(2) vulnerability
      Date: 11 June 2004
      CVE candidate: not assigned
      Author: Evgeny Demidov

      Description:

      There exists a integer handling vulnerability in NetBSD swapctl(2) system call. It seems that this vulnerability can not be exploited to gain super-user privilegies, but any local attacker can crash the kernel.

      • [^] # Re: Trollons...

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

        Oui mais non. NetBSD, c'est intéressant juste pour mettre un Unix dans sa cafetière. En parlant BSD, je pensais au seul OS qui soit vraiment sûr : OpenBSD ;-)

        (Comment ça, je vais me faire taper ? !)

        • [^] # Re: Trollons...

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

          C'est clair qu'il doit pas être vulnérable vu que dans sa version par défaut (ce que tous les BSDistes utilisent comme "version de référence" puisque la plus secure) il n'y a pas de serveur ssh donc pas de login possible.

          • [^] # Re: Trollons...

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

            il n'y a pas de serveur ssh donc pas de login possible
            Il me semble bien que si.

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

  • # Pile TCP/IP

    Posté par  . Évalué à 1.

    A noter que même après un freeze, le kernel continue de fonctionner de faire transiter les paquets ...

    La pile réseau du kernel ne semble pas être affecté (allez savoir pourquoi ?!)

    Si cela arrive sur un FW, cela ne pose pas de problème et permet de refaire une machine proprement sans se presser.

Suivre le flux des commentaires

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