Problème de sécurité entre le serveur X et le noyau

Posté par  (site web personnel) . Modéré par Bruno Michel.
Étiquettes :
25
21
août
2010
Sécurité
Invisible Things Lab est une société polonaise spécialisée dans la sécurité. Elle est à l'origine de QubesOs, un projet où les applications bureau tournent toutes dans une machine virtuelle Xen, ce afin de renforcer le plus possible la sécurité.

C'est un membre de cette équipe, Rafal Wotjtczuk, qui a trouvé un moyen légitime, sans aucun bug donc, d'obtenir des privilèges root à travers une application graphique pour faire des actions malicieuses.

Cette vulnérabilité, révélée le 17 août et découverte deux mois plus tôt, est maintenant comblée dans les noyaux 2.6.27.52, 2.6.32.19, 2.6.34.4, et 2.6.35.2. C'était il y a quelques mois, Rafal Wojtczuk de Invisible Things Lab a trouvé un exploit dans X, le serveur graphique de Linux. Cet exploit a une particularité : aucun bug n'est utilisé.

Pour réaliser cet exploit, il faut passer par… une application graphique. Le processus associé, qui est lancé par un utilisateur sans droit particulier, aura donc accès à la mémoire allouée à X, et peut réclamer de l'espace mémoire normalement réservée à X pour exécuter du code avec les privilèges de X, c'est-à-dire les privilèges de root. Et l'attaque peut commencer : à l'aide d'une fonction récursive on pousse X à réclamer de la mémoire, et puis comme c'est récursif il va réclamer plus de mémoire et va donc chercher de la place ailleurs, puis ailleurs… et il faut maintenant que le script malicieux puisse placer à temps son code aux endroits où et pendant que X est en train d'allouer de la mémoire. Même si c'est une course, le script malicieux en sort facilement gagnant.

Les logiciels n'ont pas pour habitude de faire des choses pareilles, donc il faut profiter d'une faille de sécurité dans un logiciel ou de cliquer en toute confiance sur le bouton "installe Microsoft® OpenOffice Word sur MesChampisRatent.com" pour lancer de telles actions.

Plusieurs solutions sont possibles, notamment les trois gentils patchs créés par le gentil Linus (1 - 2 - 3) pour l'intégration au noyau. Ce qui a été fait dans les versions 2.6.27.52, 2.6.32.19, 2.6.34.4, et 2.6.35.2 du noyau et qui sera rétroporté par les distributions assurant le support de noyaux plus anciens.

