Grosse faille de sécurité dans le serveur d'affichage Xorg 1.11
Une très grosse faille de sécurité vient d'être découverte dans le serveur d'affichage Xorg (version >= 1.11), utilisé par la plupart des distributions GNU/Linux. Une combinaison de touches spéciale permet de déverrouiller l'écran de veille, sans avoir besoin de renseigner le mot de passe.
Les touches à utiliser sont Alt + Ctrl + * . Attention, il faut se servir du caractère étoile du pavé numérique pour que cela fonctionne. Côté technique, cette combinaison envoie tout simplement un signal qui fait un kill sur le processus d'économiseur d'écran.
J'ai pu tester cet exploit avec succès sur une Fedora 16 et l'économiseur d'écran Xscreensaver activé. Les versions que j'utilise sont les suivantes :
$ rpm -qa | grep "xorg-x11-server-Xorg\|xscreensaver-base"
xscreensaver-base-5.15-3.fc16.x86_64
xorg-x11-server-Xorg-1.11.2-3.fc16.x86_64
Cela devrait marcher aussi pour Debian Testing, Debian Sid, ainsi que dans Gentoo et Archlinux. En revanche, la faille ne fonctionne pas sous Ubuntu 11.10, car la version de Xorg est la 1.10 :
$ Xorg -version
X.Org X Server 1.10.4
$ lsb_release -ds
Ubuntu 11.10
Bref, on critique souvent Windows & Co pour ses failles de sécurité, mais là, je pense que GNU/Linux a fait très fort.
Créé en 2005, Tux-planet est un site qui a pour ambition de regrouper des articles sur Linux et le monde des logiciels libres. 
30 Commentaires pour "Grosse faille de sécurité dans le serveur d'affichage Xorg 1.11"
Flux des commentaires de cet article Ajouter un commentairePresque mort concernant Archlinux :
http://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/xkeyboard-config&id=a1bb8eb3bcdcdcbe79e5efc0f6a631fc83409882
Du coup sur ma Linux Mint Debian Edition, j'ai Xorg 1.10.4 et la faille n'est pas présente
"Bref, on critique souvent Windows & Co pour ses failles de sécurités, mais là je pense que GNU/Linux à fait très fort."
Ca c'est petit, très très petit ...
Ca ne concerne que des distribs expérimentales, et la faille, a peine découverte, est probablement déjà résolue ..
Je suis sur qu'il y a un paquet de failles non résolues dans Windows 8 et on n'en fait pas tout un flan, surtout compte tenu de toutes les failles existantes et connues sur des windows stables depuis des années et qui n'ont recu aucun correctif...
Euh... Ubunut, une distribution expérimentale ? Idem pour Fedora, Gentoo et Archlinux ? Et les distributions dérivées de Debian Testing ou de Debian Unstable ?
Sinon, je suis d'accord avec conclusion, le problème est de connaitre l'existence des dites failles de sécurité.
C'est pas vraiment une faille de sécurité dans le sens où on l'entend…
Qui plus est, sous linux, windows ou n'importe quel O, on considère une machine insécurisée dès qu'il y a accès physique possible.
Et puis c'est pas vraiment le boulot du screensaver de bloquer une machine à mon avis. Mais c'est vrai que c'est un peu con de pouvoir le killer sans aucine protection…
Ubuntu, en version non LTS, c'est très expérimental surtout depuis les dernières releases
Fedora est le champ d'expérimentation de Red Hat pour du stable il faut aller voir du coté de RHEL ou CentOS, a la limite Fedora n-1 (donc 15 actuellement)
Gentoo et Arch sont bien réputé pour être ultra bleeding edge donc oui c'est connu de tout le monde que c'est expérimental.
Debian Testing ou Unstable comme leur noms l'indiquent ne sont pas stables, pas de surprises de ce coté la.
Je ne dit pas que ces distribs sont unstables au point d'être inutilisables, perso je déteste toutes ces distros dites stables a cause de leurs logiciels anciens. Je n'utilise que du bleeding edge, mais en connaissance de cause.
Jolie découverte ^^ .
Je plussois le commentaire de Lord. C'est moche comme "faille", mais ça n'en est pas vraiment une. avec un accès physique à la machine... bah heu suffit de rebooter sur une clé usb live pour accéder à tout le disque dur.
"Ubuntu, en version non LTS, c'est très expérimental surtout depuis les dernières releases
Fedora est le champ d'expérimentation de Red Hat pour du stable il faut aller voir du coté de RHEL ou CentOS, a la limite Fedora n-1 (donc 15 actuellement)"
Sans oublier la mise à jour d'un paquet de Xorg d'une version 6.06 (ou la 6.10) qui explosait en vol Xorg.
Jamais eu de gros problèmes coté Fedora, les rares fois que je l'ai utilisé.
"Gentoo et Arch sont bien réputé pour être ultra bleeding edge donc oui c'est connu de tout le monde que c'est expérimental."
Ah, mis à part le passage à kmod qui a été chiant, je ne me souviens pas d'avoir vu une archlinux exploser en vol depuis des années. De l'expérimental comme celui-ci, j'en veux quotidiennement.
"Je ne dit pas que ces distribs sont unstables au point d'être inutilisables, perso je déteste toutes ces distros dites stables a cause de leurs logiciels anciens. Je n'utilise que du bleeding edge, mais en connaissance de cause. "
Bleeding-edge != experimental. C'est juste des logiciels frais et faut savoir être prudent, c'est tout.
@FredBezies : @strider : certes c'est petit, mais moi ce que je ne comprends pas, c'est pourquoi de tels raccourcis clavier existent dans le code ?!?
Sinon, Fedora, Archlinux... ne sont pas des distributions expérimentales. Et nul doute qu'Ubuntu échappe à la faille de justesse dans le cas présent.
pacman -Syu ==> Nouvelle révision des paquets : extra/xkeyboard-config 2.4.1-2 2 -> 3
@Plonk : c'est des malades sous Archlinux, ils ont déjà patché ?
Sa affecte que la version de développement de Xorg, donc après c'est aux distro d'utiliser cette version dans leur branche stable ou pas...
@pti-seb : Sinon, Fedora, Archlinux... ne sont pas des distributions expérimentales. Et nul doute qu'Ubuntu échappe à la faille de justesse dans le cas présent.
Surement présente dans la version de développement de la 12.04, donc tuée d'ici là.
Et oui, le code a été patché. Donc, une simple déconnexion-reconnexion qui relance xorg avec le paquet corrigé tue le bug dans l'oeuf.
Du moins pour les malades qui utilisent le dépot testing.
Et non, les développeurs archlinuxien ne sont pas malades, ils utilisent juste du code proche des originaux, ce qui permet un correctif assez rapide en cas de problème.
experimental ça ne veux pas dire que c'est tout cassé ... Les licences GPL et autres mettent explicitement en garde que le fonctionnement des logiciels n'est pas garanti, même si, en général et c'est tant mieux, ça fonctionne plutôt bien.
Les distribs dites stables (Debian Stable, Ubuntu LTS, CentOS, RHEL, SLED) apportent une sorte de ganrantie que les logiciels fournis sont mieux testés, pour SLED et RHEL cette garantie se paye.
Quelqu'un peut m'expliquer dans quel univers parrallèle ceci est une faille de sécurité ?
La faille de sécurité, c'est les screensavers qui se prennent pour des moyens de sécurisation.
C'est pas leur job, c'est une feature kikoolol et auxiliaire au même titre que le porte-gobelet de ta bagnole.
Si tu met 2L de nitro sur ton porte-gobelet et qu'il casse, entrainant la moitié de la ville avec toi, c'est une faille de sécurité nationale de la part de Citroën ?
Pour sécuriser sa session, y'a screenlock qui se fait pas passer pour un screensaver, vlock, qingy même, ou...
....ne *PAS* laisser son ordinateur sans surveillance ?
Si quelqu'un peut poser la main sur le clavier de ton ordinateur allumé sans ton conscentement, t'as déjà perdu. Aucune mesure de sécurité existante à ce jour ne compensera ta négligeance.
Échec et mat.
"Bref, on critique souvent Windows & Co pour ses failles de sécurités, mais là je pense que GNU/Linux à fait très fort."
j'ai bien ri en lisant ça :p
ça n'a rien à voir avec GNU/Linux, c'est les devs de X.org qui ont fait très fort. En règle générale, quand on veut un minimum sécuriser un système on essaie d'éviter X.org et quand bien même ça serait nécessaire on trouve d'autres sécurités qu'un écran de veille (qui concerne que les accès physiques à la machine, en plus)
@koolfy : si on rentre dans les détails, les combinaisons de touches sont visiblement utilisées pour faire du débogage par les développeurs. Ils ont oubliés de les virer, c'est donc bien une faille de sécurité dans le logiciel Xorg.
Les mondes parallèles n'existent donc pas, nous en avons la preuve ici.
@Leo : ton commentaire est assez drôle aussi : "quand on veut un minimum sécuriser un système on essaie d'éviter X.org". Si on t'écoute, il faut virer Xorg, donc toute la couche graphique. Et on fait comment après ? On utilise uniquement le terminal ?
"Bref, on critique souvent Windows & Co pour ses failles de sécurités, mais là je pense que GNU/Linux à fait très fort."
En même temps le titre de l'article précise bien "le serveur d'affichage Xorg 1.11". GNU/Linux va donc très bien sur ce sujet, enfin je crois.
La combinaison de touches ne fait rien sur mon Ubuntu 10.10 (et oui, je suis resté à l'âge de pierre !)
@pti-seb :
"ils ont oublié de le retirer, ça prouve que c'est une faille de sécurité"
euh.... pardon ?
ça ne permet aucun exploit via xorg, ça permet juste de fermer un screensaver.
Un screensaver n'est pas (ne dois pas être considéré comme) un processus critique pour la sécurité de la machine.
C'est donc au mieux un "bug", ou plutot une feature "en trop" et "indésirable" selon certains.
Absolument rien à voir avec la sécurité.
Voir l'analogie du porte-gobelet.
Une faiblesse dans un porte-gobelet c'est chiant, mais ça ne justifie pas de prétendre que Citroën a un énorme problème de sécurité routière et des passagers.
@Pti-Seb Euh... je vois absolument pas le souci. Un serveur (où la sécurité est considérée comme critique) GNU/Linux ça s'administre quasi uniquement en terminal via SSH. Après sur un laptop ou un desktop, on va effectivement avoir besoin de la couche graphique, mais on se soucie moins de ce genre de "détails" de sécurité dans la mesure où de toute façon à partir du moment où l'attaquant a un accès physique à la machine, c'est difficile de faire une sécurité qui tienne. Enfin mon commentaire portait surtout sur le fait que la faille ne venait absolument pas de GNU/Linux mais bien de X.org. Ce sont 2 choses distinctes
Moi j'ai pas de clavier numérique sur mon portable
eh oh, c'est pas une faille!
"les gars j'ai découvert uen faille, si la personne a pas ferme sa voiture a clef, je peux entrer dans sa bagnole"
c'est une feature, déclaré par un mot clef dans le xorg.conf, on peut cracher sur les mainteneurs qui ont fait le choix de mettre celle-ci à on, mais pas sur xorg.
Si on va par la, les magic sysreq key sont aussi une faille. Et oui, verrouiller une session graphique, c'est tout sauf de la sécurité. Comme dis plus haut, vlock (avec les bonnes options) est beaucoup plus adapté si on veut vraiment verrouiller sa machine.
pti-seb: oué, patché sur Arch. Fait la mise à jour avec les miroirs fr le 19 à 11h. Donc, patché depuis encore plus longtemps sur les masters.
On a peut-être déjà répondu à la question mais ça trolle tellement, que j'ai la flemme de tout lire.
Pour ma part, je pense qu'il faut plutôt ce concentrer sur le temps de corrections de la faille, au lieux de tirer à boulet rouge sur le dev, l'utlisateur, la distrib....
Peu importe la taille de la faille, ce qui compte c'est le temps entre sa découverte et sa résolution. C'est la GROSSE différence entre Crosoft et les OS libre, on attend pas des mois pour boucher une faille.
C'est pas une faille (conceptuelle peut etre)
KO marche pas sous arch
Pour les syst et reboot live, je dirais : sur un vrai systeme, les disques sont cryptés
Ne marche pas sur mon ordi, c'est un portable et je n'ai pas de pavé numérique. Il faut croire que les dev ne travaillent que sur des machines de bureau, ou alors avec des claviers USB.
Est-ce une faille ? Oui si on considère que l'écran de veille est une sécurité. Je trouve qu'on en fait un peu de trop.
Bonjour,
C'est mon premier post mais je voulais aider ceux qui ne sont pas sur Arch en précisant que la correction peut etre faite a la main dans : /usr/share/X11/xkb/compat/xfree86
interpret XF86_Ungrab {
action = Private(type=0x86, data="Ungrab");
};
interpret XF86_ClearGrab {
action = Private(type=0x86, data="ClsGrb");
};
---
// interpret XF86_Ungrab {
// action = Private(type=0x86, data="Ungrab");
// };
// interpret XF86_ClearGrab {
// action = Private(type=0x86, data="ClsGrb");
// };
après ça plus de problème.
correction vu sur : https://bugs.archlinux.org/task/27993?project=0
@Gnieark : Tout dépend comment est configuré l'ordi en question ^^ avoir un accès physique à la machine ne veut pas forcément pouvoir dire '' accéder au bios " pour changer l'ordre de boot de l'ordi ni même avoir les ports usb à vue ^^
Maintenant c'est sûre qu'un pc à la vue de tous accessible aisément reste une proie facile alors stable ou pas et fiable ou pas le système n'est pas coupable de la bêtise de certains informaticiens pensant qu'un économiseur d'écran est une parade efficace ^^
L'économiseur d'écran économise l'écran non ? La sécurité n'est pas sa fonction première ^^