Journal : Graves problèmes de sécurité dans x.org
Posté par herodiade () le 13 mai 2006
Un chercheur français du DCSSI, Loïc Duflot, à récemment publié un papier[1] sur un trou de sécurité dans l'architecture même de x.org, faille suffisante pour circonvenir les protections habituelles (type SELinux, GRsecurity etc).
La description du problème est assez complexe mais securityfocus a publié une interview de Duflot très éclairante[2] : 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).
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 [3][4]? 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ées par OpenBSD n'ont pas été intégrées 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. Où n'utilisez pas l'architecture i386.
[1] Papier de Loïc Duflot
http://www.ssi.gouv.fr/fr/sciences/fichiers/lti/cansecwest20(...)
[2] Interview de Loïc Duflot http://www.securityfocus.com/columnists/402
[3][4] Les commentaires peu diplomatiques de Theo de Raadt sur le sujet:
http://marc.theaimsgroup.com/?l=openbsd-misc&m=114738577(...)
http://marc.theaimsgroup.com/?l=openbsd-misc&m=114233317(...)
La description du problème est assez complexe mais securityfocus a publié une interview de Duflot très éclairante[2] : 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).
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 [3][4]? 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ées par OpenBSD n'ont pas été intégrées 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. Où n'utilisez pas l'architecture i386.
[1] Papier de Loïc Duflot
http://www.ssi.gouv.fr/fr/sciences/fichiers/lti/cansecwest20(...)
[2] Interview de Loïc Duflot http://www.securityfocus.com/columnists/402
[3][4] Les commentaires peu diplomatiques de Theo de Raadt sur le sujet:
http://marc.theaimsgroup.com/?l=openbsd-misc&m=114738577(...)
http://marc.theaimsgroup.com/?l=openbsd-misc&m=114233317(...)
> Lire le journal (85 commentaires, moyenne: 4,3).
Vous avez demandé le commentaire #711349.
Run by 
Cette page a été générée par Templeet en 0.1164s (dont 0.0117 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Théo : one point - X.Org : (void *)NULL
D'après Théo de Raadt, la solution évidente serait d'avoir une couche d'abstraction entre X et le matériel. Comme il le dit si judicieusement, sous les système de type Unix, les programmes utilisent read() et write() sur des fichiers de périphériques (/dev/*) qui jouent la couche d'abstraction pour contrôler le matériel : les programmes ne dialoguent pas directement avec les chipsets, tâche dédiée aux pilotes de périphérique. Et il a bien raison car seul X.Org semble passer outre ce design.
[^]Re: Théo : two point - X.Org : (signed int)(-1)
Une autre remarque pertinente de Théo de Raadt : depuis des années, on se moquait de Microsoft d'avoir intégrer le système graphique au noyau, mais la solution actuelle d'exécuter X avec les privilèges root avec un accès total et direct au matériel n'est fondamentalement pas meilleure.
[^]Re: Théo : two point - X.Org : (signed int)(-1)
C'est pas un des buts de EGL et XEGL justement ? D'avoir une API dans le kernel avec laquelle dialoguera le serveur X.
[^]Re: Théo : one point - X.Org : (void *)NULL
>> Comme il le dit si judicieusement
Et dans son ton inimitable : the X developers are a bunch of shameless vendor-loving lapdogs
[^]Re: Théo : one point - X.Org : (void *)NULL
oui, et puis lui il s'en fout de toute façon et il peut se gausser de xorg : les vrais unix-warriors n'utilisent pas d'interface graphique pour coder avec 1) VI 2) Emacs (rayez la mention inutile) ou surfer sur le net avec lynx (voire w3c pour les plus rigoristes)
Tous ensemble contre l'esclavitude des logiciels privateurs !
[^]Re: Théo : one point - X.Org : (void *)NULL
voire w3c pour les plus rigoristes
Non, les plus rigoristes utilisent telnet pour surfer.
Hurd will be out in a year (or two, or next month, who knows)
-- Linus Benedict Torvalds, 1991
[^]Re: Théo : one point - X.Org : (void *)NULL
Non, les plus rigoristes écrivent directement en binaire (avec un interrupteur) les trames ethernet dans les registres de leur carte réseau. Les trames réseaux reçues s'affichent sur un moniteur : un pixel blanc correspond à un bit allumé, et un pixel noir à un bit éteint.
[^]Re: Théo : one point - X.Org : (void *)NULL
Pour quoi faire une carte réseau ? une pile électrique* et un emballage de chewing gum et ça roule.
* : une banane peut suffire.
Ah non, ça c'est McGiver...
[^]Re: Théo : one point - X.Org : (void *)NULL
Il faut revenir à la base : 2 pots de yaourts et une ficelle. Ça marche du tonerre.
W-Fenec : Webzine rock/métal/indus
[^]Re: Théo : one point - X.Org : (void *)NULL
Encore que j'ai ouie dire qu'on pouvait intercepter les communications en faisant un noeud avec son propre fil au milieu et en branchant son propre pot de yahourt. La communication est dégradée mais ça fonctionne. On peut même émettre.
Il serait temps de faire du SoPY (du SSL over Pot de Yahourt)
[^]Re: Théo : one point - X.Org : (void *)NULL
en même temps il a pas tord, pourvu qu'ils (Xorg/XFree) reconnaissent leurs erreurs et qu'il ne prolonge pas dans ce genre de commentaire : http://marc.theaimsgroup.com/?l=xfree86&m=11474472190755(...)
à mon avis Théo a raison, il faudra créer une couche d'abstraction pour la vidéo dans chacun des noyaux (linux, *bsd, ...) et une API commune, et XFree|Xorg devra utiliser cette couche et rien d'autre. Pour avoir au final un serveur X qu'on lance en nobody.
M.
eucd.info : sauvons le droit d'auteur !!!
[^]Re: Théo : one point - X.Org : (void *)NULL
Pourquoi créer une couche, des drivers propres en noyau feraient l'affaire...
Pour ça on a besoin que nvidia/ati libère les specs de leur cartes.
Après il y a plus qu'a faire des drivers en modules qui n'autorisent que les fonctions nécessaires au fonctionnement des dits drivers ainsi que les plages d'accès de confiance.
Dans le pdf des chercheurs il le disent bien, on peux donner des accès dma a du code ring3 dans un module/pièce de code ring0.
Mais on ne peux le faire que si dans tous les cas ce que va faire le code ring3 ne peux pas compromettre le code ring0 ou le modèle de sécurité qui le maintient en sûreté (page de mémoire, accès interruptions/PIO/MIMO/etc protégées).
Il y a quelque temps on parlais des modules binaires qui pouvais prendre en otage l'utilisateur entre un système non fonctionnel et un système avec un trou de sécurité.
Malheureusement en voici un exemple concret :'(
Il serait bon que les constructeurs de cartes graphiques se réveillent et lâchent les spécificités techniques de leur cartes afin qu'on puisse avoir un système sur !
Je pense que par exemple les modèles basés sur les drivers DRI ne doivent pas êtres affectés par ce genre de trous de sécurité...
Le risque c'est que dans quelques jours/semaines/mois/années on voie arriver des supères images 3D de la mort qui contiennent du code pour viroler l'os en traversant toutes les couches...
site perso : http://rapsys.free.fr/
[^]Re: Théo : one point - X.Org : (void *)NULL
parce que c'est comme ça qu'on fait pour tout le reste, la commande ls ne tape en RAW dans ton disque dur, et c'est normal, non ?
donc pas de raison que X le fasse pour la carte graphique.
la solution des pilotes graphiques dans le noyau est mauvaise car :
déjà comme tu le dis il faut que ATi et Nvidia, lache les specs, c'est donc mal barré.
il faudrais chaque OS qui utilise Xorg ou XFree, donc les distribs à base de Linux, FreeBSD, NetBSD, OpenBSD et autre dérivés, OpenSolaris (je compte pas Hurd ;) ), ai des développeurs + mainteneurs noyau des pilotes.
donc à chaque changement dans le pilote il faut que chaque mainteneur de chaque team noyau fasse les modifs, c'est assez contre productif.
Tandis que si chaque noyau implémente une API bien défini par une team tiers (Xorg) qui elle s'occupe de faire des pilote en se foutant de l'OS qui va faire tourner les drivers, c'est quand même du temps de gagner et bien plus propre.
M.
eucd.info : sauvons le droit d'auteur !!!
[^]Re: Théo : one point - X.Org : (void *)NULL
je parlais d'un module noyau qui autorise les plage de DMA en fonction des cartes et les divers registres nécessaires au cartes en question...
Je pense que les drivers de NVIDIA, ATI et co on juste besoin de pouvoir taper directement dans la RAM embarquée de leur carte et de faire de la magie sur leur registres.
Il n'ont surement pas besoin de quoi que ce soit d'autre.
En fait le problème est que ce serait un module qui ferait une sorte de liste blanche des choses autorisées.
(le dri doit ptet faire pareil).
Après ça empêche pas le driver proprio de faire des conneries avec sa carte graphique, mais au moins dans le pire des cas il ne peux pas compromettre le reste, un gros bac a sable en fait...
Le problème est que ce genre de chose permettrait surement d'intercepter toutes les communications entre le driver et la carte et donc de reverser les drivers.
site perso : http://rapsys.free.fr/
[^]Re: Théo : one point - X.Org : (void *)NULL
Heu j'ai compris différement cette remarque de TdR (me semble pas qu'il parle spécifiquement de /dev, si ?).
Il me semble qu'il dit que sous Unix les programes userland utilisent read() et write() pour écrire ou lire sur le disque.
Donc que les progs userland utilisent des interfaces bien définies du noyau (des appels systèmes POSIX) plutôt que d'aller taper directement dans les registres du chipset SATA (ou SCSI etc.) pour écrire ou lire sur un disque dur ou une carte réseau.
Et c'est le noyau qui se charge de causer au hardware pour faire la jonction (et au passage, nettoyer les requetes malsaines, optimiser, utiliser des caches, gérer les droits, les accès concurents etc.). Heureusement !
Sous entendu: les developpeurs x.org devraient faire pareil et définir un jeu d'appels systèmes aux interfaces définies (comme l'a fait POSIX pour l'accès à d'autres matériels) plutôt que de requierir des droits root et de taper en direct dans le hardware. Ce qui, au delà des questions de sécurité, est aussi intéressant pour des raisons de bon sens (qui n'a pas subit un gel complet de son système à cause d'un déconnage de X11 ?).
[^]Re: Théo : one point - X.Org : (void *)NULL
Il me semble que sous le Hurd, le serveur X ne demande pas de privileges particuliers. Il faudrait verifier.
[^]Re: Théo : one point - X.Org : (void *)NULL
le.. ?
[^]Re: Théo : one point - X.Org : (void *)NULL
C'est moi ou le patch proposé par TdR ne sert à rien ? X accède à la carte graphique en tapant directement dans ses registres pour déclencher des actions et sa "solution" consiste à permettre à l'administrateur de brider voire bloquer l'accès à ces mêmes registres. Sauf que si on active cette option c'est l'explosion en vol du serveur X. S'il tente d'accéder à un registre et que son truc bloque l'accès au mieux l'affichage ne marchera pas correctement, au pire c'est le segfault. Il y a effectivement un redécoupage à affectuer dans X - ce n'est pas nouveau, il n'est pas normal que X gère lui même à sa sauce les périphériques d'entrée et tout le reste qui est déjà géré par l'OS en dessous - mais sa proposition ressemble à un emplâtre sur une jambe de bois.
[^]Re: Théo : one point - X.Org : (void *)NULL
C'est moi ou le patch proposé par TdR ne sert à rien ? X accède à la carte graphique en tapant directement dans ses registres pour déclencher des actions et sa "solution" consiste à permettre à l'administrateur de brider voire bloquer l'accès à ces mêmes registres. Sauf que si on active cette option c'est l'explosion en vol du serveur X.
Non, la solution déjà intégrée dans OpenBSD consiste à pouvoir fermer totalement le fameux accès problématique direct aux registres des cartes graphiques (TdR indique seulement que ça va être vérouillé par défaut dorénavant).
Il va donc de soi que cette solution est faite pour les gens qui ne veulent pas faire tourner X.
"Pourquoi ?" me direz vous. Et bien vous n'avez pas suivi ;)
(je doit reconnaitre que j'ai un peu lancé ça dans le journal même).
Contrairement à ce qui a été dit ici, faire ou ne pas faire tourner X ne change rien à la présence du problème, du moins tant qu'on n'utilise pas une solution comme celle indiquée par TdR (sysctl machdep.allowaperture=0).
Et oui, car la place est désormais ouverte dans le kernel pour qu'un processus root puisse taper dans les registres de la carte graphique.
Cette "ouverture" est bien sûr prévue pour les serveurs X, mais n'importe quel processus root peut y accéder !
Le machdep.allowaperture=0 dont parle TdR permet à OpenBSD de reboucher ce trou (ne pas autoriser les accès directs aux registres hw pour x.org et pour les autres).
Moralité, si vous utilisez des serveurs i386, n'installez pas X11 ... et utilisez OpenBSD ;)
[^]Re: Théo : one point - X.Org : (void *)NULL
Oui, enfin, si le serveur X ne tourne pas, quel processus root va accéder au registres de la carte graphique? Le serveur apache?
Non, sérieusement, ce problème est grave mais il ne faut pas verser dans la paranoia non plus!
[^]Re: Théo : one point - X.Org : (void *)NULL
N'importe quel processus root avec une faille permettant l'execution de code arbitaire.
[^]Re: Théo : one point - X.Org : (void *)NULL
Plus précisémment, n'importe quel processus root avec une faille permettant l'execution de code arbitaire, et avec un méchant pirate en train d'exploiter la dite faille comme un porc.
[^]Re: Théo : one point - X.Org : (void *)NULL
Oui enfin dans ce cas là pas besoin de problème avec le serveur X, tu es déjà root et tu peux faire ce que tu veux. Je vois toujours pas le problème, désolé!
[^]Re: Théo : one point - X.Org : (void *)NULL
Imagine qu'une faille dans apache permette de gagner les droits de root et d'exécuter du code. Mais comme l'admin est prudent, apache s'exécute dans une cage et donc les dégats sont limités.
Sauf qu'avec cette faille il est possible au méchant pirate de quitter la cage puisqu'il a les droits root et que donc il peux exécuter le code dangereux de cette faille. En quittant la cage, imagine ce qu'il peut faire (supprimer tous les mail du serveur de mail qui tournait dans une autre cage etc...)
Mais bon, pas de crainte puisque l'admin est consencieux et qu'il fait des sauvegardes régulières :-)
[^]Re: Théo : one point - X.Org : (void *)NULL
Je pige pas bien moi cette histoire de cage. Si tu pouvais détailler ça m'interesse. Est ce que tu parles d'un apache qui tournerait sous un os émulé et donc tu serais en root que sur la machine virtuelle ou t'as une autre idée en tête?
Le wiki de l'association culture libre : collection d'œuvres sous licence art libre.
[^]Re: Théo : one point - X.Org : (void *)NULL
Mot clé : chroot (change root)
En particulier, cet article Wikipedia me semble assez correct dans son explication des avantages et des limitations de chroot :
http://en.wikipedia.org/wiki/Chroot
[^]Re: Théo : one point - X.Org : (void *)NULL
En fait, l'article se focalisait plus sur les différents niveau de sécurité qu'il y a dans un OpenBSD (d'apres ce que j'ai compris).
Le fait est qu'une fois qu'on verrouille un niveau de sécurité dans OpenBSD, on ne peut plus revenir en arrière. Le document explique que des systèmes matériels permettent de passer outre, et peuvent permettre d'exécuter du code en dehors de toute contrainte au niveau de l'OS (même en root, tu ne peux pas te créer un pointeur vers n'importe ou dans la mémoire, sauf à passer par un mechanisme spécifique de l'OS, que celui-ci contrôle et met à ta disposition gracieusement : /dev/mem).
Le document pointe surtout les failles qui sont accessibles dans des environnements ou même root n'est pas dieu sur la machine.
Forcement, un bureau sous linux sans protection particulière n'est pas concerné par cette attaque puisque le simple fait d'être root ouvre les portes de n'importe quoi. Par contre, un environnement sécurisé pour root (chroot comme dit plus haut, ou encore les niveaux de sécurité introduit par OpenBSD, et sans doute les ajouts de SELinux que je ne connais pas, et plein d'autres trucs) est particulièrement vulnérable à ce genre d'attaque.
Maintenant, si on parle de X, c'est parce que c'est le comportement actuel de X qui oblige les devs du noyau à laisser des trous de sécurité comme ça, pour pleins de raisons d'ailleurs.
N'hésitez pas à me corriger si je dis des choses fausses :-)
[^]Re: Théo : one point - X.Org : (void *)NULL
Merci pour vos réponses éclairantes ^^
J'vais aller lire l'article wikipedia...
Le wiki de l'association culture libre : collection d'œuvres sous licence art libre.
[^]Re: Théo : one point - X.Org : (void *)NULL
>Contrairement à ce qui a été dit ici, faire ou ne pas faire tourner X ne
>change rien à la présence du problème,
Si on n'utilise pas X, c'est carrément aussi bien de ne pas avoir de carte graphique...
[^]Re: Théo : one point - X.Org : (void *)NULL
et les getty alors ? ( non mais F1 a F6 c est fait pour qui ?)
[^]Re: Théo : one point - X.Org : (void *)NULL
Ben, sur le port console ça marche aussi pour ça...
[^]Re: Théo : one point - X.Org : (void *)NULL
L'admin qui a fait l'installation, il y a 5 ans.
[^]Re: Théo : one point - X.Org : (void *)NULL
Je ne sait pas si c'est systèmatiquement le cas, mais les serveurs rackables que j'ai eu entre les mains ont toujours une carte vidéo intégrée dans la carte mère. Pas facile à enlever ! ;)