Grosse faille de sécurité dans le serveur d'affichage Xorg 1.11


Xorg
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.

Linux se suicide

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.


30 Commentaires pour "Grosse faille de sécurité dans le serveur d'affichage Xorg 1.11"

Flux des commentaires de cet article Ajouter un commentaire
  •  

    Du coup sur ma Linux Mint Debian Edition, j'ai Xorg 1.10.4 et la faille n'est pas présente :)

    RépondreRépondre
    Guilou , le 19 janvier 2012 à 12:51
  •  

    "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...

    RépondreRépondre
    strider , le 19 janvier 2012 à 13:06
  •  

    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é.

    RépondreRépondre
    FredBezies , le 19 janvier 2012 à 13:12
  •  

    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…

    RépondreRépondre
    Lord , le 19 janvier 2012 à 13:17
  •  

    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.

    RépondreRépondre
    strider , le 19 janvier 2012 à 13:20
  •  

    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.

    RépondreRépondre
    Gnieark , le 19 janvier 2012 à 13:26
  •  

    "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.

    RépondreRépondre
    FredBezies , le 19 janvier 2012 à 13:29
  •  

    @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.

    RépondreRépondre
    pti-seb , le 19 janvier 2012 à 13:31
  •  

    pacman -Syu ==> Nouvelle révision des paquets : extra/xkeyboard-config 2.4.1-2 2 -> 3

    RépondreRépondre
    Plonk , le 19 janvier 2012 à 13:32
  •  

    @Plonk : c'est des malades sous Archlinux, ils ont déjà patché ?

    RépondreRépondre
    pti-seb , le 19 janvier 2012 à 13:34
  •  

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

    RépondreRépondre
    AnCaRioN , le 19 janvier 2012 à 13:35
  •  

    @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.

    RépondreRépondre
    FredBezies , le 19 janvier 2012 à 13:37
  •  

    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.

    RépondreRépondre
    strider , le 19 janvier 2012 à 13:44
  •  

    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.

    RépondreRépondre
    koolfy , le 19 janvier 2012 à 13:49
  •  

    "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)

    RépondreRépondre
    Leo` , le 19 janvier 2012 à 13:50
  •  

    @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 ?

    RépondreRépondre
    pti-seb , le 19 janvier 2012 à 13:51
  •  

    "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.

    RépondreRépondre
    spyesx , le 19 janvier 2012 à 14:01
  •  

    La combinaison de touches ne fait rien sur mon Ubuntu 10.10 (et oui, je suis resté à l'âge de pierre !) ;)

    RépondreRépondre
    JackDaniels93 , le 19 janvier 2012 à 14:09
  •  

    @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.

    RépondreRépondre
    koolfy , le 19 janvier 2012 à 14:17
  •  

    @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

    RépondreRépondre
    Leo` , le 19 janvier 2012 à 14:21
  •  

    Moi j'ai pas de clavier numérique sur mon portable ;-)

    RépondreRépondre
    jeanjo , le 19 janvier 2012 à 14:23
  •  

    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.

    RépondreRépondre
    le moine , le 19 janvier 2012 à 15:01
  •  

    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.

    RépondreRépondre
    JeyG , le 19 janvier 2012 à 15:07
  •  

    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.

    RépondreRépondre
    Ypnose , le 20 janvier 2012 à 01:34
  •  

    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.

    RépondreRépondre
    Knah Tsaeb , le 20 janvier 2012 à 09:21
  •  

    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

    RépondreRépondre
    dacrovinunghi , le 20 janvier 2012 à 15:25
  •  

    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.

    RépondreRépondre
    src , le 21 janvier 2012 à 15:05
  •  

    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

    RépondreRépondre
    NEwa , le 23 janvier 2012 à 09:38
  •  

    @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 ^^

    RépondreRépondre
    ACID , le 23 avril 2012 à 04:47
 

Ajouter un commentaire

actualité android apache apple astuce astuces bash bilboblog blog boot chrome clavier commande commandes conky date debian Desktop développement elementary exploit faille fedora firefox flash gimp gnome google graphique Graphisme hack hacking Hardware humour intel internet iphone jailbreak Jeux Kde kernel libre Linux log logiciels Logiciels Libres lucid lynx maemo mail maquette metasploit microsoft mobile mockup monitoring mozilla multi-touch musique mysql n900 nautilus nokia noyau openoffice open source password photos php Planet publicité redhat red hat rpm réseau screenshot script serveur serveurs shell sql ssh statistiques sysadmin system Sécurité thème tux-planet tv twitter ubuntu unity vidéo vidéos vlc voyage wallpaper windows wordpress yum