Journal Graves problèmes de sécurité dans x.org

Posté par  .
Étiquettes :
0
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(...)

  • # En français!

    Posté par  . Évalué à 10.

    Loïc Duflot et ses collègues s'exprimant à la perfection dans la langue de Molière, nous aurions tort de nous priver de leur prose en français:
    http://www.ssi.gouv.fr/fr/sciences/fichiers/lti/sstic2006-du(...)
    (au moins pour le "[1] Papier")

    • [^] # Re: En français!

      Posté par  (site web personnel) . Évalué à 3.

      D'autant plus que la prose est excellente, et le papier remarquablement lisible, pour peu que l'on soit familier avec les principes de fonctionnement des processeurs (notamment x86).

  • # Commentaire supprimé

    Posté par  . Évalué à 10.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 10.

      Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Théo : one point - X.Org : (void *)NULL

      Posté par  (site web personnel) . Évalué à 10.

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

        Posté par  . Évalué à 1.

        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)

        Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

      • [^] # Re: Théo : one point - X.Org : (void *)NULL

        Posté par  (site web personnel, Mastodon) . Évalué à 10.

        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.

        • [^] # Re: Théo : one point - X.Org : (void *)NULL

          Posté par  (site web personnel) . Évalué à 6.

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

          • [^] # Re: Théo : one point - X.Org : (void *)NULL

            Posté par  (site web personnel, Mastodon) . Évalué à 8.

            Pourquoi créer une couche, des drivers propres en noyau feraient l'affaire...


            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.

            • [^] # Re: Théo : one point - X.Org : (void *)NULL

              Posté par  (site web personnel) . Évalué à 2.

              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.

    • [^] # Re: Théo : one point - X.Org : (void *)NULL

      Posté par  . Évalué à 8.

      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

      Posté par  (site web personnel) . Évalué à 0.

      Il me semble que sous le Hurd, le serveur X ne demande pas de privileges particuliers. Il faudrait verifier.

      http://l-lang.org/ - Conception du langage L

    • [^] # Re: Théo : one point - X.Org : (void *)NULL

      Posté par  . Évalué à 7.

      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

        Posté par  . Évalué à 10.

        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

          Posté par  (site web personnel) . Évalué à 2.

          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

            Posté par  . Évalué à 4.

            N'importe quel processus root avec une faille permettant l'execution de code arbitaire.

            • [^] # Re: Théo : one point - X.Org : (void *)NULL

              Posté par  . Évalué à 2.

              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

              Posté par  (site web personnel) . Évalué à 6.

              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

                Posté par  . Évalué à 10.

                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

                  Posté par  (site web personnel) . Évalué à 2.

                  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?

                  • [^] # Re: Théo : one point - X.Org : (void *)NULL

                    Posté par  (site web personnel) . Évalué à 4.

                    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

                    Posté par  . Évalué à 4.

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

        • [^] # Commentaire supprimé

          Posté par  . Évalué à 1.

          Ce commentaire a été supprimé par l’équipe de modération.

  • # CPU

    Posté par  (site web personnel) . Évalué à 8.

    C'est bien la preuve que la monoculture des CPU est aussi dommageable que celle des OS. Cette faille est purement circonscrite aux x86 et elle épargne toutes les autres archi (PowerPC, Sparc etc etc).

    • [^] # Re: CPU

      Posté par  . Évalué à 4.

      Est ce que c'est valable pour les architectures de type IA64, AMD64 ?

      • [^] # Re: CPU

        Posté par  (site web personnel) . Évalué à 6.

        IA64 non.
        AMD64 je sais pas mais je crois que oui étant donné ce que j'ai compris de l'interview de securityfocus.

        • [^] # Re: CPU

          Posté par  (site web personnel) . Évalué à 2.

          This device exists on i386, amd64, alpha, cats, macppc, and sparc64.
          (Other architectures do not need such a thing, since they have less evil).

          Voilà la réponse de TdR

          • [^] # Re: CPU

            Posté par  (site web personnel) . Évalué à 2.

            il me semble que la réponse de théo concerne l'existence du driver "aperture" qui crée une barrière de protection entre xorg et l'os.

            L'article de Loic Duflot évoque lui le fait que l'archi x86 est pourrie à la base et permet de passer à travers les protections de l'os.

            Donc pour résumer : x86 c'est pourri irrémédiablement et, d'autre part, OpenBSD propose d'encapsuler xorg sur les archis i386, amd64, alpha, cats, macppc, and sparc64.

            • [^] # Re: CPU

              Posté par  . Évalué à 2.

              il me semble que la réponse de théo concerne l'existence du driver "aperture" qui crée une barrière de protection entre xorg et l'os.

              AFAIK, c'est le contraire, aperture ouvre une faille dans la politique de sécu du noyau pour permettre à X de faire mumuse avec le hardware comme bon lui semble.

    • [^] # Le côté obscure de Wintel

      Posté par  . Évalué à 6.

      Les processeurs Intel ont toujours été merdique. Et comme Microsoft vend du binaire à prix d'or. Il faut assurer la compatibilité durant une éternité. Par conséquent, on se traîne encore les défauts du 8086 ...

      Sous Linux/Bsd, on peut tout recompiler pour son nouveau processeur, voir même son nouveau microcode!

      Innover dans le domaine des cpu pour le desktop est voué à l'échec. Puisque Windows ne le supportera avant 5 ans ... cf. 64 bits!

      • [^] # Re: Le côté obscure de Wintel

        Posté par  . Évalué à 3.

        Ah voila, je savais bien qu'on allait trouver qq'un pour mettre la faute sur MS...

        • [^] # Re: Le côté obscure de Wintel

          Posté par  . Évalué à 7.

          pour mettre la faute sur MS
          Et ses amis ...
          Imagine que tu est un brillant ingénieur. Tu mets au point un cpu révolutionnaire et pas cher. Crois tu que tu le vendra? Non, car les logiciels au supermarché du coin sont compilé pour un Pentium et un OS dénommé Windows ... Ne dit pas que MS et ses amis favorise l'amd64!

          • [^] # Re: Le côté obscure de Wintel

            Posté par  . Évalué à 4.

            Imagine que tu est un brillant ingénieur. Tu mets au point un cpu révolutionnaire et pas cher. Crois tu que tu le vendra? Non, car les logiciels au supermarché du coin sont compilé pour un Pentium et un OS dénommé Windows ...

            Super, et ? Si t'es un brillant ingenieur et que tu sais ce que tu fais, tu chopes d'abord une societe qui t'aidera a produire et developper la chose, et apres tu envoies des prototypes/simulateurs/ ... avec ton business plan a MS, et si ton CPU est si revolutionnaire que ca et qu'il y a un plan solide pour le futur du CPU, tu seras peut-etre bien surpris du resultat, cf. amd64

            Ne dit pas que MS et ses amis favorise l'amd64!

            Hahaha, si seulement tu savais de quoi tu parles...

            Sans MS l'amd64 n'aurait jamais vu le jour, car sans le support de MS AMD n'aurait pas sorti ce chip, ils n'auraient pas pu le vendre en masse comme ils le font aujourd'hui.

            Quand a savoir si on favorise l'amd64 ou pas, vu que le prochain Exchange ne tournera que sur AMD64, je crois que la question ne se pose meme pas...

            • [^] # Re: Le côté obscure de Wintel

              Posté par  (site web personnel, Mastodon) . Évalué à 9.

              Quand a savoir si on favorise l'amd64 ou pas, vu que le prochain Exchange ne tournera que sur AMD64, je crois que la question ne se pose meme pas...


              han, sai nul, même pas capable de faire un programme portable ...

              M.

              • [^] # Re: Le côté obscure de Wintel

                Posté par  . Évalué à 6.

                C'est pas ça, c'est que Exchange va être tellement gros qu'un espace mémoire virtuel de 2 ou 3 Go tel que disponible sur x86 ça sera pas suffisant /o\

            • [^] # Re: Le côté obscure de Wintel

              Posté par  . Évalué à 6.

              Ne racontons pas non plus n'importe quoi. AMD a réussi à vendre un sacré paquet d'AMD64 parce qu'ils ont un excellent rapport performance/prix, sachant que la plupart des acheteurs n'étaient même pas conscients du fait que le 64 bits ne serait pas exploité par leur Windows 2000 ou XP 32-bits. A titre indicatif, les systèmes libres ont été très largement en avance sur MS sur le support du x86_64.

              Je connais extrêmement peu de personnes qui ont un Windows 64-bits sur leur machine desktop, et pas du tout qui ont installé un serveur sous Windows 64-bits.

              • [^] # Re: Le côté obscure de Wintel

                Posté par  . Évalué à 1.

                C'est pas le probleme, avant meme de le mettre sur le marche, AMD ne l'aurait pas mis en production si MS leur avait dit : "on ne le supportera pas", car les constructeurs n'auraient vu aucun avantage a mettre un CPU plus cher que les cpu 32bits actuels pour un gain de perf futur negligeable.

                Je connais extrêmement peu de personnes qui ont un Windows 64-bits sur leur machine desktop, et pas du tout qui ont installé un serveur sous Windows 64-bits.

                Ca commence petit a petit, MS pousse les constructeurs a sortir des drivers 64bits et bientot la machine de monsieur tout le monde aura ce qu'il faut comme drivers(et les applications devraient suivre).

            • [^] # Re: Le côté obscure de Wintel

              Posté par  . Évalué à 5.

              Sans MS l'amd64 n'aurait jamais vu le jour, car sans le support de MS AMD n'aurait pas sorti ce chip, ils n'auraient pas pu le vendre en masse comme ils le font aujourd'hui.
              Tu affirme en contestant mes propos que MS contrôle le design des cpu Intel et Amd. Tout en sachant que Linux supporte amd64 depuis longtemps. Et que le couple Opteron/Linux est un excelent choix pour un serveur. Mais la vente de serveur Linux ne compte pas ...

              Mais alors pourquoi MS n'a pas amélioré l'archictecture X86? Pourquoi Apple abandonne les power pc pour une architecture merdique? les $$$$ sont plus important?

              • [^] # Re: Le côté obscure de Wintel

                Posté par  . Évalué à 1.

                Tu affirme en contestant mes propos que MS contrôle le design des cpu Intel et Amd. Tout en sachant que Linux supporte amd64 depuis longtemps. Et que le couple Opteron/Linux est un excelent choix pour un serveur. Mais la vente de serveur Linux ne compte pas ...

                Il ne le controle pas vraiment, mais bien evidemment Intel et AMD vont aller discuter avec MS avant de sortir une nouvelle architecture car sans le support de MS, leur CPU ira pas loin, si il ne fait pas tourner Windows, les gens n'acheteront pas.

                Que Linux ait tourne sur AMD64 avant(et encore, la on parle de tourner en public, chez MS les private builds etaient la depuis des lustres...) n'y change rien, il tourne dessus tout simplement parce qu'AMD a eu confirmation que MS porterait Windows dessus, et ont donc lance la production.

                Mais alors pourquoi MS n'a pas amélioré l'archictecture X86? Pourquoi Apple abandonne les power pc pour une architecture merdique? les $$$$ sont plus important?

                A) C'est pas le boulot de MS de faire des CPUs, ils ne savent pas comment faire un truc pareil, et ne sont probablement pas interesses
                B) MS donne regulierement du feedback a Intel / AMD / autres a propos de ce qu'ils aimeraient voir dans les CPUs
                C) Apple <-> PPC, ben c'est simple, l'archi PPC a beau etre "jolie et propre", elle ne repondait pas aux attentes techniques d'Apple, et c'etait pas uniquement une question d'argent si tu veux mon avis(rapport prix/puissance et roadmaps qui n'etaient pas vraiment du cote du PPC notamment).

          • [^] # Re: Le côté obscure de Wintel

            Posté par  . Évalué à 5.

            Bin c'est logique, pas d'utilisateur, pas de profit pour les vendeur de logiciels, donc pas de soft donc pas d'utilisateur, etc.

            Plus le marché est mature, plus c'est dur de sortir du cercle vicieux.

            Rien a voir avec MS à proprement parler, juste des lois économiques.

  • # Risque réel?

    Posté par  . Évalué à 5.

    J'ai sans doute pas tout compris, mais c'est quoi le risque réel?

    D'après ce que j'ai compris l'exemple d'exploit requiert d'être root! (ou d'injecter du code dans un process avec suffisemment de droit délégué... genre X).

    Et il s'agit bien d'une escalade de privilège mais pas dans le sens ou roger (simple user ayant à peine accès à vi) devient pierre (super user pouvant utiliser emacs, troll inside :p) mais ou root user mode peut exécuter du code kernel (encore faut-il en faire qqch...).

    J'avoue avoir du mal à imaginer le genre d'attaque qu'on peut imaginer avec ce truc? Des idées?

    • [^] # Re: Risque réel?

      Posté par  . Évalué à 7.

      En fait, cela permet de contourner toutes les protections noyaux contre les possibles abus de root (l en existe plein: par exemple les securelevels, SELinux, GRsecurity, les protection contre les rootkits, ou par exemple un processus root peut alors sortir d'une cage chroot() ...).

      De plus, Duflot fait remarquer que cette faille permet d'écrire dans des zones non volatiles sur certains matériels (comprendre: de véroler la machine, au sens matériel, de façon résistante aux reboots et réisntallations d'OS).

      Aussi convient-il de noter qu'x.org s'éxecute en très grande partie avec les droits root (surtout sur les autres plateformes qu'OpenBSD).

    • [^] # Re: Risque réel?

      Posté par  . Évalué à 3.

      Et il s'agit bien d'une escalade de privilège mais pas dans le sens ou roger (simple user ayant à peine accès à vi) devient pierre (super user pouvant utiliser emacs, troll inside :p) mais ou root user mode peut exécuter du code kernel (encore faut-il en faire qqch...).

      ça peut servir à plein de chose de passer du securelevel 2 au -1, par exemple, charger un module pour cacher ton rootkit, modifier la conf du firewall, monter/démonter des partitions, et de permettre tout ce qui est interdit ou limité par la valeur du securelevel ..

      • [^] # Re: Risque réel?

        Posté par  . Évalué à 3.

        oui mais non, cela sous-entend une faille dans x.org permettant d'injecter du code... et ce code tourne avec des droits root, donc on est dans la m... peu importe que X permette ou non après d'exécuter en ring 0. L'auteur pars du postulat qu'il y'a des failles! (cela pourrait être vulgarisé en: ne pas laisser trainer d'allumette chez vous, si un pyromane rentre, il pourrait bruler la maison...)

        side note: L'une des premières assomptions d'une analyse sécuritaire est que l'admin n'est PAS hostil, si c'est le cas, en général c'est inutile de chercher plus loin (mauvais admin, changer d'admin).

        Je ne suis pas en train de dire que c'est idiot/faux/stupide, au contraire, je trouve cela plutôt intéressant, mais ptêt le risque n'est pas aussi important que l'article semble le présenter...

        Pour ma part, j'ai tendance à croire qu'il faut choisir: un système au design pur, évitant tout risque, quitte à devoir faire des compromis par rapport au feature et à la rapiditié (qui à dit Hurd? :p) ou accepter certain compromis qui pourrait mener à des risques de sécurité. Je sais que je vais faire bondir certains puristes de la sécurité, et je les comprends, on ne devrait pas avoir à choisir, mais pourtant c'est la réalité, surtout quand on est relativement en concurence avec des OS qui ont fait des choix du genre (je pense à windows: le fait d'avoir une appli graphique fonctionnant avec des droits root sur une machine, peut permettre d'obtenir un shell root, it's "by design").

        Ptêt aussi que c'est parce que je pense que X n'a rien à foutre sur un serveur et que s'il est installé sur un desktop, je préfère qu'il soit rapide, joli, efficace, ergonomique que théoriquement secure... (je dis théoriquement parce que pratiquement il ne le sera pas, et le risque à mon sens est avant tout de perdre mes documents, pas de compromettre mon hardware...). Je peux donc comprendre que les développement aille vers du "eye candi" plus que du "parfaitement secure" (qui a dit Xgl?)

        • [^] # Re: Risque réel?

          Posté par  (site web personnel) . Évalué à 7.

          >> ce code tourne avec des droits root, donc on est dans la m... peu importe que X permette ou non après d'exécuter en ring 0

          Le but des projets de type SELinux c'est justement de limiter la toute puissance de root. Ils veulent gérer les droits de façon plus fine et plus efficace en évitant le modèle du root tout puissant. Hors ce "problème" évoqué par Loïc Duflot casse complètement le modèle de sécurité de SELinux !
          Idem pour Xen : c'est une sorte de virtualisateur utilisé notamment pour la consolidation des serveurs. On a une seule machine et dessus on fait tourner plusieurs instances de Linux qui sont virtualisés à l'aide de Xen. Dans chacun de ces Linux on peut avoir un root différent et celui-ci, en dépit de son statut de root, ne peut pas aller foutre le bordel dans les autres instance de Linux du fait de la virtualisation.
          La encore la faille détecté explose ce modèle de sécurité et permet à un des root de pénétrer au sein même du hardware (donc en dessous de la couche Xen).

          En résumé c'est quand même un grosse faille et ce sera très difficile de s'en sortir sans passer par un refactoring de Xorg...Donc cela va être long et pénible...donc en attendant il faut éviter d'installer Xorg sur des serveurs x86.
          Peut être est-ce l'occasion d'aller voir d'autres architecture CPU ?

          • [^] # Re: Risque réel?

            Posté par  (site web personnel) . Évalué à 10.


            en attendant il faut éviter d'installer Xorg sur des serveurs x86.


            Hum... sur la plupart des systèmes, si X n'est pas installé, un attaquant qui devient root peut quand même utiliser cet accès au matériel pour contourner la protection de l'OS. Pour éviter cela, il faudrait en plus qu'il y ait un sysctl comme c'est le cas dans OpenBSD, de manière à ce que l'accès au hardware soit bloqué si on utilise pas X.

          • [^] # Re: Risque réel?

            Posté par  (site web personnel) . Évalué à -1.

            Donc ca impacte uniquement les utilisateurs de SELinux et compagnie. C'est a dire finalement pas grand monde meme du coté des serveurs.

            • [^] # Re: Risque réel?

              Posté par  (site web personnel) . Évalué à 3.

              Si j'ai bien compris, c'est pas que ça impacte uniquement SELinux, c'est plutôt que ça impacte même SELinux, qui est censé tout dé-rooter, non ?

              • [^] # Re: Risque réel?

                Posté par  (site web personnel) . Évalué à 2.

                La faille n'est exploitable que si tu es déjà root. Et si tu es root sur une machine sans SELinux/chroot/équivalent, tu as déjà les pleins pouvoirs, alors un faille qui te permet d'augmenter tes privilèges, tu t'en fous un peu ...

                • [^] # Re: Risque réel?

                  Posté par  (site web personnel) . Évalué à 2.

                  Pas sûr: sur OpenBSD le serveur X tourne en tant que "_x11", donc quelqu'un qui le compromet pourrait peut-être utiliser cette méthode pour devenir root.

                  Sinon, même sur les autres systèmes, root ne peut en théorie pas tout faire. Par exemple cela pourrait servir pour insérer un rootkit noyau de manière discrète (même s'il faut reconnaître que la plupart du temps, il y a des méthodes plus simples). Mais c'est vrai que c'est surtout pour ceux qui se fient à des méthodes de confinement que cela pose problème.

        • [^] # Re: Risque réel?

          Posté par  . Évalué à 0.

          En réalité, et contrairement à ce qu'on pourrai croire, root de devrait pas avoir *tout les droits* sur les Unix modernes. En particulier, il n'est pas censé pouvoir lire/modifier arbitrairement toutes les structures de données du noyau.

          Voilà quelques exemples simples qui montrent que root (ou disons, un root illégitime, autre que la personne qui a choisi les options au boot) ne devrait pas pouvoir faire, sans quoi le problème excède largement le fait d'avoir une machine compromise:

          - Accéder à la clef, au mot de passe de la clef ou au message déchiffré d'un utilisateur qui utilise GPG sur le système.

          - Idem pour les transaction SSL en cours (root ne devrait pas avoir accès à mon numéro de carte bleu lorsque je consulte le site de ma banque).

          - S'évader d'une cage chroot() dans lequel ce processus root est confiné (eg. daemon chrooté qui s'est fait pwned) ou autre protection de ce type (systrace, jail, ...).

          - Accéder au hardware, lui injecter cochonneries et le griller (ou accéder aux fonctionnalités de mise à jour du bios depuis l'OS etc).

          - Avoir la possibilité de modifier la visibilité de certains infos sur l'état de la machine (eg. cas d'une rootkit qui masque certains processus sur une machine compromise). Si on est pwned, pouvoir s'en apercevoir (ou pas), ça fait une grosse différence.

          - S'évader d'une pseudo "machine virtuelle" (penser à l'hébergement mutualisé virtuel) telle que jail sous FreeBSD ou uml sous Linux ou qemu/vmware ...

          etc.


          Étant donné la sophistication des Unix modernes, pour pouvoir s'assurer de ça, on a besoin de polices qui empêchent certaines actions (comme le chargement de modules noyau, sous linux). Donc ça rajoute une série de protections contre ce type de droits roots -eg.empêcher le chargement de modules du noyau si telle option a été passée au boot- (SELinux, securelevel, Capabilities etc.), qui elles mêmes ne doivent pas être modifiables/désactivables par root.

          • [^] # Commentaire supprimé

            Posté par  . Évalué à 1.

            Ce commentaire a été supprimé par l’équipe de modération.

            • [^] # Re: Euh ...

              Posté par  . Évalué à 4.

              En fait l'objectif des protections comme les securelevels n'est pas de déporter les droits sur un super-super utilisateur.

              L'idée est plutôt de restreindre l'éxecution de certains privilèges à chaud (au runtime, ou plus précisément, lorsque le kernel tourne en mode multiutilisateur ).
              Autrement dit, on considère qu'on a confiance dans le gars qui est derrière la console physique. Celui qui, par exemple, passe les paramètres activant les sécurisations en question au noyau lors du boot.

              Exemple concret: l'admin boote son OpenBSD en init 1 (donc non multiuser, non réseau), active le niveau fort de restrictions (en écrivant "securelevel=2" dans le fichier /etc/rc.securelevel). Il met aussi un machdep.allowaperture=0 dans /etc/sysctl.conf vu que TdR vient de le lui recommander ;). Puis il pose le flag "immutable" sur certains fichiers cruciaux (au hasard: /etc/rc.securelevel, le kernel /bsd, /sbin/init, et le firewall /etc/pf.conf et /sbin/pfctl). Ensuite il passe le système en mode multiutilisateur. Et bien dès ce moment, root ne peut plus désactiver les protections du securelevel, ni rien modifier qui permette que ça soit désactiver au prochain reboot, etc. Sauf s'il a accès physique à la console, ou si on peut bypasser le noyau comme dans le cas qui nous intéresse.

              Ce n'est donc pas une "remise en cause" de root. En une phrase: le noyau/arch idéal ne devrait pas permettre à un root "distant", lorsque le système est en mode mutlisateur/en prod, de se tirer une balle dans la tête, de griller son hardware, ou de voler des données les plus confidentielles de ses utilisateurs.

            • [^] # Re: Euh ...

              Posté par  (site web personnel) . Évalué à 2.

              C'est à voir. Il est parfois par exemple possible de régler ces paramètres à la configuration du noyau, ou bien au boot.

              Dans le deuxième cas, une fois la configuration faite, on met un flag "configuration terminée". Une fois que ce flag est mis, la configuration n'est plus modifiable avant le prochain reboot, même par root.

              Bien évidemment, tout ceci ne protège contre des attaques que d'un root distant, un utilisateur local aura toujours moyen d'overrider ce genre de protections.

          • [^] # Re: Risque réel?

            Posté par  . Évalué à 10.

            Étant donné la sophistication des Unix modernes, pour pouvoir s'assurer de ça, on a besoin de polices qui empêchent certaines actions

            J'ai dû relire la phrase plusieurs fois pour y comprendre le sens du mot « police ». Et apparemment, il s'agit d'une traduction malheureuse du mot anglais « policy », qui devrait se traduire par « politique ».

        • [^] # Admin ou pas admin...

          Posté par  (site web personnel) . Évalué à 1.

          side note: L'une des premières assomptions d'une analyse sécuritaire est que l'admin n'est PAS hostil, si c'est le cas, en général c'est inutile de chercher plus loin (mauvais admin, changer d'admin).

          Euh... On n'a pas du tout le meme point de vue sur un admin : pour moi, un admin est un login comme un autre, avec plus ou moins de droits.
          Il n'a pas, par exemple, à avoir le droit d'accéder aux fichiers d'un utilisateur.
          Donc : il faut aussi gérer, dans l'aspect sécuritaire, les non-droits de l'admin, ca fait partie de la sécurité...
          (en plus de gérer differents admin : admin de backup, admin applicatif, admin systeme...)

          • [^] # Re: Admin ou pas admin...

            Posté par  . Évalué à 6.

            Pour moi (et dans mes propos précédant) un admin est un être humain, parfois pas tout à fait comme les autres, parfois complètement pas comme les autres, mais parfois il a une vie sociale :p

            Sérieusement, je parle de la personne pas de l'utilisateur. Si cette personne est hostile et que cette personne a suffisemment de droit, elle pourra foutre la merde, il est pratiquement impossible de définir une politique de sécurité considérant des administrateurs hostiles.

            Ce que tu présentes c'est le cas d'une personne n'étant pas forcément de confiance à qui tu veux donner des droits intermédiaire entre "simple user" et "root". On est d'accord ça peut être utile (et c'est souvent possible), mais sur tous les systèmes (well presque tous), il y'a toujours au sommet qq qui a au moins la possibiltié de donner des droits à tous le monde (et donc de tous faire), que ce soit via 345 comptes différents ou via un seul.

            Perso j'ai toujours considéré qu'un root (officiel, ou via une faille, ou via social engineering, etc...) était... root, et que c'tait une illusion de croire que son pouvoir est limité... tout comme une personne ayant un accès physique à la machine peut potentiellement tout faire...

  • # Je sens que je vais m'en prendre une....

    Posté par  . Évalué à 8.

    Sauf erreur de ma part (possible, je ne maîtrise pas vraiment le sujet), seul le *serveur* X11 est concerné. Le client ne semble pas concerné.

    Or, installer le serveur X11 sur une machine en production a toujours été considéré comme une pratique douteuse (installer le client l'était tout autant avant la généralisation de ssh).

    Si on considère par ailleurs que s'il s'agit simplement d'obtenir les fonctions d'un terminal X11 (lequelles sont relativement exclusives, selon les bonnes pratiques du moins), employer des procs x86 n'est ni une voie obligée, ni la seule bonne voie imaginable, le problème n'est pas réellement gênant pour l'informatique professionnelle, la seule qui rémunère les devs d'x.org.

    Bon, évidemment, pour le poste de travail PC sous *nix, au vu des normes actuelles de vivialité, ça fait pas très sérieux : mais bon : après tout, s'il s'agit de concurrencer windows...

  • # troll

    Posté par  . Évalué à 5.

    Le titre est un peu trollesque.

    La faille est présente pour toutes les applis ayant les droits "raw i/o" et Xorg en fait partie mais est loin d'etre la seule.
    Et puis quand on a les droits "raw i/o", on peut aussi utiliser le dma du matos present dans la becanne pour ecrire en memoire et faire ce que l'on veut (modification des handlers d'exception, ...). C'est meme bien plus simple que jouer avec le smm...

    D'ailleurs quand on lit le Papier de Loïc Duflot, dans les possibles correctifs, il ne mentionne jamais de corriger le serveur X...
    Il s'interroge plutot sur l'architecture X86 ...


    PS : les problèmes engendré par le mode smm sont connus depuis longtemps dixit Theo de Raadt et d'autres developpeurs kernel.

    PS : le post sur lkml : http://marc.theaimsgroup.com/?l=linux-kernel&m=114735831(...)

    • [^] # Re: troll

      Posté par  . Évalué à 5.

      Le titre est un peu trollesque.

      Pas faux. J'aurais du dire un truc comme: « La conception de l'architecture i386 nécéssite l'ouverture de failles pour permettre le fonctionnement des serveurs x » (enfin dans le genre mais en plus court ! ;)
      Mea culpa, c'était involontaire, l'effervecence journalistique, toussa...

      La faille est présente pour toutes les applis ayant les droits "raw i/o" et Xorg en fait partie mais est loin d'etre la seule.

      Hmm, il y a bien sûr XFree86 aussi. A qui pense-tu (qui ne soit pas spécifique à Linux) ?

      D'ailleurs quand on lit le Papier de Loïc Duflot, dans les possibles correctifs, il ne mentionne jamais de corriger le serveur X.

      Enfin si un peu quand même ! :

      « The best solution by far would thus be for the operating system to prevent ring 3 code from being able to access PIO registers. This can only be done if no standard application requires such privileges. This would require the designers of the X server, for instance, to decide to move their display server to a saner security model. ».

      Mais c'est vrai qu'il pointe surtout du doigt l'archi pécé.

  • # Rectification

    Posté par  . Évalué à 3.

    On dit la DCSSI et non le DCSSI.
    DCSSI = Direction Centrale de la Sécurité des Systèmes d'Information.
    Elle dépend directement du Premier Ministre (http://www.ssi.gouv.fr/fr/dcssi/ ).

    • [^] # Re: Rectification

      Posté par  (site web personnel) . Évalué à 1.

      Pour une fois que les services de Villepin font un truc de bien...
      (bizarrement je me pose la question de pourquoi ils ont diffusé ce genre d'info au lieu de les garder pour que les services secrets puissent entrer partout...)

      • [^] # Re: Rectification

        Posté par  (site web personnel) . Évalué à 2.

        partout... sauf sur les millions de postes windows tu veux dire? Pour faire de l'espionnage de particulier, je pense qu'ils ont assez de faille sous le coude... Puis peut être que les services secret utilisent du unix et qu'ils aimeraient pas ce faire piquer les infos top secret de la mort par une autre agence?

  • # Pensez à suivre les liens avant de critiquer

    Posté par  (site web personnel) . Évalué à 5.

    J'ai lu le très bon rapport de l'équipe de recherche en sécurité. Le problème soulevé est un manque de cohérence dans la politique de sécurité.

    Le système méconnu mis en avant dans ce rapport est le mode de fonctionnement "System Managment Mode" spécifique aux processeurs (compatibles) Pentium. À ce que j'ai compris, c'est un mode 16 bits dans lequel *tout est permis* (écriture n'importe où en mémoire avec un accès directement, ie. sans MMU, communication _directe_ avec la matériel, etc.). Note : malgré le fait que le jeu d'instruction soit en 16 bits, 4 Go (pas plus) de mémoire restent accessibles.

    Ce mode est activé par un message matériel (ne pouvant, à priori, ne pas être déclanché par le logiciel) particulier. Mais en fait, le rapport prouve qu'il est possible de déclancher ce message simplement en écrivant sur un port particulier (les ports 16 bits : intructions assembleurs Intel IN/OU).

    Là où le bas blesse, c'est que Xfree/X.org a un accès direct au matériel. Je pense que c'est pour des questions de performance. Accès direct : écriture n'importe où en mémoire (en particulier, dans des projections mémoire de registre matériel) et écriture dans les ports 16 bits.

    Pour exploiter ce mode, il faut :
    - Pouvoir injecter son propre code => possible si on a un accès à toute la mémoire (ce que Xorg peut faire)
    - Entrer dans le mode "System Managment Mode" => en écrivant dans un port particulier

    Plusieurs solutions sont proposées, plus ou moins compliquées à mettre en ½uvre.

    Note : Je pense que Windows est très certainement victime de ce problème de politique de sécurité.

    Bon, je ne suis pas sûr que mes explications soient très claires, mais reportez-vous au PDF sinon :-)
    http://www.ssi.gouv.fr/fr/sciences/fichiers/lti/sstic2006-du(...)
    (version française)

    Haypo

    • [^] # Re: Pensez à suivre les liens avant de critiquer

      Posté par  (site web personnel) . Évalué à 3.

      Le SMM n'est pas méconnu des développeurs de noyau, sa dangerosité est connue depuis qu'il a été créé. Le problème est architectural : comment découper le code source de manière à ce que les parties critiques (celles qui accèdent aux ports) soient petites et bien détachées, afin de minimiser les risques et de maximiser la qualité de ce code critique.

      Pour l'instant avec X, c'est plusieurs millions de lignes de codes qui ont accès à ces ports -- ça fait peur. Il a été proposé de réorganiser X pour que le code critique soit détaché dans le noyau sous forme de (petit) pilote, et que le reste du code puisse tourner sous une identité pas privilégiée. Le conflit, c'est que X veut rester complètement indépendant de l'OS (c'est un OS dans l'OS), et qu'il n'a pas les moyens humains de se lancer dans une telle transformation.

      Il n'est pas dit que Windows souffre autant de ce problème : bien que tout le système graphique fasse partie du noyau, il est fort possible que la partie critique soit séparée dans un module à part, et particulièrement blindé. Indice : il n'existe pas à ma connaissance de malware qui attaque selon cette méthode, ce qui laisse à penser que cette partie est bien protégée, en tout cas plus que d'autres parties de Windows.

      • [^] # Re: Pensez à suivre les liens avant de critiquer

        Posté par  . Évalué à 4.

        Ou alors ptêt que vu que t'es root sous windows la plupart du temps, les créateurs de malware ne se tracasse pas plus que ça? (et qu'ils n'ont en général aucun intéret à tuer ta machine, s'ils veulent se répendre un minimum).

        (suffit de chercher "ring 0 windows" sur google, ça sert à rien mais c'est marrant).

  • # et pour le particulier ?

    Posté par  . Évalué à 2.

    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 ?

      Posté par  (site web personnel) . Évalué à 2.

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

      • [^] # Re: et pour le particulier ?

        Posté par  (site web personnel) . Évalué à 3.

        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 ?

          Posté par  . Évalué à 1.

          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 ?

            Posté par  (site web personnel) . Évalué à 1.

            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 ?

      Posté par  . Évalué à 1.

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

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.