Faille de sécurité dans le pilote propriétaire Nvidia

Posté par  (site web personnel) . Modéré par Jaimé Ragnagna.
Étiquettes :
0
17
oct.
2006
Matériel
Le 2 décembre 2004, Nate Nielsen rapporte un plantage de Xorg lorsque Firefox affiche une très longue URL dans la barre d'adresse. Quatre mois plus tard un bug similaire est détecté dans Eclipse. Le bug concerne l'affichage de très longues lignes de texte avec le pilote propriétaire Nvidia. La solution est d'utiliser le pilote libre nv qui n'a pas ce bug.

Face à l'absence de réaction de Nvidia, un exploit exploitant ce dépassement de tampon offrant un shell en root est publié sur Rapid7. Il est possible d'exploiter la faille à distance à l'aide d'un client X distant. La faille a en fait été corrigée dans la version 9625 du pilote Linux sortie le 21 septembre 2006, mais la série 9xxx des pilotes Linux est encore en phase béta.

Cette faille relance bien sûr le débat pour ou contre les pilotes propriétaires (BLOBs). Pour le cas de Nvidia, il est difficile de trancher car refuser le pilote officiel implique de se priver d'accélération matérielle. Plutôt que de brasser l'air avec un débat sans fin, il serait plus judicieux de contribuer au projet Nouveau qui vise justement à écrire un pilote libre offrant l'accélération matérielle. D'ailleurs, l'écriture d'un pilote a été entamée il y a peu mais il est encore loin d'être utilisable.

NdM : Merci également à Pascal Terjan d'avoir proposé une dépêche sur le même sujet.
Mise à jour : la version 9626 du pilote (stable) corrige la faille.

