Les hébergeurs qui ont patché PHP

Posté par  . Modéré par Pascal Terjan.
Étiquettes : aucune
0
26
mar.
2002
PHP
Le 27 février, un trou de sécurité était détecté dans PHP, affectant quelques 100 000 sites sur les 9 000 000 d'utilisateurs. La réaction des hébergeurs partagés ne s'est pas fait attendre, et ils ont appliqué le patch presque immédiatement. Une réaction rapide et saine de la communauté et de ses acteurs.

Aller plus loin

  • # dans leur intéret

    Posté par  . Évalué à 10.

    En ce qui concerne le ISP c'est plutot dans leur intéret de réagir rapidement.

    Par contre : la liste des ISP "non secure" est surement (et malheureusement) beaucoup plus longue...

    Il me semble que le bug touche la fonction d'upload de fichier de PHP , tous les hébergeurs n'utilisent peut être pas cette fonction pour LEURS sites, mais comment peuvent il garantir que leurs abonnés ne l'utilisent pas ? (non, je ne préfère même pas imaginer le gros grep de goret... ;)

    • [^] # Re: dans leur intéret

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

      Il n'y a pas besoin de l'utiliser pour etre sensible au probleme. C'est lors de la réception de la pièce (découpage plus précisement) qu'il y a eu un probleme. Que après tu l'utilise ou pas importe peu ... la requete HTTP sera interprétée quand même.

      • [^] # Re: dans leur intéret

        Posté par  . Évalué à -5.

        Oui, mais la solution étant :
        - soit patcher la version, si c'est possible, puisqu'il n'y a pas de patch pour toutes les versions
        - soit passer à une version supérieure, mais c'est pas toujours possible
        - soit désactiver le file_uploads

        Pour cette dernière solution, il faut savoir si les gens utilisent ou pas la fonctionnalité pour savoir si on peut l'appliquer...

        • [^] # Re: dans leur intéret

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

          - soit désactiver le file_uploads

          Pour cette dernière solution, il faut savoir si les gens utilisent ou pas la fonctionnalité pour savoir si on peut l'appliquer...


          Non, cette solution est une solution temporaire, le temps de patcher. A mon avis il vaut mieux désactiver la chose meme si les gens l'utilisent plutot qu'avoir une faille de sécu connue (php est assez connu et la faille n'est pas passée inapercue) permettant d'obtenir les droits du serveur web.
          Enfin c'est vrai que ca dépend de la politique de l'hebergeur, certains prefèrent jouer les autruches ou tabler sur la probabilité qu'ils n'auront rien.

          Ceci dit un path c'est vite mis en place.

  • # zlib

    Posté par  . Évalué à 5.

    Bon patcher PHP c'est pas difficile, je l'ai fait dans la journée en quelques minutes.

    Mais zlib c'est une autre histoire.... Ca m'a pris 2 jours pour recompiler tout ce qui était lié de près ou de loin à zlib...je me demande combien de ceux qui figurent sur cette liste l'ont fait !

    • [^] # Re: zlib

      Posté par  . Évalué à 7.

      D'où l'intérêt des distributions qui font cela pour toi !

    • [^] # Re: zlib

      Posté par  . Évalué à -7.

      c bien , tu as tout recompilé , tu as vraiment que ca a foutre de tes journées ???

      debian ro><or

      • [^] # Re: zlib

        Posté par  . Évalué à 4.

        Non, perso j'avais gardé les sources, j'ai mis le patch, fait make, il a juste recompilé le fichier impacté puis relinké. J'ai fait make install, puis relancer apache (parceque PHP en module).

        Ca a été plus rapide que de télécharger un package mis à jour.

    • [^] # Re: zlib

      Posté par  . Évalué à 8.

      Seules les applis liées statiquement doivent être re-liées (même pas besoin de recompiler).

Suivre le flux des commentaires

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