Aller plus loin

  • # un commentaire malicieux...

    Posté par  . Évalué à 7.

    ces logiciels, ils sont prévus pour faire des actions malicieuses (faire apparaître des beasties lors du reboot) ou malveillantes (prendre contrôle de la machine pour la rendre digne d'un botnet windows) ?

    http://www.thisfrenchlife.com/thisfrenchlife/2008/10/how-man(...)

    Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

    • [^] # Re: un commentaire malicieux...

      Posté par  . Évalué à 1.

      Ben à partir du moment où t'arrives à faire exécuter un shellcode tu peux faire ce que tu veux, aussi bien être malicieux que malveillant.

      Mais tu as raison, on a trop souvent tendance à traduire par paronymie.
      J'avoue avoir eu du mal avec le nom de la programmation "impérative", les "exceptions" (un terminal qui t'affiche une "Exception en point flottant" c'est quelque chose !).

      Mais bon ça fini quand même par rentrer avec le temps ^^

    • [^] # Re: un commentaire malicieux...

      Posté par  . Évalué à 1.

      Ah ? Mon dictionnaire donne pour définition:
      malicieux: qui a de la malice. Jusqu'ici tout va bien.
      Et pour malice (entre autres sens): Aptitude et inclination à faire le mal, à nuire par des voies détournées.

      • [^] # Re: un commentaire malicieux...

        Posté par  . Évalué à 4.

        Tient, ce n'est pas ce que j'aurai comme définition perso. J'ai plutôt tendance à penser que malice sous-entend un peu le jeu, la gaîté, l'astuce, l'espièglerie (c'est le pays de Candy). En bref, le truc bon-enfant.

        Donc le livre "Malice au pays des Marvels" n'a pas la signification que je pensais.

        • [^] # Re: un commentaire malicieux...

          Posté par  . Évalué à 2.

          * MALICE, subst. fém.

          MALICE, subst. fém.
          A.− THÉOL. CATH. Pouvoir de l'esprit du mal. D'autre part, Jahvé a aussi autorisé sur les nations païennes, puisqu'il envoie Jonas annoncer à Ninive que la malice de cette ville est montée devant lui (Théol. cath. t. 4, 1re part., 1920, p. 1005) :
          1. C'est ainsi que la malice, qui le poursuivit d'ailleurs sans relâche jusqu'au dernier jour, réussit alors contre le misérable prêtre la plupart de ses entreprises.
          Bernanos, Soleil Satan, 1926, p. 162.
          B.− Disposition d'esprit à faire le mal par des voies insidieuses. La malice humaine. Les volontés ne peuvent être ici mises en cause; l'erreur [de la guerre] vient de plus loin que la malice des hommes (Proudhon, Guerre et Paix, 1861, p. 322) :
          2. Aux besognes régulières avaient succédé les avaries des sens et de honteux souvenirs l'assaillaient en foule; il se rappelait la recherche de monstrueuses fraudes, la poursuite d'artifices aggravant la malice de l'acte; et les complices, les agentes de ses déchéances défilaient devant lui.
          Huysmans, En route, t. 2, 1895, p. 62.

          http://www.cnrtl.fr/definition/malice

          Depending on the time of day, the French go either way.

          • [^] # Re: un commentaire malicieux...

            Posté par  . Évalué à 3.

            des définitions allant de 1861 à 1926, depuis le sens premier du mot a été pas mal supplanté par les autres acceptions (même si la définition du Littré date elle aussi un peu) :

            http://francois.gannaz.free.fr/Littre/xmlittre.php?requete=m(...)

            "Petite méchanceté, faite par badinage. "

            "MALICE, MALIGNITÉ. Ces deux mots sont très voisins, puisqu'ils dérivent tous deux de l'adjectif latin malus, méchant, et ne diffèrent que par la terminaison. Mais on remarquera d'abord que malignité a beaucoup moins le sens favorable que malice a quelquefois, celui de petite méchanceté, d'espièglerie. Puis on peut dire en général que la malice désigne malfaire, mal agir, et la malignité l'inclination à faire du mal. "

            Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

  • # « X, le serveur graphique de Linux »

    Posté par  . Évalué à 5.

    Zut, je n'étais pas au courant que X.org n'était plus un logiciel portable. Ça date de quand ? ;-)

    • [^] # Re: « X, le serveur graphique de Linux »

      Posté par  . Évalué à 4.

      ça serait intéressant d'ailleurs de voir si la maliciosité du programme prévu pour linux pourrait également compromettre un serveur X tournant avec un autre Unix, genre FreeBSD par exemple.

      D'ailleurs, question naïve, pourquoi X tourne-t-il avec les privilèges root ? Cela ne serait pas envisageable de le faire tourner uniquement pour l'utilisateur en cours ? C'est pour les performances ?

      Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

  • # Encore une preuve

    Posté par  . Évalué à -1.

    Que linux n'est pas prêt pour le Desktop.

    Sur ce, je ~~>[]

    • [^] # Re: Encore une preuve

      Posté par  . Évalué à 8.

      Au contraire, plus il a de failles, plus il se rapproche de Windows, et plus il s'affine pour le desktop.

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

  • # Explication un peu plus complete

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

    Ce qui se passe est l'interaction entre un programme et le serveur X. Le programme peut obliger le serveur X à rentrer dans une boucle récursive dont il contrôle la profondeur. Lorsqu'un programme devient récursif, il se met à prendre de la place sur le stack pour pouvoir revenir à son état d'origine après les différents appels de fonction.
    Le bug se produit lorsque le stack descend tellement bas qu'il tombe sur un espace d'adressage déjà utilisé et controllé par l'application.
    Dans ce cas, il suffit à l'application d'écrire dedans pour écrire dans le stack du serveur X, ce qui donne très facilement un contrôle total du serveur X.

    A mon sens il y a deux bugs ici :
    - Le serveur X ne devrait pas pouvoir rentrer en récursion arbitraire avec des entrées utilisateurs; Si récursion il y a, elle doit être bornée avec des limites raisonnable. Si il n'y avait pas eu de possibilité d'exploitation, ça aurait tourné en local DoS, ce qui n'est pas un comportement valable non plus.
    - Le noyau ne devrait pas autoriser le stack à s'approcher d'aussi près de pages déjà allouées. C'est d'ailleurs ce qui a été implémenté comme solution : une page de garde est rajoutée au sommet du stack à chaque agrandissement afin d'éviter que l'application ne se mette à écrire dans des zones qui ne sont pas dans le stack.
    C'est d'ailleurs quelque chose que windows fait depuis longtemps pour séparer les différents stacks des différents threads d'un même processus.

    • [^] # Re: Explication un peu plus complete

      Posté par  . Évalué à 4.

      Tu veut dire que linux ne possède pas de sécurité de la mémoire pour ne pas faire déborder une pile sur un tas ou vis versa ? C'est trivial comme sécurité.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Explication un peu plus complete

      Posté par  . Évalué à 4.

      C'est d'ailleurs quelque chose que windows fait depuis longtemps pour séparer les différents stacks des différents threads d'un même processus.
      C'est ce qui est fait aussi sous linux pour le thread, sauf pour le thread principal (le main) dont la stack est alloué par linux.

      Le flags VM_GROWSDOWN, devrait aussi être rendu obsolète. Ils n'est plus utilisé pour les stacks des thread, et sont intérêt est limité (l'allocation de la stack étant déjà lazy)

      PS : la page de garde peut malheureusement être contournée, si le programme fait des grosses allocations sur la stack (et passe par dessus la page de garde).

      Ha si le hardware avait un flags (comme NX ou W) dans la table mmu, pour contraindre les valeurs pouvant être mise dans le registre de stack (comment ça, on pouvait faire un truc similaire avec la segmentation x86...)

  • # Découvert et corrigé en 2004... puis oublié

    Posté par  . Évalué à 8.

    Pour ceux qui liraient mal l'anglais, ce bug a été découvert en 2004 par Andrea Arcangeli de Suse et soumis aux développeurs du noyau. Pour une raison quelconque, le patch a été oublié dans la branche principale (mais les noyaux Suse ont toujours être patchés).

    source : http://linux.slashdot.org/story/10/08/19/2133246/Root-Privil(...)

    • [^] # Re: Découvert et corrigé en 2004... puis oublié

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

      >>> Découvert et corrigé en 2004... puis oublié

      mmm....d'autres disent que la faille de l'époque n'était pas accompagnée d'un exploit et qu'elle paraissaient donc plus théorique que réelle. Comme en plus le fix d'Andrea Arcangeli était jugé très invasif et "ugly" il n'a pas été accepté.
      Avec l'exploit de 2010 les devs ont pris conscience du souci et un fix minimal et élégant a été implémenté (totalement différent du patch d'Andrea donc).
      Il y a tout un article au sujet de ce bug sur le site LWN: http://lwn.net/Articles/400746/ [article qui sera ouvert à tous jeudi prochain].
      Évidemment, comme à chaque fois qu'il s'agit de sécurité, on retrouve Brad Spengler et PaXTeam dans les commentaires te ça trolle dur. Difficile de savoir qui a vraiment raison dans toute cette polémique.

      • [^] # Re: Découvert et corrigé en 2004... puis oublié

        Posté par  . Évalué à 1.

        Congrats! you just made one more "hacker lever" lwn subscriber.

      • [^] # Re: Découvert et corrigé en 2004... puis oublié

        Posté par  . Évalué à 9.

        Le type a trouvé une faille, l'a signalée à l'équipe chargée de la sécurité et a été assez gentil pour écrire un patch. Aurait-il fallu qu'il perde plus de son temps à écrire un exploit pour être pris au sérieux ? Je ne cherche pas de coupable, mais faut quand même reconnaitre que quelqu'un a merdé. Un mainteneur refuse le patch, fort bien, il lui appartenait de trouver mieux pour résoudre une faille bien réelle qui lui avait été signalée.

        Sur un point de détail : Tu dis que la faille était plus théorique que pratique. Tu remarqueras que à chaque mise à jour de sécurité du noyau, les lecteurs (sur lwn...) critiquent la phrase laconique « users are strongly encouraged to update » en l'absence de précision sur quelle faille est vraiment grave. La réponse c'est que toutes les failles du noyau sont potentiellement exploitables, sans que les mainteneurs aient à réexpliquer à chaque fois les techniques d'exploitation des failles classiques.

        • [^] # Re: Découvert et corrigé en 2004... puis oublié

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

          Yep. C'est d'ailleurs la conclusion de l'article LWN:

          "The most unfortunate aspect of the bug is the length of time it took to fix. Not just the two months between its discovery and fix, but also the five years since Delalleau's presentation. We need to get better at paying attention to publicly accessible security reports and fixing the problems they describe.".

  • # 2.6.35.2 et 2.6.35.3

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

    La dépêche mentionne trois patchs intégrés en 2.6.35.2; en réalité seul le premier est intégré en 2.6.35.2; les deux suivants sont présents en 2.6.35.3

    cf les changelog:
    http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.35(...)
    http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.35(...)

  • # Utiliser X non root ?

    Posté par  . Évalué à 1.

    En donnant les droit du serveur X a un utilisateur qui n'a que les droits sur la carte graphique. Et passer par un script avec le set user bit pour lancer la session des utilisateurs ne pourrait-elle pas suffire ? Au pire, on tombe sur du code exécute avec l'utilisateur X et pas root.

Suivre le flux des commentaires

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