A propos d’une « faille » trouvée dans WordPress 3.0.4…

Hier a été diffusé un rapport de faille de sécurité relatif à la version 3.0.4 de WordPress, et aux versions précédentes.

« Allons bon, à peine une mise à jour de sécurité importante de faite, qu’une nouvelle faille se présente déjà ? Quelle passoire, ce WordPress ! Vive SPIP ! »

Il n’en est rien. Cette « faille » n’est pas dangereuse, et je vais expliquer pourquoi juste après. Cependant, le FUD est lancé : la pseudo-faille a été largement relayée par le blog Korben, très populaire, et de là repris et retweeté maintes fois. En bref, LE PEUPLE A PEUR. Il nous faut donc apaiser les coeurs, en ce dernier jour de 2010 : oyez, oyez, vous n’avez rien à craindre avec ce type de faille.

Voici le commentaire que j’ai tenté de mettre chez Korben hier soir, en vain (antispam trop exigeant ?) :

Généralement, il est préférable de rester discret et d’écrire à security@wordpress.org, plutôt que de faire paniquer tout le monde :)

L’équipe de développement voit se genre de « hack » quasiment toutes les semaines. Celui-ci, comme beaucoup d’autres, est bien plus inoffensif que ton article ne laisse l’entendre, Korben. Comme indiqué dans le rapport, « The attacker has to be the authority of the editor » (« le hacker doit être inscrit en tant qu’Éditeur »). Dans les faits, le code HTML des Éditeurs et Administrateurs (les deux rôles les plus hauts dans la hiérarchie de WP, donc a priori pas les premiers venus) n’est pas filtré, ils peuvent publier ce qu’ils veulent… et cela ne pose aucun problème de sécurité, comme l’explique le lien suivant :
http://codex.wordpress.org/FAQ_Security#Why_are_some_users_allowed_to_post_unfiltered_HTML.3F

Donc : rien de grave.

Voyant les retweets, j’ai directement mailé Korben ce matin, mais le mal est fait, d’où le présent article.

Pour ceux qui ne parlent pas anglais, je traduis le paragraphe du Codex :

Pourquoi certains utilisateurs ont-ils le droit de publier du contenu HTML non filtré ?

Les utilisateurs ayant pour rôle Administrateur ou Éditeur sont autorisés à publier du code HTML non filtré dans les titres et le contenu de leurs articles. WordPress est, après tout, un outil de publication, et les gens doivent être en mesure d’inclure n’importe quelle balisage dont ils auraient besoin pour communiquer. Les utilisateurs avec des privilèges moindres ne sont pas autorisés à publier du contenu non filtré. Si vous effectuez des tests de sécurité sur WordPress, utilisez un utilisateur avec un rôle moindre, afin que tout le contenu soit filtré. Si vous êtes inquiet de voir un administrateur mettre XSS dans le contenu et  voler les cookies de vos utilisateurs, notez que tous les cookies sont codés pour ne fonctionner qu’en livraison HTML (ndt: « HTTP only delivery »), et sont divisés entre cookies avec privilèges pour les pages d’administration, et les cookies sans privilèges pour les pages publiques. Le contenu n’est jamais affiché dans l’administration sans être filtré. Dans tous les cas, un administrateur a de vastes pouvoirs, parmi lesquels le contenu non filtré n’est que le moins dangereux.

En mode multisite, seuls les Super Admins peuvent publier du HTML non filtré, car tous les autres utilisateurs sont considérés comme non fiables.

Si je précise que le rôle d’Editeur est l’un des plus élevé de la hiérarchie WP, c’est qu’en toute bonne logique, si vous donnez ce rôle à n’importe qui, vous avez bien d’autres soucis à vous faire que de voir des scripts-kiddies vous balancer des injections XSS. Faites le test de cette faille avec un rôle inférieur, et bigre ! Aucun souci.
Vous avez des Administrateurs et Éditeurs en lesquels vous n’avez pas vraiment confiance ? Là c’est VOTRE politique de sécurité qui est en cause, pas celle de WordPress. Vous donneriez les clefs de votre maison au premier venu ? Je ne crois pas…
Ah, et pour les extensions de publication ouverte, le contenu HTML est bien filtré, vu que leur rôle est minimal.

