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."
Aller plus loin
- Article de Loïc Duflot [PDF] (24 clics)
- Interview de Loïc Duflot sur securityfocus (5 clics)
- Les commentaires de Theo de Raadt [1] (5 clics)
- Les commentaires de Theo de Raadt [2] (3 clics)
- DLFP : Le journal à l'origine de la dépêche (13 clics)
# Anglicisme
Posté par Thomas Petazzoni (site web personnel) . Évalué à 7.
[^] # Re: Anglouse
Posté par GhZaaark3 . Évalué à 7.
[^] # Re: Anglouse
Posté par Anonyme . Évalué à 0.
# petites corrections par rapport au journal
Posté par herodiade . Évalué à 10.
- 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 tuiu pol . Évalué à 10.
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 herodiade . Évalué à 10.
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 GhZaaark3 . Évalué à 1.
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 tontonflingueur . Évalué à 6.
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 Raphaël G. (site web personnel) . Évalué à 4.
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 herodiade . Évalué à 7.
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 Raphaël G. (site web personnel) . Évalué à 3.
qui exécute du code directement au niveau hard sur les dernières version ?
[^] # Re: petites corrections par rapport au journal
Posté par Markov . Évalué à 10.
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 Pierre Jarillon (site web personnel) . Évalué à 10.
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 Markov . Évalué à 4.
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 tinou . Évalué à 2.
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 Markov . Évalué à 3.
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 Guillaume_T . Évalué à 3.
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 M . Évalué à 1.
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 Markov . Évalué à 3.
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.
# Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: xegl ?
Posté par Patrick Trauquesègues . Évalué à 2.
http://forum.hardware.fr/hardwarefr/OSAlternatifs/Nouvelle-i(...)
[^] # Re: xegl ?
Posté par Olivier Abad . Évalué à -5.
http://abu.cnam.fr/DICO/excent/index.html
http://members.aol.com/michaemann/jgmain.html
[^] # Re: xegl ?
Posté par Markov . Évalué à 4.
Cependant comme je le disais dans un poste plus haut 99% des développeurs d'Xorg s'occupent d'autre chose qu'Xegl car pour le moment Xegl ne pourrait fonctionner que sur linux ou freebsd et donc ce n'est pas une solution envisageable à cour terme car Xorg supporte aussi solaris, openbsd, netbsd et d'autres OS.
Donc pas d'accélération du passage à Xegl. De plus des OS comme OpenBSD n'accepteront certainement que des drivers open source pour les cartes graphiques (ca c'est bien :)).
# accès direct = DRI ?
Posté par DLFP est mort . Évalué à -9.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: accès direct = DRI ?
Posté par kolter (site web personnel, Mastodon) . Évalué à 0.
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.
[^] # Re: accès direct = DRI ?
Posté par DLFP est mort . Évalué à -1.
DLFP >> PCInpact > Numerama >> LinuxFr.org
# Patch des bootloaders
Posté par David (site web personnel) . Évalué à 6.
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 M . Évalué à 6.
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 cbon linux . Évalué à 0.
- 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/
[^] # la meilleure solution ? Abandonner X et X.org et créer mieux !
Posté par cbon linux . Évalué à -1.
X est vieux et très mal fait.
Il est temps de passer à quelque chose de mieux, de neuf.
Refaire tout ça from scratch.
Peut-être même inclure un serveur graphique basique mais universel dans le noyau ?
[^] # Re: la meilleure solution ? Abandonner X et X.org et créer mieux !
Posté par Didier Raboud (site web personnel) . Évalué à 3.
Bref. Bonne idée [1], en tout cas autant que le Hurd (sur lequel Y devra fonctionner), mais ça va souffrir du même problème que le Hurd : peu de développeurs pour une très bonne idée, donc temps de développement très long, donc désintérêt des communautés.
Dommage.
Conclusion, il faut une très grosse boîte derrière ça qui finance beaucoup de développeurs pour un résultat concurrentiel dans les 2-3 ans.
J'ai bon ?
[1] et je le pense sérieusement.
[^] # Re: la meilleure solution ? Abandonner X et X.org et créer mieux !
Posté par ptitlouis . Évalué à 1.
[^] # Re: la meilleure solution ? Abandonner X et X.org et créer mieux !
Posté par ondex . Évalué à 5.
Il y a un peu de vie sur la Mailing list mais je ne sais pas du tout où en est le projet.
[^] # Re: la meilleure solution ? Abandonner X et X.org et créer mieux !
Posté par Bertrand Jacquin (site web personnel) . Évalué à 4.
http://en.wikipedia.org/wiki/Y_Window_System
http://sourceforge.net/projects/dsywindows/
Salut a toi Romain ;o)
XCB est sur le point de remplacer la Xlib.
http://xcb.freedesktop.org/wiki/
http://bugs.gentoo.org/show_bug.cgi?id=93582
http://lists.freedesktop.org/archives/xorg/2006-April/015073(...)
[^] # Re: la meilleure solution ? Abandonner X et X.org et créer mieux !
Posté par Markov . Évalué à 4.
Ce protocole à aujourd'hui une place de choix dans l'industrie. Il me semble donc inutile de vouloir tout changer en abandonnant un protocol qui a plus que fait ses preuves. On passera un jour au protocol X12 (à cause de certaines limites d'X11).
Le problème ici présenté viens plutot de l'architecture x86 et de l'implémentation des drivers dans le server X (implémentation qui fait aujourd'hui l'object de nombreux travaux voir par exemple la présentation d'Egbert Eich au FOSDEM).
Pour toute personne désirant approfondir ses connaissances d'X je conseille de lire l'article de wikipedia ainsi que les liens fournit dans celui-ci.
http://en.wikipedia.org/wiki/X_Window_System
[^] # Re: la meilleure solution ? Abandonner X et X.org et créer mieux !
Posté par cbon linux . Évalué à 1.
X n'est pas "hardware independant" ?
X ne vient pas du MIT ? (ok ils ont bossé pour Sun, HP, IBM, Digital mais c'est pas l'indusrie qui a fait la recherche, c'est des génies de la fac :-) ).
Voilà de quoi lire :
http://www.art.net/~hopkins/Don/unix-haters/x-windows/disast(...)
http://www.std.org/~msm/common/protocol.pdf
[^] # Re: la meilleure solution ? Abandonner X et X.org et créer mieux !
Posté par Markov . Évalué à 2.
Enfin en ce qui concerne le rendu type postscript, cairo commence à s'imposer, sans pour autant interdire l'existence de programmes qui voudraient controler le rendu au pixel près.
Le deuxième lien est une critique bcp plus constructive de X.
# Quelle distribution est sécurisée ?
Posté par lumina . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.