Faire un don ! | | style | statistiques | contactez-nous | plan | lettre d'information

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

Posté par Guillaume Estival (). Modéré le 13 février 2008.
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.

> Lire la dépêche (57 commentaires, moyenne: 2).  

Vous avez demandé le commentaire #904726.

Je vais faire mon chieur...

Posté par plic () le 13/02/2008 à 15:27. (lien). É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» — Sommerset Maugham
  • [^]Re: Je vais faire mon chieur...

    Posté par Obsidian () le 13/02/2008 à 15:40. (lien). É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 zul (Jabber id, page perso, ) le 13/02/2008 à 15:45. (lien). Évalué à 2.

      Euh ils travaillent comment les administrateurs unix alors ?

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

        Posté par Obsidian () le 13/02/2008 à 15:56. (lien). É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 boklm (page perso, ) le 13/02/2008 à 19:30. (lien). É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 pasBill pasGates () le 13/02/2008 à 20:56. (lien). É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 matt23 () le 14/02/2008 à 21:04. (lien). Évalué à 2.

              The Postmaster Always Rings Twice

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

            Posté par Jllc () le 14/02/2008 à 20:56. (lien). É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 Julien () le 13/02/2008 à 15:46. (lien). Évalué à 3.

      quid de "super utilisateur" ?

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

        Posté par Obsidian () le 13/02/2008 à 15:57. (lien). Évalué à 2.

        Meilleur, en effet.

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

      Posté par Laurent J (page perso, ) le 13/02/2008 à 15:59. (lien). É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 Laurent J (page perso, ) le 13/02/2008 à 16:01. (lien). Évalué à 2.

        note : je ne suis pas admin...

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

        Posté par Obsidian () le 13/02/2008 à 16:17. (lien). É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 zul (Jabber id, page perso, ) le 13/02/2008 à 16:33. (lien). É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 Obsidian () le 13/02/2008 à 17:27. (lien). É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 Guillaume Estival () le 13/02/2008 à 17:20. (lien). É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 Obsidian () le 13/02/2008 à 17:37. (lien). É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 boklm (page perso, ) le 13/02/2008 à 19:11. (lien). É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 Obsidian () le 13/02/2008 à 19:41. (lien). É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 boklm (page perso, ) le 13/02/2008 à 19:48. (lien). É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 Laurent J (page perso, ) le 14/02/2008 à 11:57. (lien). É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 Michel Galle () le 14/02/2008 à 10:05. (lien). É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 mosfet () le 14/02/2008 à 10:14. (lien). É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 Laurent J (page perso, ) le 14/02/2008 à 11:41. (lien). Évalué à 4.

          et ça sert à quoi alors ? autant direct passer en root alors...

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

          Posté par meuble2001 () le 14/02/2008 à 20:31. (lien). Évalué à 0.

          Y'a des gens qui administrent une Ubuntu ?!

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

      Posté par memz () le 13/02/2008 à 22:25. (lien). É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 Guillaume Estival () le 13/02/2008 à 16:35. (lien). É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 Michel Galle () le 14/02/2008 à 10:03. (lien). É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.

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

      Posté par Ash_Crow (page perso, ) le 15/02/2008 à 14:46. (lien). Évalué à 2.

      Ce qu'il reprenait sur "week-end", ce n'est pas le fait que le mot est en anglais mais le fait qu'il manquait un trait d'union.