Pour terminer, je pense que l’équipe des développeurs de WP a largement fait ses preuves en matière de réactivité face aux failles. Si vous avez entendu parler d’une faille sur un blog populaire, il y a de grandes chances pour que l’info leur soit déjà parvenue directement. Et si vous ne voyez pas de mise à jour de sécurité, il est plus que certain que la-dite faille n’est en fait pas si pertinente.
En définitive, le mieux est d’écrire directement à security@wordpress.org pour avoir le mot de la fin.

Sur ce, bonnes fêtes de fin d’année à tous ! :)

Ajouté le 1er janvier : et voilà, à force de voir cette fausse information se faire relayer, les développeurs de WP ont dû se fendre d’un article pour écrire plus ou moins ce que j’ai écris ci-dessus, ET (fait très rare) se fendre d’un commentaire bilingue sur le blog de Korben. Le site cité par Korben a d’ailleurs effacé la page décrivant cette « faille ».

L'auteur :

Mainteneur de la traduction en français de WordPress. Son blog perso.

Informations annexes à l'article

Cet article a été publié le Vendredi 31 décembre 2010 à 8:35 et est classé dans Blog, WordPress.

Vous pouvez en suivre les commentaires par le biais du flux RSS 2.0.

Les commentaires et pings sont fermés.

Article lu 12 754 fois.

Méta

1 étoile2 étoiles3 étoiles4 étoiles5 étoiles (2 votes, average: 5,00 out of 5)
Loading...Loading...
Imprimer cette article Envoyer cet article à un ami

