X Graves problèmes de sécurité dans x.org

Posté par . Modéré par Christophe Guilloux.
Tags :
0
15
mai
2006
X
Un chercheur français du DCSSI, Loïc Duflot, a récemment publié un article sur un trou de sécurité dans l'architecture même de x.org, faille suffisante pour contourner les protections habituelles (type SELinux, GRsecurity, etc).

La description du problème est assez complexe mais securityfocus a publié une interview de M. Duflot très éclairante : il s'agit de profiter de l'accès direct (sans passer par le noyau), par X11, a certaines fonctionnalités des processeurs x86 pour pouvoir détourner les flux logiciels, et exécuter du code à l'insu du noyau (et de ses éventuelles couches de protections).

NdA : Merci à herodiade pour son journal. Je vous invite à lire les commentaires intéressants qui ont été faits. L'auteur du journal a ajouté :

"Les développeurs x.org, pour l'essentiel payés par les distributions commerciales, sont-ils trop occupés à coder des environnement 3D ? Ont-ils peur de casser la compatibilité avec les pilotes propriétaires (ATI / nVidia, qui sont maintenant nécessaire pour vendre des distribution commerciales), comme le suppose Theo de Raadt ?

Ce qui est certain, c'est que les patches permettant la séparation des privilèges (réduire le nombre de lignes tournant en root dans x.org) développés par OpenBSD n'ont pas été intégrés par l'équipe d'x.org.

Quoiqu'il en soit, nous allons certainement garder notre trou dans le X pendant quelques années : visiblement, personne chez x.org n'a décidé de régler ce problème (qui requiert, tout de même, un refactoring complet !).

