• # Mettre à jour...

    Posté par  . Évalué à 10.

    Pour l'instant on ne peut pas trop mettre à jour... la série 2.2 va jusqu'au 2.2.20, et la 2.4 jusqu'au 2.4.18 !

    Il n'y a rien à faire sinon attendre le prochain noyau, en se disant que cette fois-ci on a une bonne raison pour migrer.

    exemple de chose réalisable avec cette faille : lister le contenu d'un répertoire auquel on n'a pas accès normalement. En théorie, on devrait aussi pouvoir le faire via des démons, par exemple avec un serveur web filtrant mal les arguments en faisant un GET /argument qui sera passé à d_path().

    Donc ceux qui réagissent en disant "ce n'est qu'une faille locale, j'ai que moi comme utilisateur donc je m'en fous" (si si, il y en a ;) se trompent.
    • [^] # Re: Mettre à jour...

      Posté par  . Évalué à 10.

      meme si la serie 2.2 va jusqu'a 20 et la 2.4 jusqu'a 18, un patch va sortir d'ici peu; donc mettre a jour ne veut pas forcement dire "attendre le 2.4.19".
    • [^] # Re: Mettre à jour...

      Posté par  . Évalué à -2.

      Pour l'instant on ne peut pas trop mettre à jour... la série 2.2 va jusqu'au 2.2.20, et la 2.4 jusqu'au 2.4.18 !

      Et la commande patch ça sert à quoi ? T'es pas obligé d'attendre qu'une nouvelle release officielle du noyau sorte pour appliquer un patch... tu prends tes petites mains, tu appliques un patch (ou en code un s'il n'y en a pas), et tu recompiles... c'est aussi ça le boulot d'un admin, pas rester les bras croisés en attendant qu'une solution tout prète se présente. On est pas chez MS, pieds et poings liés à devoir attendre le patch officiel, on est dans le logiciel libre ici, on a accès au code source.
      • [^] # Re: Mettre à jour...

        Posté par  . Évalué à 10.

        ouaips, mais justement, pour l'instant il n'y a pas de patch... et je pense que le patch va prendre la forme d'un patch-2.4.19 et patch-2.2.21.

        Coder moi-même le patch, je pense que ca rentre pas trop dans mes fonctions d'admin, les serveurs dont je m'occupe sont assez critiques ;-) Je préfère laisser faire ceux qui connaissent très bien le noyau, ils feront moins de conneries que moi...
        • [^] # Re: Mettre à jour...

          Posté par  . Évalué à -10.

          Et bien on a pas la même conception du métier d'admin. Un admin ne doit pas seulement connaitre la conf d'Apache et apt-get, il doit aussi connaitre assez bien le système qu'il utilise - son fonctionnement interne je veux dire -, la prog système et le langage C. Et faire un patch provisoire pour ce genre de choses, oui, ça rentre dans le boulot d'un admin. Je parle d'un admin professionel qui fait ça a plein temps bien sur, pas de quelqu'un qui fait un peu d'admin en plus du reste.
          • [^] # Re: Mettre à jour...

            Posté par  . Évalué à 10.

            Effectivement on n'a pas la même conception du métier d'admin. Pour moi, faire de l'admin c'est maitriser les différents produits utilisés ainsi que leur configuration, maintenir le tout à jour, appliquer les patchs quand ils sortent, développer ses propres outils d'admins.

            Oui, mon métier est admin. A temps plein. Mais non, je ne connais pas suffisament le code source des produits que j'utilise pour écrire moi-même les patchs sécurité. Si t'es capable de patcher le noyau linux, squid, apache, php, zlib, postfix, proftpd, rsync, etc... sur des serveurs critiques avant le patch officiel, chapeau.

            Je sais lire un code source, appliquer un patch à la main, mais ce n'est pas en lisant un source de temps en temps qu'on en maitrise le concept et les implications des modifications. Je préfère laisser ça aux développeurs du produit - à moins qu'il ne s'agisse d'un produit qui m'intéresse pour d'autres raisons et pour lequel je connais son fonctionnement interne - auquel cas oui, je me risquerais à faire un patch.

            A priori dès qu'un bug sort sur ce genre de produit (ie avec plus d'un développeur), les développeurs cherchent à corriger le problème. Si je commence à chercher où se trouve la faille dans le source, comment patcher sans faire foirer les trucs à côté, tester sur une config de test pour minimiser l'impact sur la production... avant la fin de ma recette le patch officiel sera sorti. Donc non, faire des patchs suite à des failles de sécurité ce n'est pas mon métier.

            Par contre oui, patcher pour ajouter des fonctionalités à un produit fait partie de ma tâche d'admin. Mais à ce moment là j'ai tout mon temps pour lire le source, comprendre sa logique, tester mon patch, etc...
            • [^] # Re: Mettre à jour...

              Posté par  . Évalué à -10.

              Parce que tu fais des patchs pour rajouter des fonctionnalités et pas pour corriger des trous de sécurités ? Corriger un trou de sécurité c'est souvent quelques lignes de code, qui ne nécessitent pas une connaissance complète du système. Pour ce trou là, c'est juste renvoyer une erreur au lieu de succès quand le path a été tronqué... c'est beaucoup plus simple et beaucoup moins risqué que de rajouter des fonctionnalités.
              • [^] # Re: Mettre à jour...

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

                Tu l'as appris où ton metier ?

                Je doute meme que tu sois admin d'ailleur ...

                --
                Ker2x
              • [^] # Re: Mettre à jour...

                Posté par  . Évalué à 10.

                >un trou de sécurité c'est souvent quelques lignes de code
                As tu deja corrige une faille de securite?
                > qui ne nécessitent pas une connaissance complète du système
                C'est tres recommande.
              • [^] # Re: Mettre à jour...

                Posté par  . Évalué à 10.

                [..]Corriger un trou de sécurité c'est souvent quelques lignes de code qui ne nécessitent pas une connaissance complète du système[..]
                Si seulement vous pouviez avoir raison, apres tout, ce serait beaucoup plus simple.
                Seulement, autant il peut s'agir des trous triviaux a corriger, du fait qu'ils proviennent d'une faute d'inattention du codeur, trous qui peuvent sauter aux yeux, lors d'un simple audit du code, par un lecteur avise ou non. Autant il peut s'agir d'une remise en question du design original du code, et la je pense que vous faites fausse route.

                En ce qui concerne vos affirmations sur les taches que devrait pouvoir remplir un administrateur, je reste sans mot, aussi je ne commenterais pas.

                PS: si j'en juge par la qualite de vos posts sur LKML, vous etes tout pardonne puisque tout ceci vous depasse.
                • [^] # Re: Mettre à jour...

                  Posté par  . Évalué à -1.

                  Je n'ai jamais dit que *tous* les trous de sécu étaient simples à corriger, j'ai dit qu'ils l'étaient *souvent*. Beaucoup de trous sont dus à une vérification manquante, un strcpy au lieu d'un strncpy, ou ce genre de choses, et se corrigent en quelques lignes. Bien sûr que certains trous sont beaucoup plus complexes à corriger. Dans le cas présent, il ne s'agit pas d'un trou de conception, et ça ne doit donc pas être extrêment compliqué de corriger.

                  si j'en juge par la qualite de vos posts sur LKML, vous etes tout pardonne puisque tout ceci vous depasse.

                  Vous ? c'est qui le vous ?
                  Si c'est moi, déjà ce sera bien le première fois que je vois des gens se vouvoyer sur DLFP, et ensuite à part quelques bugs reports et un point godwin, je n'ai jamais rien posté sur la LKML... je lis rapidement c'est tout...
          • [^] # Re: Mettre à jour...

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

            Superman lover ;))

            http://www.kip.ru/s/daemons/takeittux.jpg(...)

            @+
            Code34
          • [^] # Re: Mettre à jour...

            Posté par  . Évalué à -1.

            Ah? C'est comme quand on est admin et qu'on veut installer Le Hurd, si on veut le clavier, faut dabord écrire le driver a la main?
      • [^] # ouais moi aussi je patche!

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

        si les root aimaient patcher, ils se lèveraient sur leurs petites pattes arrières, zyeuteraient le code source et feraient du bon vi.
        au lieu de ça, les root fument des pétards, jouent au babyfoot et grippent au plafond.

        ok ok ok ok
        • [^] # Message aux scoreurs

          Posté par  . Évalué à -10.

          Euh... ça sert à quoi de voter [-] sur les posts auto-censurés à -1 ??? Le post précédant c'était de l'humour, proprement mis à -1... Enfin, vous faites ce que vous voulez, mais je crois que vous avez mal compris l'utilité du vote [-] et la signification de la case -1

          -1 car complètement HS
          • [^] # Re: Message aux scoreurs

            Posté par  . Évalué à -1.

            ben moi j'ai voté [+] pasque sinon j'irai mouler sur 01 ou LMI mais c'est beaucoup moins drole.

            -1 aussi mais comme tu le dis ça ne sert à rien de l'écrire...
          • [^] # Re: Message aux scoreurs

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

            A te faire perdre des points d'xp qd on trouve que tu dis une connerie, pourquoi ?

            +1 pasque je le veux bien.

            --
            Kerdezixe
        • [^] # Re: ouais moi aussi je patche!

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

          T'façon les roots c'est des branleurs :o)
    • [^] # Re: Mettre à jour...

      Posté par  . Évalué à -10.

      Il n'y a rien à faire sinon attendre le prochain noyau,

      Arg ! Et qu'est ce qu'il faut faire en attendant ?
      C'est pas un peu dangereux d'annoncer à tout le monde une faille sans qu'il y ait de solution ?

      A moins de verrouiller...
      • [^] # Re: Mettre à jour...

        Posté par  . Évalué à 10.

        C'est dingue de voir à chaque news sur un trou de sécu la même rengaine... On est pas chez microsoft ici. On ne protège pas les gens en leur cachant la vérité. S'il y a un trou, il *faut* diffuser l'information le plus possible. Pour que les admins aussi soient au courant, et pas juste une poignée de personne.

        Après libres à eux de prendre les mesures qu'il faut: couper temporairement certains services, faire un patch provisoire eux-mêmes, ... mais dissimuler des informations n'a jamais servi qui que ce soit, à part ceux qui possèdent déjà cette information.
        • [^] # Re: Mettre à jour...

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

          Ou, quand on dit savoir ce que le boulot, refiler sa solution aux autres afin qu'ils puissent en profiter et/ou l'ameliore.... wait and see kilo, parle moins, et file nous une soluce...
          • [^] # Re: Mettre à jour...

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

            La solution? Déclarer les bugs quand on les voit. Ce n'est pas en se voilant la face qu'un soft évolue.
            Soit on dit "Linux a un bug a tel endroit" et quelques dévellopeurs essaient d'y remédier, et ça peut aller trés vite, soit la personne qui a découvert la faille ne dit rien jusqu'à ce qu'elle ai trouver la faille et dans ce cas ça peut prendre du temps.
            Dans le premier cas, ça peut permettre aux admin de couper certains services jusqu'à l'arrivé d'un patch, dans le second, les admin n'étant pas au courant ne font rien.
            • [^] # Re: Mettre à jour...

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

              Oui, oui on a comprit... J'ai pas dit le contraire

              En reprennant les discutions de Mr Kilo* on voit qu'il dit carrement que l'admin DOIT savoir faire un p'tit patch vite fait (Et tant pis si il sait pas, c'est pas un vrai2vrai), et attendant les officels.

              Donc je lui demandais juste de se bouger et de nous le filer le sien des qu'il aurait fini :^) la...
              • [^] # Re: Mettre à jour...

                Posté par  . Évalué à -3.

                Mr Kilo*

                Kilo* ? Pourquoi ne pas dire mon pseudo complet ? Tu as peur d'invoquer un démon majeur ? :)

                dit carrement que l'admin DOIT savoir faire un p'tit patch vite fait

                Oui. Enfin, relativisons. Je ne dis pas qu'un admin doit être capable de tout patcher, mais dans beaucoup de cas, les trous de sécurités sont dus à des oublis ou des étourderies et se patchent très simplement pour qui connaît bien le C. Or, oui, je l'affirme une bonne connaissance du langage C est nécessaire pour être administrer une machine Unix sensible.

                Donc je lui demandais juste de se bouger et de nous le filer le sien des qu'il aurait fini :^) la...

                Je ne suis pas admin (sinon je serais dans le code entrain de faire un patch là...)

                -1 car ça part en ***** ce débat
                • [^] # Re: Mettre à jour... -1

                  Posté par  . Évalué à -5.

                  "je l'affirme une bonne connaissance du langage C est nécessaire pour être administrer une machine Unix sensible."

                  oui oui... D'ailleurs j'ai le code de solaris et à la moindre alerte j'installe emacs et gcc sur une machine de prex...

                  -1
                • [^] # Re: Mettre à jour...

                  Posté par  . Évalué à 0.

                  Faut aussi savoir souder au cas ou une carte grille et qu'on puisse réparer en soudant une chtite résistance par-ci par-là en attendant de recevoir la bonne pièce.
                • [^] # Re: Mettre à jour...

                  Posté par  . Évalué à 1.

                  «Kilo* ? Pourquoi ne pas dire mon pseudo complet ? Tu as peur d'invoquer un démon majeur ? :)»

                  Bah, il devait oublier que dire 'Kilobug', c'est sans danger tant qu'on dit pas 'GNU' et 'Hurd' dans la même phrase. Ohmerde.
        • [^] # Re: Mettre à jour...

          Posté par  . Évalué à -2.

          Mort de rire !!!

          Grace à moi t'as gagné au moins 32 XPs!

          ----
          Homotrollus.
    • [^] # Re: Mettre à jour...

      Posté par  . Évalué à 9.

      Certes il ne faut pas minimiser l'impact de cette faille ... mais:

      elle depend d'un débordement de buffer sur les noms de chemin. Pour l'activer, il faut quand meme créer en local (peut etre sur un drive reseau aussi) une arborescence de fou.

      la faille c'est que le noyau, au lieu de renvoyer une erreur, renvoie la taille de son buffer (trop petit) et donc renvoie un chemin tronqué.

      A priori ce sera difficile a exploiter a distance, puisqu'il faut avoir le droit de creer des repertoires imbriqués sur la machine.

      Cela ne signifie pas que c'est impossible si vous hebergez un serveur FTP avec droit en écriture par exemple.(encore que la création de repertoires imbriqués n'est pas conseillée sur les serveurs FTP).
      • [^] # Re: Mettre à jour...

        Posté par  . Évalué à -2.

        Pour l'activer, il faut quand meme créer en local (peut etre sur un drive reseau aussi) une arborescence de fou.

        Je me demande si /home/../home/../home/..... peut permettre de dépasser le buffer même si les noms de fichiers ne sont pas trop longs...

        -1 car je dis peut-être une bêtise
        • [^] # bétise ?!?

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

          Ben non, pas tant que ça, puisque je doute que le kernel traite en interne la résolution de noms de fichiers relatifs.
          Techniquement, ce "zig-zag" doit parfaitement marcher.

          A tester

          (et je n'oublierai plus le "m" de "grimper", ni de citer les nuls, ni d'indiquer mes "-1", ni de remercier tous les gentils scoreurs qui ont de l'humour)
  • # C'est dingue !!

    Posté par  . Évalué à 10.

    C'est fou comme on trouve des bugs c'est temps-çi !! J'en reviens toujours pas.. Mais ça veux dire qu'y a plus de monde qui utilise du libre! On va enfin pouvoir montrer la puissance du libre : à savoir,un temps de résolution de problème imbattable :P

    Mais j'avoue que des fois,j'ai envie de sauter sur les BSD(openbsd pour les paranos ou freebsd pour les gens "normaux") pour quelques temps le temps que la marée de gros bugs linux passe :|

    Les forces libre vaincront...
    • [^] # Re: C'est dingue !!

      Posté par  . Évalué à 6.

      Ah bon, on en trouve aussi souvent que ça ? J'ai pas trop suivi les problèmes du noyau Linux, mais il n'y en a pas tant que ça d'aussi grave, si ?
      • [^] # Re: C'est dingue !!

        Posté par  . Évalué à -4.

        nan a priori c'est problematique sur les programmes priviligies (lance en droit root ou setuid root) qui font certaines operations sur le systeme de fichier (chdir, readlink, etc). donc a ce que j'en ai vu c'est pas grave.
      • [^] # Re: De Schneider à Jak

        Posté par  . Évalué à -2.

        Pas si souvent que ça,mais on a vu de bugs(pas necessairement majeur) qui on fait des belles surprises sur les forums(ici aussi il me semble)!

        Des bugs qu'on pensaient impensable!! Mais c'était des bugs applicatifs dans la plupars des cas et qui touchait plusieurs plateformes(openssh dernièrement) autre que linux :)

        J'avoue être encore très novice(je me perd encore dans KDE et Gnome) et je peux avoir une fausse idée de la situation...eeeh,juste comme ça,y en a pas qui trouve que KDE et Gnome sont pas très pratique?? J'en viens à penser que la ligne de commande est moins compliqué ^_^ ...
        • [^] # Re: De Schneider à Jak

          Posté par  . Évalué à 1.

          Oui, mais par exemple, le bug de la zlib dont on a parlé récemment est susceptible de toucher aussi les applis Microsoft qui l'utilisent. C'est de l'OpenSource, mais pas lié à Linux spécifiquement.
          Linuxfr a arrêté de parler des failles de sécurité des produits Microsoft en ce qui concerne IE, IIS, Outlook, etc, et c'est logique, mais ce n'est pas parce qu'une faille est révélée ici qu'elle est à imputer au noyau Linux.
    • [^] # Re: C'est dingue !!

      Posté par  . Évalué à 2.

      > openbsd pour les paranos
      Je ne suis pas d'accord. OpenBSD est avant tout un OS stable et a mon sens, excellement documente (jetez un coup d'oeil aux pages de man).
      > freebsd pour les gens "normaux"
      Je ne pense que les utilisateurs d'unix libres soient dans la normalite pour l'instant.
      • [^] # Re: De Schneider à Delaregue

        Posté par  . Évalué à 0.

        >Je ne suis pas d'accord. OpenBSD est avant tout un OS stable et a mon sens, excellement documente

        hmm...Openbsd est très stable et pas de bugs de sécurité dans l'installation par défaut depuis plus de 2 ans si j'ai bien saisie :P

        Mais c'est la cryptographie en natif qui tue selon moi et j'aime à m'imaginer qu'un VNP avec Openbsd soit "pratiquement" inviolable s'il est bien configuré :P

        J'aimerais faire un firewall avec openbsd,je pense pouvoir dire sans me tromper que le hacker qui va s'essayer à me rentrer dedans avec ça ,va en ch... un max ;D

        >Je ne pense que les utilisateurs d'unix libres soient dans la normalite pour l'instant.

        Touché !! Parfaitement d'accord :)))
        La normalité,c'est extrèmement relatif !!!
        Plus on est fou,mieux que c'est,sinon,la vie est un peu morne....
        • [^] # Re: De Schneider à Delaregue

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

          hmm...Openbsd est très stable et pas de bugs de sécurité dans l'installation par défaut depuis plus de 2 ans si j'ai bien saisie :P

          A c't'heure ça fait ben 4 ans qu'y'a pas eu de trous de sécu dans l'install par défaut !
          • [^] # Re: De Schneider à Delaregue

            Posté par  . Évalué à 0.

            Ho oui Ho ouiii !!!

            je m'étais planté,merci

            C'est encore mieux que je pensais,mouaahahaaaaa :P

            Les forces du libre vaincront...
          • [^] # OpenBSD

            Posté par  . Évalué à 1.

            En fait, je crois que c'est plutôt aucun trou de sécurité "remote" dans l'install par défaut.

            Pour autant, on ne peut pas dire pour autant que les démons soit parfaitement sécurisés, je crois me souvenir d'une faille sur Bugtraq concernant serveur FTP d'OpenBSD il y a un an. Elle ne comptait pas, car le serveur FTP n'était pas dans
            l'install par défaut.
            Les multiples race conditions dans le noyau (similaire à celle que l'on avait trouvé dans Linux) ne comptent pas non plus car elles sont "locales".

            En fait, j'ai l'impression que l'install par défaut n'installe aucun programme accessible en "remote", d'ou le fameux slogan qui permet de dire : OpenBSD, c'est le serveur ne servant à rien le plus sécurisé de la planète.
            • [^] # Re: OpenBSD

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

              Oui, j'ai oublié remote !

              Cependant dans l'install par défaut on a quand même ssh qui écoute dehors. C'est pas rien !
              • [^] # Re: OpenBSD

                Posté par  . Évalué à 1.

                Ils ont pas trouvé une faille (off by one je crois) récemment dans SSH (auth.c)

                Comment ça se fait qu'OpenBSD n'est pas concerné, ils sont pas vulnérables ou bien c'est quand leur histoire d'install par défaut qui fait que "celle-la elle compte pas" ?
          • [^] # Re: De Schneider à Delaregue

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

            J'ai pas vu de trou de sécurité dans un caillou depuis au moins 4 milliards d'année. Le caillou est mieux sécurisé. Et en plus y'a même pas besoin de l'installer.
    • [^] # Re: C'est dingue !!

      Posté par  . Évalué à 5.

      La tres grande majorité des bugs sous linux (GNU/Linux) sont des bugs applicatifs. Donc des bugs que tu retrouvera surement sous *BSD (php, zlib, etc...).

      Mais si ça te rassure passe sous *BSD.

      Tu peux aussi faire la politique de l'autruche :
      - utiliser Windows
      - ne visiter que www.microsoft.com
      • [^] # Re: De Schneider à matiasf

        Posté par  . Évalué à -3.

        C'est vrai,j'aurais dût spécifier que les bugs était applicatifs :( mais j'ai pas pensé à le faire,désolé !

        Mais si je passe sous BSD(oui,si),ça va surement pas pour être rassuré!! Je me suis senti un peu insulté par cette déclaration,mais ,vu que tu me connais pas c'est compréhensible et je passe la main :)

        J'avoue être chatouilleux sur ce point là: me faire dire que je suis un lâche dans ce que je fait(même si des fois,ça peut être justifié)...

        >Tu peux aussi faire la politique de l'autruche :
        >- utiliser Windows
        >- ne visiter que www.microsoft.com


        OUCH!! Celle-là, elle à fait VRAIMENT mal >:|
        Je sais pas dans quel sens tu me dit ça mais devant mon clavier, je me sent insulté en caliss(terme quebecois) !!!

        J'ai vraiment pas aimé ,précise si tu le veux bien si j'ai pas bien interprété !

        Pour ton information, je suis dans un cours d'administrateur de réseau et télécoms ,et j'apprend actuellement win2000 serveur ET ÇA ME FAIT ROYALEMENT CHIER(désolé...) !!!!

        J'apprend cisco dans 1 mois(c'est un cours de 1 ans compressé) et c'est un cours assez plein,j'ai pas beaucoup de temps pour moi(entre l'école et les dépannages,ouf). Mais j'essaie d'apprendre les logiciels libres et la philosophie du libre du mieux que je peux et ça aide pas de se faire descendre comme tu viens de le faire...

        C'est "presque" impardonnable et c'est indigne d'un "evêque" ....
      • [^] # Re: C'est dingue !!

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

        Le bug de php n'a pas su être exploité ss freebsd
  • # Ca a pas l'air trop trop méchant

    Posté par  . Évalué à 4.

    D'après ce que j'ai vu, à part le process perd les pédales et sait plus où il est, c'est pas encore trop trop méchant... Il y a des processes que cela ne devrait pas gêner (notament certain démons qui se positionnent dans un répertoire avant de faire quoi que çe soit). Attention quand même à argv[0] !

    Et puis on lance rarement des process root n'importe comment.

    On est loin du root exploit.
    • [^] # Re: Ca a pas l'air trop trop méchant

      Posté par  . Évalué à 1.

      à part le process perd les pédales et sait plus où il est,
      Et ça permet pas de faire un DoS ?

      Enfin, je dis ça, je sais pas, hein...
      • [^] # Re: Ca a pas l'air trop trop méchant

        Posté par  . Évalué à -3.

        Des process, t'en lances beaucoup dans ces conditions ?
        • [^] # Re: Ca a pas l'air trop trop méchant

          Posté par  . Évalué à 0.

          Ben moi, sur certains serveurs, j'ai une 60aine d'apaches qui tournent, presque autant de ftpd, et pis sans compter les php en su-exec, donc qui se positionnent effectivement dans un répertoire donné... Le mutualisé, c'est très sensible aux DoS :(
  • # a propos de Netscape ;)

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

    ah ouai, un truc de moindre importance ;()

    netscape 6.2.x est sorti depuis quelques jours [..]

    http://www.netscape.com(...)

    @+
    Code34
  • # Mandrake 8.2 vol à l'adhérent ;))

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

    je viens de lire un truc assez fort sur toolinux.com .

    Mandrake a fait paraitre par voix de presse un communiqué expliquant que staroffice 6.0 n'est intégré que dans les versions pro de mandrake oem[..]

    Selon l'accord passé avec Sun, Mandrake devait mettre aussi à disposition des adhérents de son club (dont on avait parlé il y a quelques jours) Staroffice en Oem...

    Seulement, ça leur prendrait trop de ressources... Ils ont donc décidé de mettre à disposition Staroffice uniquement pour les adhérents Silver ...

    Comme quoi c est bien beau de racoler un max de personnes, et de faire appel à la bonté des utilisateurs en leur disant que peu importe leurs contributions on a les meme avantages...

    Si je ne me trompe pas c est de la publicité mensongère.

    @+
    Code34
  • # mauvaise langue

    Posté par  . Évalué à -4.

    c pas pour faire chier le peuple, mais à mettre quake3VersionHardcoreBigboobs.o dans le kernell, c'est pas la grosse surprise que y'ait des bugs qui apparaissent

    sérieusement, p-e le temps de penser que le kernel est un kernel, c'est pas la place ppur mettre des choses genre TUX
    au pire, que les codeurs le concoivent pour qu'il puisse marcher en noyeau, cool!, mais que le monde veuillent l,avoir dans le kernell oficiel, là...

    ça s'applique p-e pas ici, vu que ça l air du fct de bas niveau et indispensable, mais la déferlante de bug commence à m énerver un peu


    dans le fond, les microkernel, c est vrai que théoriquement, c mieux que le mono
  • # Zeu patch, made by moi ;-)

    Posté par  . Évalué à 8.

    Voila, j'ai trafiqué mon 2.2.20, apparament ça marche ...
    Mais comme j'ai pas une totle maîtrise de la Force, faut voir...


    --- /usr/src/linux/fs/dcache.c.orig Fri Nov 2 17:39:08 2001
    +++ /usr/src/linux/fs/dcache.c Wed Mar 27 23:30:32 2002
    @@ -794,8 +794,11 @@
    break;
    namelen = dentry->d_name.len;
    buflen -= namelen + 1;
    - if (buflen < 0)
    + if (buflen < 0) {
    + /* FIXME : buffer overflow -> no return */
    + retval = buffer+buflen;
    break;
    + }
    end -= namelen;
    memcpy(end, dentry->d_name.name, namelen);
    *--end = '/';


    J'ai testé l'exploit, je me fais pas avoir, moi ;-)

Suivre le flux des commentaires

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