22 commentaires

  1. Bon, ça a le mérite d’être clair: Korben a paniqué :D
    Merci pour le post.

  2. Salut Xavier,
    Il y a quand même une sacrée différence entre poster du code non filtré et pouvoir utiliser une faille XSS. Dans des cas comme l’utilisation d’un plugin TDOMF par exemple, cette faille peut être dangereuse car l’internaute a ce fameux rôle éditeur. Tout cela je l’ai expliqué dans mon l’article.

    Après si effectivement ce n’est pas dangereux et qu’il n’y a rien à craindre, je ne comprend pas bien pourquoi les gens de chez WordPress ont sorti la 3.0.4 en urgence, en mailant tout le monde pour dire « faites la MAJ viiiite ».

    Il m’a semblé bon de relayer cette demande initiale. Dommage juste qu’on se retrouve avec la quasi même faille dans la 3.0.4

    Loin de moi l’idée de lancer un FUD, j’ai juste relayé les faits… Y’a une faille accessible aux éditeurs (et pas simplement une fonctionnalité d’HTML non filtré) et dans certains cas où tu n’as pas confiance en tes éditeurs ou que des plugins utilisent ce rôle éditeur pour l’internaute, ça reste quand même une faille importante.

  3. >Il nous faut donc apaiser les coeurs, en ce dernier jour de 2010

  4. Il nous faut donc apaiser les coeurs, en ce dernier jour de 2010

    Déjà ? :-)

  5. J’suis pas reveillé moi lol.. vous avez modifié le temps que j’écrive mon commentaire :O

  6. Korben : comme je l’explique, si tu n’as pas confiance en tes éditeurs, c’est un problème de politique de sécurité propre au blog, pas à WordPress. Un éditeur peut directement effacer tes pages, tes articles, tes catégories, tes commentaires… et ce directement dans l’admin ! Tu penses qu’avec un tel rôle, il se prendrait la tête à faire une injection XSS ? :)

    Dans tous les cas, je le répète, le rôle d’Admin et d’Éditeur doit être réservé aux personnes de confiance, pas au premier venu qui veut publier un article.

    Quant aux extensions qui utilisent ce rôle, elles sont mal codées, donc la faille est dans l’extension, pas dans WordPress. Il faut contacter l’auteur de l’extension.

    La mise à jour de la 3.0.4 était certes sur un thème similaire, mais beaucoup plus large — et est maintenant résolue. Avec la 3.0.4, les utilisateurs sont maintenant pleinement protégés de ce genre d’attaque, ce qui n’était peut être pas le cas avec la 3.0.3 — d’où l’empressement à passer à la 3.0.4, et aujourd’hui la sérénité face à cette faille.

    Plus globalement : crois-moi, les core-dev de WP savent ce qu’ils font, et prennent tout problème de sécurité TRÈS au sérieux. S’ils m’ont dit hier soir qu’il n’y avait aucun problème, alors c’est qu’il n’y en a pas.

  7. Benji : oui, je m’étais mal relu au premier passage :)

  8. Ok ok :-)
    Pas grave alors… en même temps j’ai pas dit aux gens que c’était grave hein, j’ai juste relayé l’info en leur disant d’être prudent s’ils avaient des éditeurs un peu louches ;-)

  9. sinon, comme tu me l’as demandé, j’ai édité mon article avec un lien vers le tien.

    Meilleurs voeux Xavier

  10. Korben : merci, bonne fin d’année à toi également !

  11. Heu… vu qu’il y a possibilité d’hijack la session, il y a possibilité de choper celle d’un admin, donc de monter en droits de Editeur à Administrateur.

    Donc c’est critique.

    Dire « nan mais c’est bon, s’il est éditeur c’est que c’est pas un méchant » revient à supposer que l’utilisateur de ce rang ne va pas faire de bêtise à l’insu de son plein gré. C’est une hypothèse très forte, tout administrateur ou éditeur d’un blog n’a pas forcément les compétences techniques pour comprendre les implications de ses actions. Donc : on vérifie *toujours* ce qu’on va insérer dans une BD, d’où que ça vienne, sans exception.

  12. Les blogs mono-blogger (qui représentent probablement la majorité des WP) ont à mon avis intérêt à passer à la 3.0.4, et si j’ai relayé hier qu’il fallait mettre à jour et qu’aujourd’hui je relaye « la faille n’en est pas une », ça sent la confusion chez tous ceux qui lisent en diagonale…

    Bref, mieux vaut s’abstenir de relayer « cette faille WP n’en est pas une » pour l’instant, vous ne croyez pas ?

  13. Bonsoir,

    Je voulais juste dire que l’équipe de développeurs WordPress fait vraiment un boulot remarquable.

    Longue vie à WordPress et bonne année 2011 à toutes et à tous.

    Michel

  14. J’ai oublié de remercier Xavier pour cette news.

    Michel

  15. Effectivement Arena, le mot de la fin sur le blog de développement de WP ;)

    http://wpdevel.wordpress.com/2.....-accurate/

  16. JKB : le problème « à l’insu de son plein grès » est justement ce qui a été résolu avec la 3.0.4 (d’où la mise à jour essentielle). L’annonce initiale de la faille a été effacée du site cité par Korben. Je ne vois pas ce qu’il y a de plus élaborer…

    David S. : en fait, ça marche dans le sens inverse : il faut en premier lieu se renseigner avant de relayer « il y a une faille », vous ne croyez pas ?

  17. Oui Xavier bien sur il faut se renseigner avant de relayer, quelle que soit l’info… mais il y a ce que les gens devraient et ce que les gens font ;)

    Pas plus tard que ce matin j’ai eu contact avec une personne qui m’a dit que ce n’est pas la peine de faire la maj vers 3.0.4 car « la faille trouvée n’en était pas une », donc la confusion est bien là : les évènements « faille dans 3.0.3″ et « non-faille dans 3.0.4″ sont très rapprochés dans le temps…

  18. David S. : j’en suis bien conscient, malheureusement ce n’est certainement pas nous qu’il faut accuser de rétablir la vérité, mais certains autres de propager des rumeurs sans fondements. De fait, je t’enjoins à laisser un commentaire chez Korben ;)

  19. et hop une autre rumeur ,pour une autre faille
    http://blog.felix-aime.fr/deve.....ress-fear/
    j’ai eu le lien sur le site de Korben,dans un commentaire

  20. Anatolia Security a rapporté une vulnérabilité, classifiée comme « moyennement critique », pour WordPress 3.0.4, qui pourrait être exploitée par un internaute malveillant détourner les sessions des utilisateurs.

    Les entrées envoyées au paramètre « content », lors de la publication d’un commentaire sur un billet, ne sont pas traitées correctement avant d’être affichées au lecteur du billet.

    L’exploitation de la vulnérabilité nécessite que l’internaute malveillant puisse publier des commentaires sur un billet du blog WordPress vulnérable.

    La vulnérabilité a été confirmée pour la version 3.0.4 et 3.0.3. D’autres versions peuvent être affectées.

  21. Ca reste une faille, vous avez juste eu de la chance qu’elle se localise à cet endroit là et qu’il faille des privilèges relativement élevés pour pouvoir l’exploiter.

Les commentaires sont fermés.

écrire un commentaire