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 #711673.



et pour le particulier ?
Bonjour à tous
Ce problème de faille m'effraie un peu !
Quels sont les risques pour le particulier qui fait tourner une distribution comme Linux Mandriva 2006 ?
Existe t'il un moyen de se prémunir ?
[^]Re: et pour le particulier ?
Pour le particulier, generalement quand un attaquant passe root, c'est mort ..
Le seul moyen de ce proteger ?
Abandonner X.org (essayer les framebuffer peut être) et passer sous openbsd ...
"Les États-Unis sont le seul pays à être passé de la barbarie à la décadence sans connaître la civilisation." -- (origine réelle inconnue) Albert Einstein/Oscar Wilde/Georges Clemenceau/etc..
[^]Re: et pour le particulier ?
abandonner xorg ne protègera contre rien. La faille elle même est dans le noyeau. Elle est là "pour" xorg mais que xorg soit installé, utilisé ou ne soit pas là du tout n'y change rien.
[^]Re: et pour le particulier ?
Et concrètement, comment savoir que son PC est ou a été "piraté" ou "percé" ?
Existe t'il un moyen de voir qu'il y a un truc sur sa machine qui tourned pas rond ?
[^]Re: et pour le particulier ?
Si j'ai bien compris l'interview (lu en diagonale), le risque, c'est justement que l'OS ne voit rien, parce que les instructions sont exécutées dans un autre mode du processeur lui-même.
Si j'ai bien compris donc, la réponse est non, pas directement, mais comme la faille permettrait de faire exécuter du code arbitraire par le processeur directement, tu peux cramer des disques, brûler des cartes mères (enfin... je ne pense pas, mais ne sait-on jamais), stopper des ventilos (donc cramer le proc), etc, etc. et c'est à ça que tu le verrais, par des signes extérieurs.
J'ai bon ?
[^]Re: et pour le particulier ?
Pour le particulier qui fait tourner une distribution orientée bureautique, les risques sont exactement les mêmes :
il faut être root (super-utilisateur) pour exploiter cette faille. Et sur les distributions orientées bureautique, une fois root, l'attaquant a déjà le contrôle absolu de la machine, donc l'attaque expliquée plus haut n'a aucun interêt (la porte est déjà grande ouverte).
La question se pose pour des serveurs dit "sécurisés" utilisant des distributions spécifiques (SELinux, par exemple) pas du tout conçues pour un usage bureautique (comme mandriva ou ubuntu) ainsi que des cas spécifiques (virtualisation), où précisement être root sur la machine ne donne pas les droits sur le matériel.
Le seul rapport, c'est que ces deux types de distribtutions utilisent (ou peuvent en tout cas) le même matériel (x86 ou autre processeur au fonctionnement équivalent) avec le même prérequis : X doit tourner avec des privilèges spéciaux, voir "spécieux".
[^]Re: et pour le particulier ?
SELinux n'est pas une distribution.
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.