Important bug de sécurité sur noyau 2.6.17 à 2.6.24

Posté par  . Modéré par rootix.
Étiquettes :
0
13
fév.
2008
Noyau
Une importante faille de sécurité a été mise en évidence ce week-end sur l'ensemble des noyaux Linux 2.6 récents (2.6.17-2.6.24.1). Elle permet à un utilisateur local d'obtenir les priviléges root. Le code d'exploitation est disponible publiquement depuis la fin du week-end.
Une mise à jour rapide du noyau Linux est donc nécessaire.
Le dernier noyau en date (2.6.24.2) règle définitivement le problème. Certaines distributions ont déjà rétropropagé le correctif. Les autres distributions ne devraient pas tarder.
Si vous utilisez un serveur dédié, pensez à regarder les forums de votre hébergeur pour obtenir la marche à suivre pour la mise à jour. Un lien sur le fil de discussion correspondant au sujet chez OVH a été mis en lien ci dessous, avec la marche à suivre pour leurs serveurs dédiés.
Les noyaux durcis (Grsec) sont affectés.

NdM: Merci à inico et à Victor Stinner pour leurs journaux sur le sujet.

Aller plus loin

  • # Fixé sous Gentoo

    Posté par  . Évalué à 1.

    Cette faille est corrigée sous Gentoo avec les packages gentoo-sources-2.6.23-r8 (stable) et gentoo-sources-2.6.24-r2 (~x86/amd64).

    • [^] # Re: Fixé sous Ubuntu aussi

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

      On s'arrête la ou on les liste toutes? :)

      (note: l'exploit marche très bien out-of-the-box sur une 7.10 non-patché, mais fait un seg-fault sur mes 7.04 (2.6.20). Probable qu'il aurait fini par marcher en ajustant ceci ou cela...)

  • # Dedimaniacs:

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

    Et pour les Dediboxés avec un noyau 'made-in-dedi', y'a une 2.6.24.2 là, sauf gourrage de ma part:

    ftp://ftp.dedibox.fr/pub/dedibox/kernel/r8-1/

  • # Fixé depuis hier (12/2) sur Mandriva

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

    http://wwwnew.mandriva.com/en/security/advisories?name=MDVSA(...)

  • # Les noyaux durcis (Grsec) SONT affectés.

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

    Grsec n'empêche pas l'exploit sur les noyaux 2.6 récents. Il est impératif de les mettre à jour eux aussi.

    Le patch pour 2.6.24.2 n'est pas encore sorti, mais il y a moyen de bricoler des 2.6.22.18 ou 2.6.23.14 corrigés. On en parle sur plusieurs threads des forums Grsec :

    http://forums.grsecurity.net/viewtopic.php?f=1&t=1889
    http://forums.grsecurity.net/viewtopic.php?f=1&t=1892
    http://forums.grsecurity.net/viewtopic.php?f=3&t=1888

    Bon courage

    • [^] # Re: Les noyaux durcis (Grsec) SONT affectés.

      Posté par  . Évalué à 1.

      Je confirme, et d'ailleurs je n'avais pas mis ca dans la news originelle, vu que octave (d'ovh) precisait bien que meme les noyaux "durcis" (j'avais jamais vu ce terme ;)) etaient impactés.

      En revanche, j'avais oublie de signaler les journaux qui en parlaient, merci aux moderateurs de l'avoir ajoute :)

    • [^] # Re: Les noyaux durcis (Grsec) SONT affectés.

      Posté par  . Évalué à 1.

      > Grsec n'empêche pas l'exploit

      Idem pour SeLinux.
      Grsec ou autres ne corrigeront jamais tous les bugs du noyau. Ça serait trop beau.

      • [^] # Re: Les noyaux durcis (Grsec) SONT affectés.

        Posté par  . Évalué à 2.

        mais une politique correcte peut les empecher parfois.
        comment tu execute ton exploit si tu ne peut rien executer sur la machine par exemple, ou si tu na pas accès a vmsplice, etc etc. Il me semble que la faille ne fonctionne pas sur certain serveurs a distance type www.ulteo.com par exemple.

        • [^] # Re: Les noyaux durcis (Grsec) SONT affectés.

          Posté par  . Évalué à 1.

          > comment tu execute ton exploit si tu ne peut rien executer sur la machine par exemple

          Mais parfois il faut excécuter sur les bécanes. Et Linux permet de le faire avec un bon niveau de sécurité (sauf bug comme ici). Per exemple pour Ulteo :-)

          > Il me semble que la faille ne fonctionne pas sur certain serveurs a distance type www.ulteo.com par exemple.

          Peut-être car Ulteo utilise un noyau antérieur à 2.6.17 ?
          Peut-être car Ulteo a patché ses systèmes sans que tu le saches.

          Pour info, Red Hat un fait un module dimanche que tu change et qui empêche exploit. C'est une solution de crise (pour ceux qui ne peuvent vraiment pas attendre ou rebooter).

    • [^] # Re: Les noyaux durcis (Grsec) SONT affectés.

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

      Le patch est sorti (pour 2.6.24.2) : http://www.grsecurity.net/~spender/

  • # Je vais faire mon chieur...

    Posté par  . Évalué à 4.

    noyaux Linux récents.

    privilèges rootadministrateur.

    week-end et ci-dessous (trait d'union)

    backporté rétropropagé le correctif.

    thread fil de discussion

    Ce commentaire pourra ensuite être effacé pour donner lieu à un débat plus constructif :-)

    ­La faculté de citer est un substitut commode à l'intelligence -- Somerset Maugham

    • [^] # Re: Je vais faire mon chieur...

      Posté par  . Évalué à 4.

      Je suis assez d'accord dans le principe, sauf sur :

      Privilèges administrateur. C'est trop vague (et trop proche de Windows). Un administrateur en informatique, c'est quelqu'un qui fait des tâches d'administration sur les machines et qui, à ce titre, doit bénéficier de pouvoirs particulier. Le root UNIX, c'est quand même beaucoup plus précis que cela. Et de toutes façons, le bon administrateur UNIX ne travaille jamais sous root.

      Rétropropagé. Pourquoi pas, mais ça reste un piège classique du traducteur. C'est un mot français qui n'a de sens que lorsque l'on connaît déjà l'original. Hors contexte, ça devient beaucoup plus flou.

      • [^] # Re: Je vais faire mon chieur...

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

        Euh ils travaillent comment les administrateurs unix alors ?

        • [^] # Re: Je vais faire mon chieur...

          Posté par  . Évalué à 3.

          Ils font la majorité de leur travail sous leur propre compte, utilisent des comptes dédiés pour les daemons (dont les privilèges peuvent être plus restreints encore que ceux des utilisateurs de base), configurent les groupes correctement, changent d'identité uniquement sur besoin avec su et pensent à refermer le shell concerné derrière (le tout, donc, sans avoir besoin de changer de session), font un usage modéré de sudo, et n'utilisent le mot de passe root et le prompt # qu'en tout dernier ressort.

          • [^] # Re: Je vais faire mon chieur...

            Posté par  . Évalué à 2.

            Ca c'est au cinema. Dans la vraie vie les gens ils ont en general autre chose à faire que créer 50 000 comptes, s'amuser à regler les permissions le plus précisement possible et changer d'identité toutes les 30 secondes.

            • [^] # Re: Je vais faire mon chieur...

              Posté par  . Évalué à 6.

              Je veux pas dire, mais ils doivent etre sacrement monotones les films que tu regards au cinema :+)

              Le Bon, la Brute et le compte Root
              Le Seigneur des Serveurs
              Le Slience des Shells

            • [^] # Re: Je vais faire mon chieur...

              Posté par  . Évalué à 2.

              Ca c'est au cinema. Dans la vraie vie les gens ils ont en general autre chose à faire que créer 50 000 comptes, s'amuser à regler les permissions le plus précisement possible et changer d'identité toutes les 30 secondes.

              Je suis dans une très grosse entreprise française, et je peux te dire qu'il y a un sacré paquet de comptes sur les serveurs Unix.

              Chaque application tourne avec ses propres comptes. Les droits sur les fichiers/répertoires étant généralement en 750 (ou 755), ça évite qu'une application écrive par erreur dans l'arborescence d'une autre (c'est un élément de sécurité parmi d'autres). Une application (dont on parle au sens large dans cette boîte) peut comporter plusieurs serveurs (d'application, web ...) qui ont donc chacun leur propre compte.

              Et on a beaucoup d'applications différentes.

              En plus, sur une même machine, une même application est dupliquée dans ce qu'on appelle chez nous des environnements : un premier pour le développement de la version N de l'appli, un pour développer les correctifs de la version N-1 en cours de tests (recette), et un troisième avec la version N-2 actuellement en production, où l'on teste les éventuels bugs de prod.

              Multiplié par le nombre de serveurs indépendants, où se retrouvent encore dupliquées ces applis, je manipule personnellement, en tant que simple développeur environ 32 comptes (dont les noms sont logiques, et faciles à retrouver), car j'interviens sur 2 applis.

              Sachant que nos serveurs hébergent des dizaines et des dizaines d'application, je vous laisse faire le total.


              A coté de ça, on a aussi des admins qui sont tout le temps en root, et font des su - dans tous les sens. On a des machines (de développement seulement) dont la racine appartient à un compte ordinaire, /home un autre (avec les droits 777), et tout un tas de fichiers systèmes avec des proprios surprenants ...

      • [^] # Re: Je vais faire mon chieur...

        Posté par  . Évalué à 3.

        quid de "super utilisateur" ?

      • [^] # Re: Je vais faire mon chieur...

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

        > Et de toutes façons, le bon administrateur UNIX ne travaille jamais sous root.

        Qu'un utilisateur normal ne travail jamais sous root, je peux comprendre.

        Mais qu'un administrateur, qui est censé balancé 15 commandes à la minute nécessitant la plupart du temps les droits root, ne soit pas en root, j'ai du mal à voir comment il fait. (nan parce que sudo ça va 2 secondes, mais au bout de 10 min d'administration, ça me gave personnellement).

        • [^] # Re: Je vais faire mon chieur...

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

          note : je ne suis pas admin...

        • [^] # Re: Je vais faire mon chieur...

          Posté par  . Évalué à 4.

          De toutes façons, sudo, c'est un moindre mal. On en avait déjà discuté il y a quelque temps. Evidemment, qu'un administrateur Unix va avoir besoin d'ouvrir un shell root de temps en temps, mais cela ne doit pas être un comportement ordinaire.

          qui est censé balancé 15 commandes à la minute nécessitant la plupart du temps les droits root

          C'est surtout cela qu'il faut identifier. Quand tu en es à balancer, en temps normal, 15 commandes root à la minute, c'est que ta machine n'est pas configurée correctement. Il y a des dizaines de petits trucs à régler pour t'éviter de passer systématiquement root chaque fois que tu as besoin de faire une action un peu originale. L'une des plus importantes, à mon avis, est l'accès aux logs. Un sudo pour aller lire un log Apache ou autre, par exemple, est une hérésie. A la place, il faut créer un groupe dédié spécialisé et lui donner les droits de lecture seule.

          En identifiant toutes les tâches privilégiées répétitives, tu peux réduire considérablement tes 15 commandes par minute. Evidemment, cela demande un minimum de bon sens. On peux donner les droits read-only sur des logs à un groupe, on sera beaucoup plus circonspects s'il faut donner les droits d'écriture.

          Dans l'absolu, même des trucs comme passwd n'ont pas besoin d'être setuid root s'il ne s'agit que d'aller mettre à jour le fichier /etc/passwd. Un SetGID sur un groupe ordinaire suffit largement. Evidemment, aujourd'hui, ce n'est plus tout-à-fait vrai car le tout passe par PAM et qu'il y a différentes méthodes d'authentification. Mais l'esprit reste le même ...

          • [^] # Re: Je vais faire mon chieur...

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

            Je pensais que les vrais administrateurs partaient très loin en courant quand on leur parlait de sudo. Un logiciel setuid qui fait des choses aussi complexes, ca a de quoi faire peur. Surtout quand les patchs se succèdent. Et surtout depuis que Watson a identifié des possibles races conditions en Août 2007 permettant de faire des choses pas belles (http://www.watson.org/~robert/2007woot/2007usenixwoot-exploi(...)

            Enfin sinon je comprend ce que tu voulais dire, le jamais était juste de trop (et je vois mal la différence entre un su - et être loggué en root).

            • [^] # Re: Je vais faire mon chieur...

              Posté par  . Évalué à 3.

              Un logiciel setuid qui fait des choses aussi complexes, ca a de quoi faire peur

              Encore une fois, il faut distinguer sudo et les setuids du compte root. On peut prendre l'identité de n'importe quel (pseudo-)utilisateur.

              Un logiciel setuid qui fait des choses aussi complexes, ca a de quoi faire peur

              Oui, mais cela reste toujours plus facile de les faire directement en root dès lors que les privilèges sont acquis. C'est pour cette raison qu'il ne faut pas prendre l'habitude de passer root à tout bout de champ.

              Un truc style gksudo, par exemple, accorde un délai de grâce à une console inconnue (normal si directement lancée depuis X), ce qui permet à n'importe quel processus X-Window ou se détachant de lui-même de sa console d'en profiter ( https://linuxfr.org//comments/860291.html#860291 ).

              Une console root ouverte sous X peut éventuellement recevoir des événements clavier d'une autre application connectée au serveur graphique ...


              (et je vois mal la différence entre un su - et être loggué en root).

              C'est-à-dire que su permet de changer d'identité, et pas forcément pour prendre celle du root. C'est ce dernier point qui est important, parce que ce n'est pas utilisé assez fréquement, à mon goût, pour les tâches d'administration.

              Quand à utiliser su et se logger de façon ordinaire, c'est aussi, à mon avis, l'origine d'une faiblesse courante sur de nombreux système :lorsque su ou un dispositif similaire sont indisponibles, les gens préfèrent souvent s'accorder directement tous les pouvoirs, parce qu'il est difficile de changer temporairement d'identité. C'est même très génant quand on est obligés de le faire au milieu d'une session de travail.

          • [^] # Re: Je vais faire mon chieur...

            Posté par  . Évalué à 0.

            Je ne suis pas tout a faire d'accord ici. Si c'est vrai pour les logs (et facile a faire), jamais je me casse le cul a faire sudo pour toutes les commandes d'admin que j'ai a faire regulierement (typiquement gerer apache 2 en fait, plus quelques merdes de droits par ci par la)
            Donc j'ai regulierement une console root ouverte sur mes serveurs parce qu'il faut que ca soit gere, tout simplement. Ca veut aussi dire qu'il faut que je sache ce que je fait a tout moment, je suis donc plus mefiant qu'un "oh je suis en user, je risque rien 'sudo rm -Rf /'"... ;)

            Pour passwd sans SUID bit, je veux bien voir comment tu fais :) Parce que s'il a le SUID, c'est essentiellement pour que l'utilisateur puisse mettre a jour son propre mot de passe... (root en a rien a foutre) qui n'est plus dans /etc/passwd depuis la prehistoire (mais dans shadow)...

            Quand a la difference entre ssh root et su -, je t'invite a faire taper "screen" dans les deux cas pour voir la diff ;)) (ssh cree un PTS alors que su ne le fait pas, tu est pas TOTALEMENT root en su pour de rare cas particuliers)

            • [^] # Re: Je vais faire mon chieur...

              Posté par  . Évalué à 3.

              C'est parce que tu as mal lu. :-)

              Il ne s'agit pas de passer toutes les commandes root en un équivalent utilisateur ordinaire, mais les plus fréquentes, de façon à ce que passer root devienne exceptionnel (ou, au moins, rare).

              Pour password, encore une fois, il y a une différence entre utiliser le SetUID d'une manière générale, et l'utiliser pour passer root. De toutes façons, pour gagner le droit d'écriture sur un fichier donné, un SetGID suffit. Pas besoin de changer en plus d'identité.

              Quand a la difference entre ssh root et su -, je t'invite a faire taper "screen" dans les deux cas pour voir la diff ;)) (ssh cree un PTS alors que su ne le fait pas, tu est pas TOTALEMENT root en su pour de rare cas particuliers)

              Déjà repondu juste au-dessus.

          • [^] # Re: Je vais faire mon chieur...

            Posté par  . Évalué à 4.

            C'est surtout cela qu'il faut identifier. Quand tu en es à balancer, en temps normal, 15 commandes root à la minute, c'est que ta machine n'est pas configurée correctement.

            Effectivement, quand je me log en root pour taper 15 commandes à la minute, c'est que la machine n'est pas configuré correctement, ou qu'il y a quelquechose à regler dessus.

            En identifiant toutes les tâches privilégiées répétitives, tu peux réduire considérablement tes 15 commandes par minute. Evidemment, cela demande un minimum de bon sens. On peux donner les droits read-only sur des logs à un groupe, on sera beaucoup plus circonspects s'il faut donner les droits d'écriture.

            Personnellement, et je pense que c'est le cas de beaucoup de monde, il y a peu de taches répetitives que j'ai a faire en root de facon régulière, les trucs que j'ai besoin de faire sont plutot imprevisibles. Et c'est pas par ce que j'ai besoin d'éditer la conf apache une fois tous les 6 mois que je vais me créer un groupe, des scripts de redemarrage et passer 3 heures à regler les permissions pour m'éviter de passer root une fois tous les 6 mois. Surtout qu'après tu risques de te retrouver avec 250 groupes dont tu ne sais plus à quoi ils servent, des scripts d'admin de partout, un fichiers sudoers de 2500 lignes, et un compte utilisateur qui permet de faire à peu près tout sans passer root.

            Pour eviter quoi au fait ?

            • [^] # Re: Je vais faire mon chieur...

              Posté par  . Évalué à 2.

              il y a peu de taches répetitives que j'ai a faire en root de facon régulière.

              Je crois que cette phrase résume à elle-seule tout le sujet.
              L'idée générale était bel et bien que le recours à root doit demeurer occasionnel.

              • [^] # Re: Je vais faire mon chieur...

                Posté par  . Évalué à 1.

                Pas pour un administrateur systeme, dont l'une des taches principales est en general de configurer des machines.

          • [^] # Re: Je vais faire mon chieur...

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

            >Quand tu en es à balancer, en temps normal, 15 commandes root à la minute, c'est que ta machine n'est pas configurée correctement

            bon déjà, je disais 15, c'etait juste comme ça. Sinon, oui effectivement, le boulot d'un admin n'est-il pas d'installer, de configurer une becane (nouvelle ou mal configurée) ? Donc de taper 15 commandes à la minute pour ça, non ?

            Même si pour certaines tâches quotidienne, il n'est pas forcément besoin d'être en root bien évidément.

        • [^] # Re: Je vais faire mon chieur...

          Posté par  . Évalué à 1.

          je suis admin

          et je ne travaille pas en root

          et oui je prends sur moi la corvée de passer root à des moments importants de mon travail et uniquement à ces moments.

          on me paye justement pour les corvées et pour éviter les accidents !

          sudo en soi n'est pas une protection

          donc exemple : on écrit un nouveau fichier de configuration en simple utilisateur, on regarde les réglages, on fouine et seulement ensuite on passe root pour copier et activer la nouvelle configuration.

        • [^] # Re: Je vais faire mon chieur...

          Posté par  . Évalué à 1.

          sudo -i est ton ami, ca evite de taper sudo toutes les 2 s sous ubuntu

      • [^] # Re: Je vais faire mon chieur...

        Posté par  . Évalué à 2.


        Rétropropagé. Pourquoi pas, mais ça reste un piège classique du traducteur. C'est un mot français qui n'a de sens que lorsque l'on connaît déjà l'original. Hors contexte, ça devient beaucoup plus flou.


        Très juste ! Pour leur part les anglophones connaissent le sens du mot "backport" dès leur naissance. Mais comme les francophones leur font perdre leur sens commun, ils ont du donner quelques explications sur Wikipédia :
        http://en.wikipedia.org/wiki/Backport

    • [^] # Re: Je vais faire mon chieur...

      Posté par  . Évalué à 2.

      Ah desole d'avoir ecrit ca a la jean claude, mais comme le signalent d'autres personnes, certaines traductions sont mauvaises, ou peuvent prete a confusion.
      Maintenant j'etais fier d'avoir fait bien gaffe a mettre des accents partout, quand on a appris a taper au clavier avec un QWERTY, certaines habitudes ont la vie dure :)
      (note: j'ai pas ta trad de backporte ni de thread, j'ai l'impression que ca fait un faux sens ou qu'il manque un truc)

    • [^] # Re: Je vais faire mon chieur...

      Posté par  . Évalué à 2.

      root est un terme technique qui correspond a un utilisateur très précis en unix

      on pourrait le nommer racine, mais il fut nommé root et on le traduit pas.

      week-end a été adopté y a très longtemps, de même que "rendez-vous" par les américains. ne faites pas le borné pour le plaisir de contredire

      "rétropropager" est un chouette mot. je l'utiliserais volontier

      thread : je ne dis jamais thread pour parler d'un fil de discussion d'un forum. il m'arrive de dire thread dans le cas de sous-tâche exécutée au sein du processus principal parce que je parle technique et il me faut un langage dénué de toute ambiguïté entre processus et fil d'exécution et que je viens de lire de la documentation en anglais.

      Après, je ne sais pas ce que vous voulez démontrer ou dire : manifestement, contrairement à vous je ne vois aucune raison de parler en franglais tout le temps. j'aime particulièrement le français et l'anglais comme ils sont tout en ne craignant pas leurs évolutions et échanges.

  • # Commentaire supprimé

    Posté par  . Évalué à 0.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Exemple du'tilisation de la faille

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

      Pour se cultiver il vaut mieux lire l'article de LWN qui explique techniquement (avec des extraits du code noyau) l'origine de la faille.

      Un extrait de la conclusion : "This vulnerability is a clear example of how a seemingly read-only vulnerability can be escalated into something rather more severe. It also shows what can happen when certain types of sloppiness find their way into the code".

      L'article est ici mais il ne sera ouvert aux non-abonnés que la semaine prochaine : http://lwn.net/Articles/268783/

      • [^] # Commentaire supprimé

        Posté par  . Évalué à -2.

        Ce commentaire a été supprimé par l’équipe de modération.

  • # Délai ?

    Posté par  . Évalué à 2.

    Je trouve que linuxfr à mis longtemps à sortir l'info. C'est passé sur slashdot il y a plus d'une semaine et sur les sites de sécu encore plus tot.

    Je sais bien que ça n'est pas la vocation de Linuxfr mais je vois aujourd'hui plein de gens qui "découvrent" le problème alors qu'il est connu depuis trop longtemps.

    • [^] # Re: Délai ?

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

      >>> Je trouve que linuxfr à mis longtemps à sortir l'info.

      Linuxfr est dépendant des gens qui proposent des news.
      Conclusion : Lancez-vous et écrivez des news ! Au lieu de torcher un journal en 2 minutes prenez un peu de temps pour soumettre une news et tout le monde en profitera.

    • [^] # Re: Délai ?

      Posté par  . Évalué à 1.

      c'est parce que je m'etonnais de ne pas voir de news sur le sujet que j'en ai fait une (apres avoir demande s'il n'y en avait pas deja une en validation...

  • # Fonctionnalité

    Posté par  . Évalué à 4.

    Moi je trouvais ça pas mal comme commande...!
    Mieux que sudo en tout cas, parce qu'au moins, ça
    ne demandait pas de password, password que la
    plupart du temps les admins ne communiquent jamais !

    Dommage que ce genre d'outil ne soit pas disponible
    sous NetBSD ! :)

Suivre le flux des commentaires

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