Déni de service dans x-window

Posté par  . Modéré par Benoît Sibaud.
Étiquettes :
0
13
juin
2002
Serveurs d’affichage
Lors d'utilisation de fontes anormalement grandes, il est possible de geler un PC utilisant X-window...

L'expérience peut etre tentée avec Gimp, mais le plus dangereux reste encore le deni de service à distance grace à Mozilla, lorsque les fontes se voient assignées une valeur trop grande dans les CSS (Cascading Style Sheets).

Le travail est en cours pour résoudre le problème mais il n'y a pas encore de solution pour éviter le bogue...

Aller plus loin

  • # Et ça ça marche?

    Posté par  . Évalué à 10.

    Sous Netscape 7 y a une petite case avec marqué: Autoriser les documents à utiliser d'autres polices. Si on demande à Mozilla de ne pas utiliser la taille des fontes que fournit la page mais une taille prédéfinie par l'utilisateur, ça doit pouvoir marcher quand même???
    Certes, on aura la même taille et la même police partout mais bon.
    • [^] # Re: Et ça ça marche?

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

      cf lien "Description du problème" : Ca marche pas

      L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

    • [^] # Re: Et ça ça marche?

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

      Sauf que le problème vient de X et pas de Mozilla.

      Il vaudrait donc mieux corriger le problème à la source, parce que sinon, cela signifie ajouter une verrue (une « feature ») sur tous les programmes au dessus de X succesptibles d'être touché par le bug !

      Ceci-dit, c'est quand même un bug bien étrange.
    • [^] # Re: Et ça ça marche?

      Posté par  . Évalué à 10.

      Je viens de tester à l'instant... Non, ça ne fonctionne pas. Apparemment, cette option empêche les applications de changer la famille de la police, mais pas la taille; j'arrive quand même à obtenir de très grosses fontes en désactivant "autoriser les documents à utiliser d'autres polices"
  • # Issu d'un post de BugTraq

    Posté par  . Évalué à 10.

    Il semblerait que le problème provienne, non du serveur X ou de xfs, mais de libXfont. Elle détecte bel et bien qu'on lui demande de rendre quelque chose d'anormalement grand, et fait tout simplement un... abort. Ce qui est une assez mauvaise idée, dans une librairie

     struct segment *
    StepBezier(struct region *R, /* Region under construction or NULL */
    [...]
    if ( TOOBIG(xB) || TOOBIG(yB) || TOOBIG(xC) || TOOBIG(yC)
    || TOOBIG(xD) || TOOBIG(yD) )
    abort("Beziers this big not yet supported");


    Enfin, dans tous les cas, XFS/X devra aussi être patché, pour refuser directement toute police trop grand, sans attendre que libXfont râle à cause des courbes de Bezier

    J'ai entendu dire que certains avaient déjà des liens vers des librairies patchées, ou des patchs fonctionnels... plus d'infos?

    (Au passage, chez moi --- sans xfs --- ca s'est contenté de manger de la mémoire, puis de tuer mozilla et de rendre le système dans un état utilisable, une fois qu'il n'y avait plus de mémoire)
    • [^] # Re: Issu d'un post de BugTraq

      Posté par  . Évalué à 4.

      tout les X meme sur bsd ?
      • [^] # Re: Issu d'un post de BugTraq

        Posté par  . Évalué à 10.

        Le problème affecte Xfree86 (utilisé par Linux et tous les *BSD que je connais). Pour ce qui est des autres serveurs X, le document 2 (description du problème) prétend que oui:

        When loading pages with a specially prepared (or erroneous) stylesheet,
        mozilla and X windows (not restricted to XFree) exhibit any of two
        undesireable behaviours.


        Il faudra que je teste, sur ma Sun (qui n'utilise pas Xfree, mais le serveur X de Sun), histoire de voir si ça la crashe.
    • [^] # Re: Issu d'un post de BugTraq

      Posté par  . Évalué à 10.

      j'ai le meme simptome que toi sans Xfs.

      sinon de toute facons Xfree 4.3 devrait pointer le bout de son nez d'ici un mois ou deux, donc ca devrait corriger le probleme.

      par contre la question c'est que virtuelement d'autres applis peuvent etre victimes de ce bug non?
      • [^] # Re: Issu d'un post de BugTraq

        Posté par  . Évalué à 10.

        Dans le lien sur LinuxSecurity, ils expliquent que ce problème se retrouve sur plusieurs versions de X et pas simplement XFree.

        Si aucune implémentation de X n'effectue de vérification sur la taille de police, c'est peut-être qu'il n'y a pas de solution vraiment propre (dans le protocle X) pour signaler le dépassement de taille maximale au client...
        • [^] # Re: Issu d'un post de BugTraq

          Posté par  . Évalué à 10.

          Sans doute

          Mais quelque part... on s'en fiche du client; s'il est assez stupide pour demander une police de 15000 pixels de haut, c'est qu'il a un problème/bug quelque part. A mon humble avis, la solution la plus propre est de dire "oui, ok, voici la police", mais de retourner une police de taille égale au max autorisé, 512, 1024 pixels, un truc du genre.

          Mais bon, ça soulève un autre problème: certains logiciels peuvent réellement avoir besoin de polices énormes. Sous GIMP, je peux bel et bien vouloir travailler sur un dessin de 5000x7000 pixels, et vouloir rendre une lettre qui fait toute la hauteur. Et il me semble (mais je fais peut-être erreur) que GIMP utilise X pour effectuer le rendu des polices qu'il inclut dans ses images. La solution? Heu, une gestion directe des polices par ce genre d'applications via les libs idoines, et restreindre l'utilisation de X pour le rendu des polices à afficher directement à l'écran?

          Disclaimer: n'étant pas un spécialiste de GIMP, je me gourre peut-être complètement
          • [^] # Re: Issu d'un post de BugTraq

            Posté par  . Évalué à 10.

            > mais de retourner une police de taille égale
            > au max autorisé
            Entièrement d'accord. D'ailleurs, en règle general, quand on ne sait pas traiter correctement une erreur, mieux vaut un contournement approximatif _documenté _ qu'un plantage définitif (avec perte de données et tout le toutim).

            >La solution? Heu, une gestion directe des
            >polices par ce genre d'applications via les libs
            >idoines.

            Non. Les librairies de base doivent bien faire leur travail. Il ne doit pas être nécessaire de réinventer la roue pour chaque nouveau soft qui fait appel à ces fonctionnalités.
            • [^] # Re: Issu d'un post de BugTraq

              Posté par  . Évalué à 10.

              Il n'est là pas forcément question d'utiliser des librairies de base différentes, mais plutôt de ne pas utiliser un protocole pour ce pour quoi il n'est pas prévu à la base.

              La gestion des polices sous X est destinée à rendre directement ces polices à l'écran, et pas forcément à les rendre dans un tampon mémoire destiné à être édité ensuite (cas des applications de dessin bitmap, comme GIMP, qui rend la police dans un tampon mémoire, puis dimensionne ce tampon en fonction de coefficient de zoom spécifié, ou de la définition de l'écran/de l'image).

              Ce que je veux dire, c'est que si rendre des polices de taille énorme n'est pas justifié sous X, le serveur X peut très bien décider d'interdire la tentative d'affichage de telles polices. Mais par contre, vu que, pour des raisons qui lui sont propres, GIMP peut avoir besoin de rendre des polices extrêmement grandes, pourquoi ne pourrait-il pas directement, sans passer par le protocole X, mais en utilisant les mêmes librairies (freetype, etc), effectuer lui-même le rendu des polices dont il a besoin?

              Et au passage, si j'utilise GIMP à travers le réseau, et que j'ai tout un ensemble de polices (kitsch) qui ne sont destinées qu'à décorer les images réalisées sous GIMP: pourquoi devrais-je les installer (directement ou à travers xfs) sur tous les serveurs X des postes qui doivent accéder à GIMP? Les polices ne font-elles pas partie de l'application? Les polices se trouvent sur le serveur X, et non dans les applications clientes, essentiellement pour des raisons d'économie de ressources, mais dans le cas présenté, on n'économise pas de ressources, voire on en perd encore plus si on décide de centraliser la gestion des polices avec un XFS.

              En résumé, la gestion des polices d'une application de dessin bitmap (entre autres, ce n'est qu'un exemple) n'est pas directement liée à l'usage prévu initialement par X (affichage direct de textes à l'écran). Pourquoi devrait-elle être soumise aux limitations (logiques) issues de cet usage?

              En pour rajouter une dose de trollage à une contribution qui est certainement largement sujette à juste controverse:

              La gestion des polices sous X, elle suxe grave.
      • [^] # Re: Issu d'un post de BugTraq

        Posté par  . Évalué à 10.

        <troll>
        ... sinon de toute facons Xfree 4.3 devrait pointer le bout de son nez d'ici un mois ou deux, donc ca devrait corriger le probleme.

        Finalement c'est bien que Branden Robinson n'ait pas encore packagé Xfree4.2, comme ça on passera directement de xfree4.1 --> 4.3 l'année prochaine ... après la sortie officielle de la woody <optimiste> cet hiver </optimiste>
        </troll>
  • # Commentaire supprimé

    Posté par  . Évalué à 10.

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

    • [^] # Re: Hop, le corrigé dans cvs !

      Posté par  . Évalué à 10.

      Petite précision: le bug n'est pas corrigé par Mozilla, il est juste contourné. J'ai aussi testé avec Opera 6.01 et ça ne plante pas.
      • [^] # Commentaire supprimé

        Posté par  . Évalué à 5.

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

        • [^] # Re: Hop, le corrigé dans cvs !

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

          Evidement, puisque c'est n'est pas un bug de Mozilla.

          mais est-ce un bug de XFree ? Je n'ai pas de probléme avec Konqueror 2.1.1 chez moi (XFree 4.2 , pas d'antialiasing)
          • [^] # Re: Hop, le corrigé dans cvs !

            Posté par  . Évalué à 3.

            En fait, ce n'est pas un bug

            Mozilla demande à X une fonte de telle taille, X veut lui donner la fonte en question ... Maintenant, si la fonte est immense, X va commencer à bouffer tout ton CPU, toute ta RAM, et là, l'OOM killer réagira quand il n'y aura plus aucune place en mémoire.

            Tout ce fonctionnement est logique.

            Mon avis serait plutôt de limiter la taille des polices possibles avec Mozilla; il faut que, quand on veut, on puisse utiliser des polices de la taille qu'on veut .
            Konqueror, apparement, refuse de demander à X des fontes qu'il estime trop grandes. C'est le comportement que Mozilla devrait, AMHA, adopter, de même que tous les clients (et pas seulement clients web) pouvant être atteints par le même problème
            • [^] # Commentaire supprimé

              Posté par  . Évalué à 2.

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

            • [^] # Re: Hop, le corrigé dans cvs !

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

              Konqueror, apparement, refuse de demander à X des fontes qu'il estime trop grandes.

              je ne crois pas, konqueror affiche un résultat avec des fontes de taille énorme ( trop grandes pour être entiérement visibles sur un écran 17 '' en 1024*768)
              • [^] # Re: Hop, le corrigé dans cvs !

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

                une taille en 16000 pixels ne doit pas tenir sur beaucoup d'écrans actuels...

                et c'est avec ça que l'on test !

                donc son affirmation est tout a fait possible (je me demande si mozilla 1.0 ne fait pas pareil car j'ai pas réussi à planter ma machine avec)
            • [^] # Re: Hop, le corrigé dans cvs !

              Posté par  . Évalué à 10.

              Non, ce n'est pas logique. Dans un système multi-utilisateur, jamais, au grand jamais, une application ne devrait être capable de rendre le système inutilisable pour les autres applications, de faire planter celui-ci, ou de faire planter d'autres applications. Le bug est en fait double, comme ils le précisent:

              1) Un auteur de page web n'a aucune raison d'avoir le droit de faire des polices excessivement grandes sur son site, c'est un bug de mozilla que de les accepter.

              2) X n'a aucune raison de planter, ni a fortiori de faire planter le système, juste parce que une application a fourni un paramètre abusif. De plus, le fait qu'une application puisse, en plantant X, faire planter toutes les autres apps qui utilisent X, n'est pas acceptable.
          • [^] # Commentaire supprimé

            Posté par  . Évalué à 2.

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

  • # c'est ce qu'on a vu hier ds la tribune?

    Posté par  . Évalué à 6.

    cf. daique.dyndns.org/bug.html

    enfin, il me semble que c'est cette adresse...
  • # Testez votre serveur X!

    Posté par  . Évalué à 2.

    ici: http://jseven.free.fr/bug.html(...)

    try it for free! just one click to know!
    • [^] # Re: Testez votre serveur X!

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

      Snif, je voulais voir ma linux box planter, mais ça marche pas !!!! ;-(


      Ma config : XFree86 4.2.0 (mdk 8.2) et mozilla 1.0 (tarball officiel)... (et xfs)

      J'ai essayé aussi sur un serveur sun (solaris 2.8 + xfs), et rien non plus à part freezer le mozilla (nightly 2002052022).

      Il faut faire quelque chose en plus pour que ça plante tout ???
      • [^] # Re: Testez votre serveur X!

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

        je viens de trouver...

        Bon, avec mon mozilla, pas moyen...

        mais avec The Gimp et une police en 14000, ça fait mal...

        en fait, comme xfs plante, il n'y a plus grand chose d'autre que l'on peut lancer... (j'ai pu lancer un xterm mais j'ai pas réussi à redémarrer xfs..., reboot obligé).
        • [^] # Re: hum

          Posté par  . Évalué à 2.

          j'ai pu lancer un xterm mais j'ai pas réussi à redémarrer xfs..., reboot obligé

          euh... c'est moi qui délire
          ou est-ce que certains n'ont jamais vu les consoles
          qui se cachent toujours derrière un serveur X ?
          • [^] # Re: hum

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

            Je te rassure, je connais le CTRL+ALT+FX...

            Mais /etc/rc.d/init.d/xfs stop (ou restart) n'a pas fonctionné... et je voulais essayer de planter complètement ma machine, donc j'ai essayé de lancer quelques applis... et la seul qui passait était le xterm...

            ça te rassure ? ;-)
            • [^] # Re: init

              Posté par  . Évalué à 3.

              ça te rassure

              ma fois un peu, mais à ta place j'aurais quand
              même essayé l' "init 1" plutôt qu'un reboot...

              ps: on va quand même pas se mettre à tout rebooter
              sous pretexte que X a dégagé...
              où irions nous (tm) ?!
              • [^] # Re: init

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

                c'est vrai, mais là, c'est des trucs que je fait un peu moins souvent...

                faut dire aussi qu'à la suite de mon test de redémarrage de xfs, j'ai voulu voir ce que ça faisait de quitter le serveur X et de retourner sur kdm...
                mais le serveur X n'a jamais voulu redémarrer... (normal avec un xfs en carafe) et la police blanche du mode console est bizarement devenue verte...
                comme j'étais sur mon portable, j'ai pas voulu jouer plus et j'ai rebooté (j'ai pas envi d'endommager l'écran, qui ne craignait peut-etre rien ici, mais bon, j'aime pas joué avec le feu dans ces cas là).
            • [^] # Re: hum

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

              Mouais ca ca marche jamais chez moi, mais normalement ca devrait:

              tu lance X avec xfs, tu crashe xfs,

              un petit /etc/init.d/xfs restart

              et sous X un xset fp- unix/:7100
              puis xset fp rehash
              puis xset fp+ unix/:7100
              puis xset fp rehash

              doit normalement permettre un retour a la normale (si pas de xterm .. bein console+DISPLAY
              mais ca ne marchait avec moi que sur des NCD (Terminaux X) (heureusement parce que a rebooter c merdes la ...)
    • [^] # Re: Testez votre serveur X!

      Posté par  . Évalué à 5.

      je ne plante pas : Mozilla 1.0, XFree86-4.0.3-7mdk, XFree86-xfs-4.0.3-7mdk.

      je vois pas tres bien pq. Je ne suis pas allé sur le site lire l'ensemble des explications, mais j'ai rien configuré et ca freeze pas.
      • [^] # Re: Testez votre serveur X!

        Posté par  . Évalué à 6.

        j'ai vu que cela concernait les polices au format vectoriel, donc si j'utilise des polices dans un format bitmap, le bug ne peut pas intervenir, puis qu'il est dans l'algo concernant le rendu des courbes de bezier.
      • [^] # Re: Testez votre serveur X!

        Posté par  . Évalué à 2.

        finalement, j'ai fini par planter.

        en fait j'avais planté mon serveur de fontes. N'ayant plus de serveur de fontes, le serveur X a fini par me lacher, et n'ayant pas les droits sur la machine -> reboot.

        attention, meme si vous lancez un second display (X :2), vous allez planter votre serveur xfs, et donc finir par planter votre session X (la vrai aussi).
    • [^] # Re: Testez votre serveur X!

      Posté par  . Évalué à 3.

      Avec XFree 4.2.0 (LFS) et Mozilla 1.0 j'obtiens une grande page blanche, mais absolument pas de plantage.
      Serait-ce valable uniquement sur des versions plus anciennes de X ?
    • [^] # Re: Testez votre serveur X!

      Posté par  . Évalué à 0.

      Avec Konqueror 3.0 / XFree 4.2.0, c'est konqueror qui a planté...
    • [^] # Re: Testez votre serveur X!

      Posté par  . Évalué à -2.

      avec Xfree 4.1 et mozilla 0.9.9 (woody), ça se contente de fermer l'onglet de la page (faut dire que je n'utilise pas xfs).
  • # Pinaillage

    Posté par  . Évalué à 4.

    Issu de la page de man de X

    The X Consortium requests that the following names be used when referring
    to this software:

    X
    X Window System
    X Version 11
    X Window System, Version 11
    X11


    Le titre de la news n'est donc pas correct, "x-window" n'est pas une appellation acceptée par le X consortium.

    Bon, -1 parce que c'est du pinaillage
    • [^] # Re: Pinaillage

      Posté par  . Évalué à 2.

      t'as raison mais tout le monde, enfin en france, parle de X Window eventuellement tres rarement de X11, ou X. Et ceux qui ajoutent un 's' a la fin se font tapper sur les doigts, plus ou moins a juste titre.
      • [^] # Re: Pinaillage

        Posté par  . Évalué à -2.

        bah, pourquoi, le S c'est pour abréger X Window -S-ystem non ?
      • [^] # Re: Pinaillage

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

        t'as raison mais tout le monde, enfin en france, parle de X Window eventuellement tres rarement de X11, ou X.

        Tout le monde, enfin en France, utilise MS-Windows. éventuellement, mais très rarement, Gnu/Linux ou OpenBSD.

        Ont-ils forcément raison ?
      • [^] # Re: Pinaillage

        Posté par  . Évalué à 1.

        Dans OpenOffice, y'a "look&feel: XWindows", c'est surement un concurrent de window-manager

        -> -1
  • # Deni de service ?

    Posté par  . Évalué à 3.

    Je ne suis pas un expert en sécurité, mais ce truc ne me semble pas avoir grand chose à voir avec un deni de service. C'est un bug qui fait planter l'os, c'est tout.
    • [^] # Deni de service !

      Posté par  . Évalué à 7.

      Eh bien si justement, c'est un DoS.

      L'OS ne plante pas à proprement parler (quoique je n'ai pas testé sur beaucoup de machines), c'est l'OOM killer qui tue X quand c'est nécessaire (voir mon post un peu plus haut).
      • [^] # Re: Deni de service !

        Posté par  . Évalué à 6.

        Il me semblait qu'un dos, ça consistait à mattraquer un serveur jusqu'à ce qu'il ne puisse plus répondre à la demande et parte en quenouille.
        Or ici le client doit aller chercher une page qui fait planter son serveur x, je ne vois pas trop le rapport.
        C'est quoi un OOM killer ?
        Explications siouplait.
        • [^] # Re: Deni de service !

          Posté par  . Évalué à -4.

          Ok, je n'ai rien dit, j'ai compris.
        • [^] # Re: Deni de service !

          Posté par  . Évalué à 10.

          Matraquer un serveur jusquà ce qu'il tombe par terre en se tordant de douleur, c'est un exemple de DoS. Il en existe tant d'autres.

          En fait, Denial of Service, c'est le fait, pour une personne non-autorisée, de parvenir à empêcher, momentanément ou définitivement, un logiciel ou un équipement de rendre un des services pour lesquels il est conçu. (définition made in moi-même, à l'instant). Donc, le fait de bombarder un serveur, l'empêchant de fonctionner, tout comme le winnuke, ou l'exploitation de ce bug de X, sont bel et bien des denials of service.
        • [^] # Re: Deni de service !

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

          Le OOM killer est une fonction du noyau qui permet de tuer un processus si celui ci prend trop de mémoire (trop = toute la mémoire de la machine ou suivant les règles définit par l'admin) et empeche ainsi le bon déroulement des fonctions vitales du noyau...

          OOM killer = out of memory killer
        • [^] # Re: Deni de service !

          Posté par  . Évalué à 6.

          OOM killer == Out Of Memory killer : http://linux-mm.org/docs/oom-killer.shtml(...) , permet de libérer de la mémoire lorsqu'il n'y en a plus en killant le process le plus gourmand (voir lien pour plus de détails).
      • [^] # Re: Deni de service !

        Posté par  . Évalué à 1.

        C'est bien l'OOM killer qui termine X.
        Par contre, le fait que ta machine plante ou pas dépend des ressources que X avait (il controle le hardware) et qu'il n'a pas pu libérer a cause du kill. (D'ou des retours d'expériece divers ...)
  • # cette dépêche, c'est du vent

    Posté par  . Évalué à 3.

    1) le problème est règlé avec les Xfree et xfs récent : il abandonne le chargement (4.2.0)

    2) lorsqu'on a pas xfs, on a quand même xfs.. le fait d'avoir xfs est le fait d'avoir un module à part pour gérer les polices. Si on a pas xfs, c'est x qui prend, c'est simple.
    • [^] # Re: cette dépêche, c'est du vent

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

      heu, t'es sur que le problème est règlé avec le 4.2.0...

      car sur ma mdk (8.2, XFree86-4.2.0-10mdk), The Gimp a planté xfs en faisant afficher une police de 14000 points...

      par contre, avec mozilla, ça n'a rien fait... c'est peut-etre que c'est pas corrigé complètement !?
  • # par contre sous IE...

    Posté par  . Évalué à -7.

    je viens de tester ça plante pas et c'est même assez joli... pourquoi on peut pas faire le même ? :'(

    -10 ok

Suivre le flux des commentaires

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