Aller plus loin

  • # Lien vers journal

    Posté par  . Évalué à 3.

    On en parlait déja la : http://linuxfr.org/~gaston/22917.html

    (Note aux modos : un petit lien à rajouter dans la dépêche, non ?)

  • # nouveau driver nouveau ?

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

    pourquoi faire un nouveau driver plutôt que d'améliorer le driver nv de xorg ? nv est trop vieux ? difficilement évolutif ?

    (je pose cette question parce que je n'y connais pas grand chose et je ne trouve pas de faq)

    • [^] # Re: nouveau driver nouveau ?

      Posté par  . Évalué à 4.

      si j'ai bien compris, ils modifient le code de "nv" mais le boulot c'est surtout d'ecrire un module drm et dri.

    • [^] # Re: nouveau driver nouveau ?

      Posté par  . Évalué à 8.

      nouveau n'est pas un nouveau driver (clair non?)

      En fait c'est une extension du driver nv (2D only) vers les fonctions 3D

    • [^] # Re: nouveau driver nouveau ?

      Posté par  . Évalué à 6.

      euh le problème c'est surtout que nv n'est pas vraiment libre non plus.
      A la base c'était la sortie d'un gcc -E... et je crois pas que ce soit la forme préferée pour faire des modifications.

      http://airlied.livejournal.com/34017.html

      • [^] # Re: nouveau driver nouveau ?

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

        A la base c'était la sortie d'un gcc -E... et je crois pas que ce soit la forme préferée pour faire des modifications.

        Attention, si on veut pinailler, la "forme préferée pour faire des modifications" n'est imposée que par la GPL, pas par la license MIT qui est justement celle qui couvre ce pilote. Et on considère pourtant en général que la license MIT est libre...

    • [^] # Re: nouveau driver nouveau ?

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

      le problème avec le pilote nv est qu'il est obscurci (obfuscate) au niveau du code source :
      http://airlied.livejournal.com/34017.html

      En plus de faire un pilote pouvant exploiter les capacités 3D, nouveau cherche aussi à faire un pilote plus facile à maintenir et gérant plus de fonction que nv (le dual screen ou exa par exemple ).

    • [^] # Re: nouveau driver nouveau ?

      Posté par  . Évalué à -1.

      c'est bien souvent une question de connaissance. En réécrivant le pilote de bas en haut, tu apprends plus que de tenter de comprendre un pilote existant et de l'améliorer, surtout s'il y a très peu de document et pas de specs. Les auteurs/mainteneurs de nv n'ont pe pas pour objectifs d'implémenter l'acceleration, c'est pkoi la réécriture me parait sencée.

    • [^] # Re: nouveau driver nouveau ?

      Posté par  . Évalué à 0.

      Ce pilote pose certains problemes, en 2D il est clairement plus lent que le driver proprio et n'aime pas un certain nombre de resolutions d'ecran (il a refusé mordicus de configrer la resolution correspondant a mon LCD 20' widescreen)

      • [^] # Résolutions originales

        Posté par  . Évalué à 1.

        Ce pilote [...] n'aime pas un certain nombre de resolutions d'ecran (il a refusé mordicus de configrer la resolution correspondant a mon LCD 20' widescreen)

        D'un autre côté, le serveur X contient un certain nombre de résolutions prédéfinies et les autres ne le sont pas.
        Donc, à moins que toi (ou l'utilitaire de configuration de X de ta distribution) ne l'aies déjà fait, il est souhaitable, sinon indispensable, de définir dans xorg.conf (Section "Monitor") un Mode correspondant à ton moniteur, idéalement en récupérant ses spécs (si c'est possible), ce qui se fait avec read-edid ( http://john.fremlin.de/programs/linux/read-edid/ ) :
        ./get-edid | ./parse-edid

        « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

        • [^] # Re: Résolutions originales

          Posté par  . Évalué à 1.

          à moins que toi (ou l'utilitaire de configuration de X de ta distribution) ne l'aies déjà fait, il est souhaitable, sinon indispensable, de définir dans xorg.conf (Section "Monitor") un Mode correspondant à ton moniteur

          Oui et non, les modeline doivent (!) disparaitre, la méthode moderne est d'utiliser dpms.
          Et oui j'avais entré la résolution à utiliser a ma mano, il s'en fichait royalement et fail-safait en 800*600 (ouch!)

          • [^] # Re: Résolutions originales

            Posté par  . Évalué à 1.

            Personnellement, une fois mon 20 pouces large acheté et installé, j'ai édité xorg.conf et à la place de 1027x768 j'ai mis 1680x1050, j'ai redémarré et cela a fonctionné sans le moindre problème ni la moindre anicroche avec le driver proprio d'Ati. Donc ça doit beaucoup dépendre des configurations, mais j'ai rien changé d'autre. De toutes façons, avec les écrans plats actuels dont la résolution est fixée dans le marbre et la fréquence de rafraichissement standardisée à 60 Hz, il n'y a plus trop besoin de jouer avec les modelines ou ces histoires là.

            • [^] # Re: Résolutions originales

              Posté par  . Évalué à 3.

              De toutes façons, avec les écrans plats actuels dont la résolution est fixée dans le marbre et la fréquence de rafraichissement standardisée à 60 Hz, il n'y a plus trop besoin de jouer avec les modelines ou ces histoires là.

              Tu diras ça à M. Acer, par exemple. J'ai vu le cas d'Acer 17'' plats premier prix qui ne fonctionnaient pas avec le mode prédéfini du serveur X (pas d'image ou parties de l'image qui "clignotent") et qui fonctionnent tout-à-fait bien avec le mode extrait par read-edid.
              Seules les durées du signal de synchro et du retour de faisceau différaient, mais ceux du mode standard ne leur plaisaient pas. Pourtant le retour de faisceau, pour un moniteur LCD, ça n'a aucun sens, mais peut-être avaient-ils un peu de mal à détecter un signal de synchro trop court...

              Évidemment, d'un autre côté, j'ai aussi vu le cas d'un écran plat branché sur un PC sortant un mode supérieur (réglé pour un moniteur cathodique) avec une fréquence élevée et qui l'a affiché sans broncher avec une interpolation aussi propre que possible.

              « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

          • [^] # Re: Résolutions originales

            Posté par  . Évalué à 1.

            Oui et non, les modeline doivent (!) disparaitre, la méthode moderne est d'utiliser dpms.

            C'est justement ce que fait read-edid... pour définir des Mode (pas "line", mais c'est juste une question de présentation).
            Je n'ai pas eu l'impression jusqu'ici (mais je n'ai pas dû utiliser les toutes dernières versions) que le serveur X soit capable d'utiliser directement et correctement le DMPS pour récupérer les modes écran.
            Et je ne parle même pas de déduire un mode 1440x1080 à une fréquence potable (pas 60 Hz, merci pour nos yeux) pour un 19'' cathodique qui ne sort qu'une définition de mode 1280x1024...

            Et oui j'avais entré la résolution à utiliser a ma mano, il s'en fichait royalement et fail-safait en 800*600 (ouch!)

            Moi j'ai plutôt vu l'inverse : des moniteurs LCD qui n'affichaient rien jusqu'à ce qu'on leur mette le Mode récupéré par read-edid.
            Ta résolution n'était probablement pas dans l'intervalle de synchronisation défini auparavant, sinon X t'aurait sorti quelque chose, quitte à ce que le moniteur ne soit pas capable de l'afficher si le mode ne lui convient pas.

            « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

      • [^] # Re: nouveau driver nouveau ?

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

        En cherchant un peu plus loin que le bout de son nez, on peut se rendre compte que nouveau utilise la nouvelle API de Xorg qui s'appelle EXA.

        Pour faire très simple, EXA déporte énormément de code qui se trouvait initialement dans les pilotes, dans Xorg. Ceci réduit considérablement la complexité des pilotes et les rend beaucoup plus rapide à écrire. Cependant, par défaut, le code de EXA n'est pas très optimisé et des options dans le fichier de xorg.conf permettent de modifier les algorithmes utilisés derrière.

        En rajoutant la ligne suivante à ton xorg.conf, dans la section Device, la 2D sera BEAUCOUP plus rapide :
        Option "MigrationHeuristic" "smart"

        cf. http://nouveau.freedesktop.org/wiki/EXA

        À bon entendeur.

    • [^] # Re: nouveau driver nouveau ?

      Posté par  . Évalué à 2.

      Honnêtement, cette histoire de pilote libre, j'ai des doutes.

      Combien de model de radeon dont nous avons finalement toutes les specs suffisantes, fonctionnent-elles au poil?
      Je parle des R200 et R250.
      Le projet DRI semble aller dans tous les sens en même temps.

      Alors partir sur du Nvidia sans infos et arriver à faire mieux - ou équivalent - que leurs ingénieurs qui, soit dit en passant, font d'excellent pilotes, me fait doucement rire ...nerveusement.
      Ne vous y trompez pas, j'envie autant que vous des pilotes de libres pour cartes graphiques*, mais bon qu'elles sont nos chances d'avoir quelque chose de fonctionnel et dans les temps?

      @+
      *J'utilise mon ATI mobility 9000 avec les DRI, la partie 2D est quasi irreprochable. Je remerci les devs de DRI au passage

      • [^] # Re: nouveau driver nouveau ?

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

        les drivers radeon libre fonctionne bien mieux que ceux d'ati. et pour cause, ati ne fournit plus de drivers pour les r2xx depuis un bon moment !

      • [^] # Mieux ?

        Posté par  . Évalué à 8.

        Alors partir sur du Nvidia sans infos et arriver à faire mieux - ou équivalent - que leurs ingénieurs qui, soit dit en passant, font d'excellent pilotes, me fait doucement rire ...nerveusement.

        "Mieux", ça dépend des critères qu'on considère en premier. Au niveau de la performance, c'est probablement très difficile, mais au niveau stabilité, par contre, il suffit de faire un code qui ne plante pas côté CPU.
        Souvenons-nous que quand Microsoft en a eu marre qu'on dise que Windows plante sans arrêt (ça devait être à l'époque de Windows 95 ou 98), ils ont contraint les fabricants de matériel à faire passer une certification à leurs pilotes, et il faut reconnaître que Windows plantait effectivement nettement moins après...
        Sous Linux, nVidia et ATI ont pu reprendre leurs "bonnes" habitudes et nous fournir des pilotes qui vont quelquefois jusqu'à geler complètement le noyau en cas de mise en veille de l'écran (vécu) ou autres joyeusetés du même acabit...
        Et je passe sur la sécurité d'avoir du code fermé qui tourne pour une partie en mode noyau et pour le reste en en super-utilisateur...

        « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

      • [^] # Re: nouveau driver nouveau ?

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

        Combien de model de radeon dont nous avons finalement toutes les specs suffisantes, fonctionnent-elles au poil?

        En fait peu de développeurs ont les specs des radeon, ce sont ceux qui ont signé un NDA il y a plusieurs années, et c'était pour R100 ou R200. Les docs R300 se limitent à des registres décrivant la 2D.

        Le projet DRI semble aller dans tous les sens en même temps.

        Tous les sens ? Par rapport au fait qu'on travaille sur ATI et Nvidia ? Ce ne sont pas les mêmes personnes, et puis je pense qu'on n'a pas d'obligation de travailler sur tel ou tel modèle de cartes, en particulier quand on fait ça dans son temps libre et bénévolement. Il faut se faire plaisir avant tout !

        Alors partir sur du Nvidia sans infos et arriver à faire mieux - ou équivalent - que leurs ingénieurs qui, soit dit en passant, font d'excellent pilotes, me fait doucement rire ...nerveusement.
        Ne vous y trompez pas, j'envie autant que vous des pilotes de libres pour cartes graphiques*, mais bon qu'elles sont nos chances d'avoir quelque chose de fonctionnel et dans les temps?

        Je t'accorde que les pilotes de nvidia sont très bons. C'est sûr que si tu vises des performances tip-top, c'est ceux-là qu'il faut utiliser. Maintenant si tu veux des pilotes libres, ou que tu as un powerpc, ou une autre machine un peu exotique, tu es content de trouver une alternative.

        Pour ce qui est d'avoir quelque chose de fonctionnel "dans les temps" je ne vois pas vraiment ce que tu veux dire. Tu as une échéance précise en tête ?

        • [^] # Re: nouveau driver nouveau ?

          Posté par  . Évalué à 3.

          Pour ce qui est d'avoir quelque chose de fonctionnel "dans les temps" je ne vois pas vraiment ce que tu veux dire. Tu as une échéance précise en tête ?


          Peut-ête veut-il dire avant que la carte ne soit plus vendue?

          • [^] # Re: nouveau driver nouveau ?

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

            Peut-ête veut-il dire avant que la carte ne soit plus vendue?

            J'espère que non :) Je pense en particulier aux possesseurs de TNT, TNT2, et Geforce 1 ou 2 qui sont obligés d'utiliser le pilote "legacy" de nvidia. Ces cartes ne sont certes plus vendues, mais pourraient très bien supporter AIGLX.

            Pour ces utilisateurs, l'arrivée d'un pilote implémentant AIGLX serait intéressante même si leurs cartes ne sont effectivement plus en vente depuis longtemps.

          • [^] # Re: nouveau driver nouveau ?

            Posté par  . Évalué à 1.

            @Stéphane: on va pas parler d'échéance quand même, disont qu'une année et quelques mois d'attentes après la sortie d'une carte par exemple, ça serait bien.

            Evidement que je fais valoir l'ouverture, la sécu et la stabilité avant les perfs, mais bon, un moment, t'aimerais bien faire pèter quelques polygones texturés aux matériaux programmables, dans un ptit FPS bourrin :)
            Non c'est, j'suis pas un joueur, mais dans le domaine infographie et j'aimerais bien, ne pas trop être handicapé, mais j'assume complètement mes choix!

            Quant à l'alternative, je l'utilise justement, j'ai un powerbook G4 nourrit au DRI, et comme je l'ai dit, la gestion 2D est presque irréprochable mais pas d'AIGLX convenable, mais ça j'admet que ça puisse venir de moi et que c'est facultatif. :)

    • [^] # Re: nouveau driver nouveau ?

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

      Hello

      La question est pertinente. Oui, nous partons du driver "nv" et nous nettoyons le code et rajoutons le support pour la 3D. Non, ce n'est pas fait dans l'arborescence officielle parce que cettte arboressence est maintenue par des developeurs travaillant pour nvidia, et que ça pourrait causer des conflits.

      • [^] # Re: nouveau driver nouveau ?

        Posté par  . Évalué à 2.

        Une question en passant, est-ce que vous vous basez aussi sur le driver Utah GLX pour Xfree 3.3 ? Ils avaient un driver fonctionnel quoique pas au niveau des perfs de celui de nvidia. Mais il permettait quand même de faire tourner Quake 3 de façon raisonnable sur une TNT2.

        • [^] # Re: nouveau driver nouveau ?

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

          Alors, il existe effectivement un driver GLX qui fonctionne avec les NV04 (TNT), NV05 (TNT2) et toutes les variantes de NV10 (geforce 1, geforce 2mx, geforce 2ti/gts, geforce 4 mx). Le problème c'est que ce driver utilise les geforces comme si c'étaient des TNT/TNT2 (ces cartes ont en effet un mode rétro-compatible avec la famille TNT).

          Si on se refère aux docs des cartes :
          http://nouveau.cvs.sourceforge.net/nouveau/renouveau/nv_obje(...)
          ça veut dire qu'au lieu d'utiliser NV10_TCL_PRIMITIVE_3D il utilise NV04_DX5_TEXTURED_TRIANGLE et donc ne tire pas partie de tout un tas de fonctionnalités, dont le TCL matériel (et bien d'autres choses, je t'invite à comparer les 2 objets en question).

          D'autre part ce driver est un driver GLX, c'est-à-dire qu'il tourne complètement en user space et donc nécessiterait une réecriture si on voulait récupérer le code.

          Donc finalement, ce driver est principalement intéressant pour comprendre le fonctionnement des TNT/TNT2, mais je ne pense pas que récupérer son code soit une bonne idée.

  • # Pour info

    Posté par  . Évalué à 3.

    Je souligne que je ne suis pas aller voir l'exploit, mais quel peut être l'intérêt de faire planter le serveur X ? En quoi cela permet-il de rentrer sur la machine distante ?

    • [^] # Re: Pour info

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

      D'apres les security advisories que j'ai lu, le crash entraine un shell root, je te laisse juge des consequences.

      Steph

    • [^] # Re: Pour info

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

      En fait, il y a deux choses:
      1/ une simple page HTML provoquant un DOS (pas vraiment d'interet sinon demontrer la presenc de la vulnerabilite)
      2/ un exploit permetant d'avoir un acces root sur la machine

      le second est plus interessant, mais aussi plus delicat a mettre en oeuvre. Ce sont juste deux facons de tirer profit de la meme faille, l'une bourine (je platre de merdier jusqu'a ce que ca plante), la seconde plus fine (je mets juste ce qu'il faut la ou il faut pour que ca execute mon code en root)

      • [^] # Re: Pour info

        Posté par  . Évalué à 0.

        ok voila, en lisant un peu vite on pourrait penser que le 1) pouvait provoquer le 2) ..
        merci

    • [^] # Re: Pour info

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

      une grande partie du code X tourne avec des droits augmentés. Le faire crasher permet de récupérer le fil d'exécution de ce programme par un autre programme. On peut donc lui faire crasher sur un exec("sh"); ce qui confère au nouveau shell les privilèges de X, donc du root.

      • [^] # Re: Pour info

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

        Question : le bug est-il exploitable par un attaquant distant ? Le profane que je suis n'a pas vraiment pu éclaircir le sujet avec les explications lues dans la dépêche ou ses commentaires.

        Ce n'est pas anodin, la portée d'une faille n'est pas la même selon la réponse à cette question. Une faille ne pouvant être exploitée qu'en local ou requérant un compte utilisateur sur la machine n'aura qu'une portée très limitée, alors qu'une faille exploitable par n'importe quel lambda qui "attaquerait" la machine est très dangereuse, surtout pour une machine qui tourne 24/24 (serveur web et ssh).

        • [^] # Re: Pour info

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

          L'advisory répond pleinement à ta question.

          [...]The NVIDIA Binary Graphics Driver for Linux is vulnerable to a
          buffer overflow that allows an attacker to run arbitrary code as
          root. This bug can be exploited both locally or remotely (via
          a remote X client or an X client which visits a malicious web page).[...]


          http://download2.rapid7.com/r7-0025/

          • [^] # Re: Pour info

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

            Je suis peu etre a cote de la plaque, mais j'ai l'impression que cet advisory utilise "remote" et "local" dans des sens quelques peu different de ce que veut l'usage...

            D'habitude, on comprend par local une vulnerabilite exploitable par un attaquant qui a un compte sur la machine (il peut exploiter la faille si il est a l'autre bout de la Terre, pour peu qu'il ai un access SSH, telnet, rsh, etc... D'habitude, on comprend par remote une vulnerabilite exploitable par quelqu'un qui un acces reseau non privilegie a la machine (pas de compte sur la machine).

            Or, de ce que j'ai compris de la vulnerabilite du driver nVIDIA, il faut tout de meme que le serveur X soit bien gentil avec l'attaquant pour pouvoir etre attaque: il faut que celui-ci ai le droit de se connecter au serveur X afin de le forcer a executer l'operation fatidique. Ca implique que la machine attaquante doit etre en "xhost +", ou qu'il ait mi la mains sur un Xauthority, ou autre... Bref, d'apres ma comprehension toujours, il n'est pas suffisant d'avoir un X11 expose a un attaquant anonyme pour etre exploitable (cela dit, ca a toujours ete considere comme suicidaire que d'exposer son X11 a n'importe qui...)

            Bref, je trouve la formule "can be exploited [...] remotly" quelque peu abusive...

            • [^] # Re: Pour info

              Posté par  . Évalué à 4.

              or an X client which visits a malicious web page

              Et si tu fous un shell code dans une page web malicieuse qui phone home chez toi et t'offres un shell distant (en utilisant pas exemple des ressources locales comme netcat ou telnet ou autre), tu acceptes la dénomination de "can be exploited [...] remotly" ?

        • [^] # Re: Pour info

          Posté par  . Évalué à 4.

          Depuis quand on installe X sur un serveur web ? Qui plus est, avec les drivers nvidia....

          • [^] # Re: Pour info

            Posté par  . Évalué à 2.

            Depuis quand un serveur web se limite à un serveur web ?

            Bon, la forme de ma reponse est un chouilla provoc, je le concede.

            Cependant, cette idée comme quoi un serveur web c'est un truc qui ne fait que sa, qu'il ne devrait pas y avoir ni d'ecran clavier souris etc. m'etonne toujours au plus haut point.

            Dernierement, j'ai installé un serveur web pour une association locale. Comme le pc est loin d'etre une bete de course (200Mhz 128Mo) j'ai effectivement juste installé le serveur web, ssh, bientot il fera routeur et on recupere son clavier ecran souris pour un autre pc, sa fait des economie. Mais ils auraient eu un pc plus consequent, j'aurai installé un poste de travail par dessus le serveuravec les drivers nvidia et quelques jeux et je veux bien qu'on m'explique pourquoi il ne faut surtout pas faire sa.

            • [^] # Re: Pour info

              Posté par  . Évalué à 4.

              Peut etre parce que c'est pas super niveau disponibilité si la machine plante pendant que des gens consultent le site ?

            • [^] # Re: Pour info

              Posté par  . Évalué à 4.

              Mais ils auraient eu un pc plus consequent, j'aurai installé un poste de travail par dessus le serveuravec les drivers nvidia et quelques jeux et je veux bien qu'on m'explique pourquoi il ne faut surtout pas faire sa.

              Parce que tu n'es pas sous Windows? (et que, même si tu l'étais, ça ne serait pas une chouette idée pour autant)
              Parce qu'on ne mélange pas les torchons et les serviettes, et que ce qui est tout à fait acceptable pour un serveur ne l'est pas pour un client, et réciproquement. Et qu'à vouloir cumuler les deux profils sur une même machine, tu t'interdis du même coup l'acceptable de l'un ET l'acceptable de l'autre.

              Au final, un ordonnanceur de tâche aura des consignes très différentes entre les deux types de machines : sur un serveur, tu préfères qu'il change moins souvent de tâche, de manière à dépoter un maximum (les changements sont coûteux). Sur une station, tu préfères généralement un système réactif, quitte à ce qu'il perde en efficacité "brute" (le throughput d'outre-flotte) à force de passer régulièrement du gestionnaire de fenêtres à l'application (et plus si affinités).

              Après, on fait les économies qu'on peut. :)

              • [^] # Re: Pour info

                Posté par  . Évalué à 0.

                mouais, enfin faut voir la gueule du site aussi, hein...

                Si c'est un site "statique" avec 50 visites par jour (toutes reparties entre 19 et 21h00 evidemment), je vois pas trop ou se situe le probleme et je pense pas que le throughput soit reellement primordiale...

                c'est quoi la prochaine etape? Load balancing et redondance en cas de panne pour une machine qui va servir 1000 pages/jour?

                • [^] # Re: Pour info

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

                  Le vrai probleme, il est justement demontre par cette news: c'est la securite.
                  Un serveur web expose en public sur internet est une machine particulierement sensible aux attaques, moins il y aura de choses installe dessus, mieux ca vaudra.

                  Si vraiment ton asso a besoin d'un petit serveur web pour 50hits/jours, recupere un vieux PII 400Mhz avec 64Mo de ram (ca se donne de nos jours), il fera tres bien l'affaire avec une installation minimal de ton OS prefere. Mais bien sur sans X11, sans Gnome ni KDE, sans driver nVIDIA crippled...

                  Ceci dit, je crois que le parent du parent du parent a mal lu: la faille ici n'est pas d'avoir un serveur web en meme temps que le driver vulnerable, mais bien un client web, qui irrait consulter un serveur web malvaillant... Et je pense que 99.9% des gens qui utilisent les drivers proprio nVIDIA ont egalement un client web (voir meme, ils l'utilisent...)

                  • [^] # Re: Pour info

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

                    > Ceci dit, je crois que le parent du parent du parent a mal lu: la faille ici n'est pas d'avoir un serveur web en meme temps que le driver vulnerable, mais bien un client web, qui irrait consulter un serveur web malvaillant... Et je pense que 99.9% des gens qui utilisent les drivers proprio nVIDIA ont egalement un client web (voir meme, ils l'utilisent...)

                    Ce que je voulais dire par "exploiter a distance", c'est qu'un attaquant puisse compromettre la machine sans qu'un utiliseur qui a un compte sur la machine ait fait quoi que ce soit, en gros, pour comparer, comme les failles Blaster et Sasser de XP qui étaient virtuellement exploitables en étant simplement connecté au net (sans pare-feu).

                    Si vous me dites qu'il faut "visiter une page malicieuse" pour qu'on puisse exploiter la faille, j'appelle pas ça de l'exploitable à distance : il faut une intervention d'un utilisateur (qui surfe) pour que la machine puisse être compromise. Peu importe qu'il fasse ça devant l'écran ou en export display, du moment qu'il faut un utilisateur, la nature du risque n'est plus la même.

                    J'en déduis qu'à la question "Si je laisse mon serveur web connecté en 24/24 est-ce qu'il y a risque d'attaque via cette faille", il me semble bien que non.

                    A la question "Puis-je me faire infecter par une action à risque de ma propre personne", la réponse est oui, mais ça, c'est un peu plus facile à gérer.

    • [^] # Re: Pour info

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

      Le bug, ici, est un "buffer Overflow".
      C'est à dire que des données vont être écrite en mémoire, en dehors de l'espace qui leur est alloué.
      En tant "normal", lorsque ce bug se produit, on se retrouve généralement avec des données aléatoires écrites on ne sait où, ce qui provoque le plantage du serveur.
      L'interêt de cet exploit est d'utiliser ce bug pour savoir qu'elles données on écrit où.
      Typiquement, on se débrouille pour faire pointer le registre d'exécution vers un shellcode, ce qui permet donc d'exécuter du code connu en tant que root. C'est autrement plus interessant qu'un simple plantage de X.

      Si j'ai dit des bêtises, je laisse les spécialistes me corriger...

  • # Précision

    Posté par  . Évalué à 10.

    Une précision, Chad Loder (« Manager of Engineering » de Rapid7 ) est un développeur OpenBSD, d'où la formulation très militante de cet advisory.

    OpenBSD fait justement parti de ceux qui réclament les specs de tout matériel, sans NDA, depuis longtemps. J'espère que les devs Debian pas contents (de la dépêche d'à coté) saisiront l'occasion pour leur filer un coup de main.

    • [^] # Re: Précision

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

      Ah, j'ignorais cette precision. En tout cas, merci a OpenBSD et ses contributeurs très carrés qui font bouger les choses concernant les specs de beaucoup de pilotes.

  • # Faux

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

    Contrairement à ce qui est dit dans la nouvelle, la version 9626 n'est pas du tout une version stable mais une nouvelle béta apportant le support d'une carte en plus.

  • # PcInpact dit n'importe quoi, enfin pour changer

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


    Les chercheurs de Rapid7 ont publié un bulletin de sécurité concernant cette faille hier tout juste, une faille qui ne concerne que les pilotes propriétaires (sources fermées) de NVIDIA. Les pilotes Linux open source de la marque (inclus par défaut dans X Window) ne sont en revanche pas sujets à cette faille de sécurité. Car ces derniers n'offrent pas l'accélération matérielle que permet les pilotes propriétaires.


    Voila grace à PCInpact on sait que les trous de sécurité proviennent de l'accélération matérielle et non du developpement de cette couche ;)



    Source :
    http://www.pcinpact.com/actu/news/32112-faille-NVIDIA-Linux.(...)

  • # Carte graphique NVIDIA GeForce 7600 GS et effet 3D

    Posté par  . Évalué à -3.

    Bonjour,
    Je viens de changer de carte graphique (pour une GeForce 7600 GS) et je suis confronté à un problème, je n'ai plus accès aux effets 3D (XGL). Je précise que je viens d'installer la dernière mouture de Mandrake (une petite infidélité à Ubuntu le temps de l'essayer ;)).
    Quel driver dois je installer pour obtenir les effets 3D, ceux de NVidia (Pilote d’affichage Linux - AMD64) ?
    Merci d'avance.

  • # Corrigée également dans la branche 87xx

    Posté par  . Évalué à 2.

    La version 1.0-8776 sortie le 19/10 corrige également cette faille.

Suivre le flux des commentaires

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