Moralité, mais tout le monde le sait, n'installez pas de serveur X11 sur vos serveurs en production. Ou n'utilisez pas l'architecture i386."
  • # Anglicisme

    Posté par (page perso) . Évalué à  7 .

    En français, on traduit "circumvent" par "contourner", pas par "circonvenir".
    • [^] # Re: Anglouse

      Posté par . Évalué à  7 .

      Et "refactoring" par "refonte", ce n'est pas une traduction littérale mais l'idée ressort mieux.
      • [^] # Re: Anglouse

        Posté par . Évalué à  0 .

        Littéralement, je pense que ce serait refabrication.
  • # petites corrections par rapport au journal

    Posté par . Évalué à  10 .

    Quelques corrections apportées par les commentaires dans le journal:

    - Le titre de la news (repris du journal) etait involontairement trollistique, car x.org n'est pas le seul ni le principal responsable.
    Un titre plus précis mais trop long : « Des déficiences combinées dans l'architecture des processeurs i386 et le design des serveurs XWindows obligent les noyaux de nombreux Unix libres à ouvrir une brèche pouvant être exploitée pour contourner les mécanismes et politiques de sécurité ».

    - La « moralité » que j'avais ajoutée est trompeuse : en réalité il ne suffit pas de ne pas lancer de serveur X11: qu'il tourne ou pas, la brêche est ouverte (accessoirement, sous OpenBSD, on peut dans ce cas précis la refermer avec la commande "sysctl machdep.allowaperture=0").

    Voilà, désolé pour ces imprécisions initiales.
    • [^] # Re: petites corrections par rapport au journal

      Posté par . Évalué à  10 .

      Merci.

      Au passage, quand tu as des info intéresantes comme celle-ci sous le coude et assez de courage pour rédiger une dépêche correcte tu devrais directement la proposer en dépêche plutôt que d'en faire un journal.
      • [^] # Re: petites corrections par rapport au journal

        Posté par . Évalué à  10 .

        Je ne me suis pas senti assez à l'aise pour faire une dépêche (le sujet est ardu et m'échappe largement).

        Mais bon, histoire de détourner les débats du journal vers ici ;), je vais essayer de faire une mini synthèse sur un point qui a été discuté dans le journal, et qui semblait pas naturel pour certains: sur les Unix modernes, le super utilisateur root n'est pas toujours censé avoir tout les droits.

        En particulier, il est généralement admis qu'il est préférable que les utilisateurs (dont root) n'accèdent pas directement au matériel: on préfère qu'ils s'adressent au noyau (qui peut ensuite décider de dialoguer avec le matériel) via une interface bien définie (un appel système). Mais pour des raisons de commodité et de portabilité notamment, x.org et XFree86 dérogent à ce principe et accèdent directement au matériel. Le noyau doit donc ménager une ouverture pour permettre ce genre d'opérations.

        Par ailleurs les Unix libres intègrent parfois des protections permettant de limiter les dégâts que peut causer (volontairement ou pas) les programmes ayant des droits root (acquis et utilisés légitimement ou pas). Par exemple les systèmes BSD incluent généralement un mécanisme appelé securelevel(7) qui peut permettre -entre autres- d'empêcher totalement (même pour root) la modification des fichiers ayant le drapeau "immuable", ou d'écrire sur /dev/mem, ou de modifier le paramétrage du pare feu, etc. En théorie, seul l'administrateur système (la personne physique, à ne pas confondre avec le concept informatique de "root") peut désactiver ces mécanismes lorsqu'il a accès à la console physique de la machine, et avant que le système d'exploitation ne passe en mode multi utilisateur. Le noyau Linux possède lui aussi des mécanisme de confinement (comme SELinux, GRSecurity ou encore RSBAC).

        Mais là où les choses deviennent manifestement ennuyeuses, c'est que l'ouverture noyau donnant accès au matériel permet aussi de manipuler certaines fonctionnalités dangereuses des processeurs i386, lesquelles permettent un accès total à l'espace mémoire (en fait aux 4 premiers Go) à l'insu du noyau. C'est suffisant pour permettre à un logiciel ayant les droits root de détourner toutes les protections noyau évoquées ci-dessus.

        Appréciation personnelle (et sans rapport direct avec la dépêche): x.org est un logiciel énorme (plusieurs million de lignes de code) qui tourne presque totalement avec les droits root. En partie du fait de ce problème de conception, et en partie parce que les développeurs n'ont pas choisi d'intégrer certains mécanismes pour réduire la proportion de code tournant en root (d'où ma remarque amère sur la non intégration des patches d'OpenBSD. Bref, on est assis sur une bombe). Et les récentes failles d'x.org (CVE-2006-1526 et CVE-2006-0745) témoignent des problèmes qu'engendre un si gros programme suid root...

        Voilou.

        Un peu de doc complémentaire:
        Les récentes failles sécu d'x.org:
        http://wiki.x.org/wiki/SecurityPage
        L'implémentation des securelevel(7) sous OpenBSD:
        http://www.openbsd.org/cgi-bin/man.cgi?query=securelevel
        SELinux:
        http://en.wikipedia.org/wiki/Security-Enhanced_Linux
        • [^] # Re: petites corrections par rapport au journal

          Posté par . Évalué à  1 .

          C'est énorme en tout cas, et ne rien faire pour ne pas casser la compatibilité avec des pilotes proprios et bien la preuve qu'on est résolu à ne faire que des concessions et ne jamais s'imposer.
          Après tout, que les distros qui ne veulent pas suivre le pas, ne le fassent pas mais qu'on empêche nullement les correction par peur de voir sa popularité chuter.

          Ou alors est-ce une fausse excuse de la part de X.org, ils n'ont peut-être pas pour l'heure, les ressources nécessaires pour ou l'envie de s'atteler à un si gros morceau.

          Encore une fois, un apport non négligeable d'OpenBSD qui se voit refuser. Absurdité
        • [^] # Re: petites corrections par rapport au journal

          Posté par . Évalué à  6 .

          Je peux essayer de reformuler ? parce que j'aimerais bien comprendre quelle conséquence cette histoire a pour nous autres pauvres utilisateurs. Vous me dites si c'est bien ça ...

          Ce que l'on savait déjà :

          Le serveur X tourne en tant que root, parce qu'il a besoin d'un accès bas niveau au matériel . Le code du serveur X est très compliqué - plusieurs millions de ligne de code, donc il est très vraisemblable qu'il y ait beaucoup de trous de sécurité dedans, qui va permettre a un attaquant de devenir root sur la machine. C'est pour cela que la sagesse populaire conseille de ne pas faire tourner X sur des serveurs critiques.

          Ce qui est nouveau :

          Des techniques complémentaires comme SELinux permettaient, croyait-on de se prémunir contre certaines de ces attaques. Et bien l'article prouve que ces techniques sont inopérantes dans le cas du serveur X sur les processeurs Pentium, parce que X utilise un mode particulier appelé "mode SMM". En exploitant une faille dans le code du serveur X, il est possible d'exécuter du code dans ce mode. On peut alors contourner toutes les protections supplémentaires apportées par SELinux, et permet aussi de sortir d'une machine virtuelle Xen.

          C'est bien ça ? J'ai bon ?
          • [^] # Re: petites corrections par rapport au journal

            Posté par (page perso) . Évalué à  4 .

            En fait il y a deux "proof of concept" (exemple d'exploits).

            L'un utilise le mode SMM pour viander toutes les protections du noyaux et pouvoir obtenir les droits niveau noyau.

            Pour ceci, l'attaquant a besoin d'obtenir les droits de déclancher une intéruptions SMI pour passer en mode SMM et de pouvoir écrire le code qui va bien, là où il faut pour pouvoir exécuter ce code en mode protégé (le noyau n'y voyant rien du tout).

            Concrètement, tu diffuse un module X proprio (genre NVIDIA corrompu), ton root l'installe.
            Ton code modifié va ouvrir une ouverture d'accès direct a la mémoire vidéo légèrement modifié pour écrire dans la partie de mémoire que le mode SMM peut exécuter.
            Après il se débrouille pour lancer une intéruption SMI et paf il charge un module qui lui donne un full accès niveau noyau.

            Le cas concret est un de tes utilisateurs XEN se fait trouer et le pirate veux devenir calife a la place du calife...

            Pour cette faille il est possible de se protéger en posant certains flags qui vont bien pour interdire le lancement de cette instruction SMI.

            Sinon y avais un second hack, mais j'ai déjà oublié...

            Enfin la seule solution pour corriger ça serait d'avoir du code "sûr" en mode noyau (avec une whiteliste des fonctions/registres autorisées) et lasser le code useland en ring3 (tournant sous nobody par exemple).

            Mais pour ça il faudrait que les fabricants de cartes graphiques qui payent ces même développeurs se décident a libérer les specs de leurs cartes :'(
          • [^] # Re: petites corrections par rapport au journal

            Posté par . Évalué à  7 .

            millions de ligne de code, donc il est très vraisemblable qu'il y ait beaucoup de trous de sécurité dedans, qui va permettre a un attaquant de devenir root sur la machine. C'est pour cela que la sagesse populaire conseille de ne pas faire tourner X sur des serveurs critiques.

            Oui et d'ailleurs pas seulement. À mon avis la sécurité n'est pas le seul enjeu dans le cas de « serveurs critiques », la stabilité est aussi très importante ; un gros processus root qui part en sucette peut faire beaucoup de dégâts (surtout un processus root qui en plus cause au matériel par devers le noyau). Ne pas sous estimer la profondeur des sagesses populaires ;)

            Des techniques complémentaires comme SELinux permettaient, croyait-on de se prémunir contre certaines de ces attaques.

            En fait je n'ai indiqué SELinux que pour lister les techniques courantes de confinement sous Linux (en parallèle avec securelevel(7) quoi, pour faire moins OpenBSD-centric ;).
            Mais je pense (il faudrait creuser) que ce n'est pas la protection la plus visée par cette attaque (sauf si par exemple on compte sur lui pour déléguer de façon sécurisée des droits d'accès aux PIO iopl(3) a un utilisateur non privilégié qui ferait tourner x.org). Les « victimes de choix » qui viennent tout de suite à l'esprit seraient plutôt les protections visant à réduire les possibilité du superutilisateur root (sous Linux, type RSBAC ou LIDS).
            La découverte de Duflot montre que dans certaines conditions, root peut faire encore plus de choses que ce qu'on pensait.

            D'autre part, sous Linux précisément, il n'est pas certain que cette faille soit la méthode la plus simple pour ce type de détournement (mais ce n'est pas une raison pour accepter qu'il y en ai une de plus).

            et permet aussi de sortir d'une machine virtuelle Xen.

            Ah oui tu fait bien d'en parler: à priori (cf. l'interview) les machines "invitées" (guest, dom>0) de Xen n'ont pas le droit d'accéder aux PIO, donc non, ils ne peuvent dans ce cas précis utiliser cette fragilité pour sortir. Xen serait donc une bonne protection.
        • [^] # Re: petites corrections par rapport au journal

          Posté par . Évalué à  10 .

          Xorg (XFree86) est vieux, très vieux. Il y a quelques années peux de systèmes d'exploitation offraient une interface intéressante pour accéder aux BUS PCI et aux matériel. A l'époque XFree86 a donc développer ses propres routines d'accés aux bus (PCI, ISA, ...) et ses drivers. Mais pour ne pas reécrire 50 fois la même chose les drivers ont étés réalisés en user mode (pas besoin d'écrire un driver pour chaque OS et X tourne sur bcp d'OS (solaris, bsd, vm, linux, ...)).

          Les dévelopeurs d'Xorg ont bien conscience qu'aujourd'hui ce schéma posse problème. Ils réflechissent à comment évoluer vers un système plus sein, et ce bien avant la publication de Loic. Seulement l'impératif pour les développeurs c'est de ne pas tout casser du jour au lendemain mais de progresser petit à petit.

          Par exemple actuellement bcp de développement porte sur l'utilisation du librairie générique d'accés aux bus pci (agp, pcie, ...) qui utiliserait le noyau (bsd, solaris, linux, ...).

          Par ailleur pour complétement s'affranchir du problème il faudrait un modèle de driver comme celui utiliser par le DRI avec un module noyau (DRM). Mais pour le moment cette solution n'est pas envisageable car trop peux de noyaux ont l'architecture DRM (linux et freebsd seulement).

          Cependant sun a commencé à développer un DRM pour le noyau solaris. Il faudrait qu'OpenBSD face de même ainsi que netbsd et les principaux OS aujourd'hui "officielement" supportées aurait l'architecture nécessaire pour un modèle de driver graphique "secure".

          Nota bene: DRM c'est pas pour Digital Right Management mais pour Direct Rendering Manager

          Voila, il ne faut donc pas cracher sur les développeurs d'Xorg (c'est pas gentil ;)) de plus très peux d'entre eux travaillent activement sur Xgl ou AIGLX, la grande majoritée s'occupe de retravailler Xorg afin de corriger les bugs de conceptions et de repartir sur des bases solides (XCB, Xinput, libpci, ...).
          • [^] # Re: petites corrections par rapport au journal

            Posté par (page perso) . Évalué à  10 .

            comment évoluer vers un système plus sein,

            Un système plus sain, car il y a des failles au sein du programme.
            Saint Xorg, protégez-nous ! ;-)
            • [^] # Re: petites corrections par rapport au journal

              Posté par . Évalué à  4 .

              Argh décidement l'orthographe sera toujours mon pire ennemi :)

              Sinon petite précision supplémentaire (je viens d'y penser après un petit tour sous gdb ^^) il est bcp plus facile de faire du "reverse engineering" (j'aime pas trop l'expression francaise :d) d'un driver en user mode qu'un driver dans le noyau.

              Je pense notament à la lecture des registres (mmio) ou encore au "man in the middle" (bcp plus dure mais tellement plus instructif).

              Quand on voit que le seul constructeur à fournir ses spécifications compléte est intel, on ne peut que penser que le reverse engineering est nécessaire. Enfin c'est mon opinion (j'aime pas les blobs binaires dans le noyau >->)
          • [^] # Re: petites corrections par rapport au journal

            Posté par . Évalué à  2 .

            Par ailleur pour complétement s'affranchir du problème il faudrait un modèle de driver comme celui utiliser par le DRI avec un module noyau (DRM). Mais pour le moment cette solution n'est pas envisageable car trop peux de noyaux ont l'architecture DRM (linux et freebsd seulement).

            Cependant sun a commencé à développer un DRM pour le noyau solaris. Il faudrait qu'OpenBSD face de même ainsi que netbsd et les principaux OS aujourd'hui "officielement" supportées aurait l'architecture nécessaire pour un modèle de driver graphique "secure".


            Tant qu'on parle de sécurité et de code "propre", je voudrais en profiter pour poser une question, moi qui ne suis même pas développeur: Le concept même de l'architecture DRM ne pose-t'il pas un problème de sécurité ? A part les performances, que reproche-t'on à Utah-GLX (dont j'ai cru comprendre que le code fonctionne intégralement en user-mode) ?
            • [^] # Re: petites corrections par rapport au journal

              Posté par . Évalué à  3 .

              Je suis trop jeune pour connaitre les raisons qui ont poussées à abandonner le projet Utah-GLX. Il me semble néanmoins (j'ai une connaissance très limité d'utah dc pardonnez mes erreurs) que le problème été justement la sécurité.

              Le module DRM du noyau est vraiment minimaliste pour chaque carte video. Il "scan" les packets de command qui pourrait être dangereux, grosso modo tous les packets qui concernent le transfert de donnée entre la CG et la ram ou la ram et la CG. Il vérifie donc que le processus qui envoit les commandes à le droit d'accéder à la plage d'addresse spécifier. Pour le reste le DRM se contente de faire un bete copier coller (pas exactement ca) des commandes vers la carte graphiques.

              Il me semble, mais je peux me tromper, que le meilleur endroit pour faire ce genre de controle c'est dans le noyau. C'est pourquoi utah présentait un modèle 'moins secure'.

              Il existe un document qui traite de cela:
              http://dri.sourceforge.net/doc/security_low_level.html

              De plus un thread viens de réapparaitre sur la mailing list d'xorg:
              http://lists.freedesktop.org/archives/xorg/2006-May/015368.h(...)

              Voir notamment les interventions de Dave Airlie et d'Alan Cox
              http://lists.freedesktop.org/archives/xorg/2006-May/015369.h(...)
              http://lists.freedesktop.org/archives/xorg/2006-May/015377.h(...)
              • [^] # Re: petites corrections par rapport au journal

                Posté par . Évalué à  3 .

                Intervention d'Alan Cox :
                1. "X server *REQUIRES* access to the raw hardware"
                Well actually it doesn't. Whether you bitbang hardware, use a kernel
                provided interface for the card or just some kind of mediated hardware
                interface (eg one that allows only the relevant ports to be accessed) is
                entirely a matter for the driver. In the Linux case you will find all of
                the variants


                D'après lui X n'accède pas directement au matériel, il est bien placé pour le savoir non?
                Soit je comprends pas bien, soit cela remet en cause la base sur laquelle se fondent ces fameuses failles.
                Si SElinux est fait pour surveiller ce qui se passe dans le noyau, je ne vois pas comment cela peut lui échapper
                Dave Airlie est assez ironique/vexé, en pretextant qu'on ne va pas accuser le noyau pour toutes les failles potentielles, nombreuses, de X...
        • [^] # Re: petites corrections par rapport au journal

          Posté par . Évalué à  1 .

          Mais pour des raisons de commodité et de portabilité notamment, x.org et XFree86 dérogent à ce principe et accèdent directement au matériel.

          Pas forcement : man fbdev

          The fbdev driver supports all hardware where a framebuffer driver is
          available. fbdev uses the os-specific submodule fbdevhw(4) to talk to
          the kernel device driver. Currently a fbdevhw module is available for
          linux.
          • [^] # Re: petites corrections par rapport au journal

            Posté par . Évalué à  3 .

            Toute personne saine (j'ai bon pour l'orthographe ? ;)) d'esprit n'utiliserait pas fbdev quand une acceleration et disponible et encore une fois ici seul linux (a ma connaissance et d'après man fbdev) posséde un module fbdevhw.

            Enfin l'interface définit par fbdev me semble trop minimaliste pour tirer profit des cartes graphiques d'aujourd'hui. Mais la solution qui me semble la plus adapter pour régler ce problème est bien celle d'un module noyau pour chaque carte graphique. Ce module s'occupant des tâches sensible et pénalisant le moins possible l'accés à la carte graphique et à ses fonctionalités. Une grande partie du driver de la carte resterait néanmoins en user mode (facilitant la programmation et aussi le portage sur différent OS).

            Néanmons cette solution ne me semble pas réalisable dans un avenir proche aux vues de la pluralitées des systèmes supportés par Xorg.
  • # xegl ?

    Posté par (page perso) . Évalué à  5 .

    Salut à tous,

    Est-ce que l'architecture d'Xegl n'a pas ce problème ? Est-ce que ce problème pourrait accélérer le passage à Xegl ?

    Étienne.
  • # accès direct = DRI ?

    Posté par (page perso) . Évalué à  -9 .

    Il ne suffirait pas de désactiver le support DRI dans le noyau ? (Et pis si vous compilez pas vos kernels vous avez des ptits zizis !).

    DLFP >> PCInpact > Numerama >> LinuxFr.org

    • [^] # Re: accès direct = DRI ?

      Posté par (page perso) . Évalué à  0 .

      Et pis si vous compilez pas vos kernels vous avez des ptits zizis


      en fait pas tout fait, c'est ceux qui savent se servir de leur zizi qui utilisent des distribs avec un kernel correctement compilé et des outils qui permettent de compiler des modules simplement (m-a) !

      --> []

      M.
  • # Patch des bootloaders

    Posté par (page perso) . Évalué à  6 .

    Hello,

    Pourquoi ne pas patcher les bootloaders x86 (lilo, grub, etc.) pour qu'ils fassent ce que le BIOS devrait faire lui-meme, c.a.d activer le bit D_LCK pour vérouiller la faille en interdisant l'accès à la zone mémoire SMM.

    Même si cette solution ne remplace pas une refonte de la sécurité, elle a le mérite d'être efficace très rapidement.

    A+
    • [^] # Re: Patch des bootloaders

      Posté par . Évalué à  6 .

      Parce que le code pour le faire est différent en fonction du chipset...
      De plus, c'est pas dit que tout les chipsets fournissent les spec pour le faire...
  • # x.org = mal conçu et a besoin de programmeurs et d'idées !

    Posté par (page perso) . Évalué à  0 .

    X (que x.org suit) est une usine à gaz et n'est pas sûr :

    - remplis trop de fonctions inutiles.

    - passe directement par le matériel (carte graphique, rom video, souris, etc.) au lieu de passer par le noyau !
    "X est-il une application ou un système d'exploitation ?"

    - il utilise root
    "Le noyau Linux contient environ 10 millions de lignes de code qui fonctionnent en root. Le serveur X contient 16 millions de lignes de code dont certaines sont exécutées en root. Si vous recherchez des trous de sécurité, où avez-vous le plus de chance ?"
    "Il n'y a aucune raison technique exigeant du serveur X de fonctionner en root."

    Donc il faut en refaire la conception de A à Z et même plus.

    Et pour cela X.org a besoin de toi !

    Voir ces articles :
    http://linuxfr.org/2005/10/06/19684.html
    http://linux.tlk.fr/traitement-graphique/
  • # Quelle distribution est sécurisée ?

    Posté par . Évalué à  1 .

    Ne sachant pas clairement qui utilise X, qui ne l'utilise pas, qui est affecté par cette faille, qui ne l'est pas, j'aimerai savoir quels sont les systèmes d'exploitation sécurisés à ce jour ? Quelles distributions installer sur un nouvel ordinateur pour éviter les failles potentielles ? Merci

Suivre le flux des commentaires

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