WordPress 4.2.1 : une mise à jour critique

Elle n’a été expérimentée que sur les versions les plus récentes de WordPress (3.9.3 à 4.2), mais concerne vraisemblablement toutes les installations du CMS : une faille critique de type XSS (script inter-site) peut permettre à n’importe quel internaute de prendre le contrôle d’un site en insérant du code malveillant via le module de commentaires.

Chercheur en sécurité informatique, le Finlandais Jouko Pynnönen a dévoilé cette vulnérabilité le 27 avril. Il estime qu’elle se rapproche d’une autre brèche révélée début 2014 – et corrigée dernièrement après 14 mois d’attente – par son confrère Cedric van Bockhaven.

Ce dernier avait déterminé que l’insertion, dans un commentaire, d’un caractère invalide, entraînait la troncation dudit commentaire avant son insertion dans la base de données. Une astuce qui permet d’ajouter en toute discrétion des balises HTML parmi celles que tolère WordPress : <a> pour faire un lien, <b> pour mettre du texte en gros… ou encore <code>, pour exécuter du code arbitraire.

La faille mise au jour par Jouko Pynnönen exploite le même principe, mais se fonde sur un dépassement de capacité : un commentaire est tronqué lorsqu’il pèse plus de 64 Ko.

Principale différence avec la vulnérabilité repérée par Cedric van Bockhaven : le code JavaScript ne peut s’exécuter directement dans le panneau d’administration, avec le commentaire simplement en liste d’attente : il faut que le modérateur l’ouvre.

Il existerait déjà des « exploits » mettant en oeuvre cette brèche pour changer le mot de passe de la session utilisateurs en cours, ajouter un compte administrateur, voire utiliser l’éditeur de thèmes et de plugins pour stocker du code PHP malveillant sur le serveur.

Si bien que l’éditeur américain Automattic, qui a pris sous son aile le projet WordPress, recommande vivement de passer à la version 4.2.1 du CMS, déployée en urgence comme une mise à jour mineure installée automatiquement par défaut.

Jouko Pynnönen avait découvert, fin 2014, une autre faille liée à des caractères spéciaux. En l’occurrence dans la fonction wptexturize(), utilisée pour remplacer certains éléments de texte par des caractères « enrichis » ; par exemple les guillemets français (touche 3 du clavier AZERTY) qui apparaissent comme des guillemets anglais (que l’on obtient avec Alt-174 et Alt-175).

Pour ne pas interférer avec le formatage HTML, wptexturize() divise d’abord le texte en segments. Les éléments entre crochets comme [CODE] sont normalement détectés et non texturisés. Mais un texte mêlant différents types de crochets ([ ], < >) peut perturber le processus… et texturiser partiellement du code HTML, facilitant alors l’ajout d’attributs à une balise.

Ci-dessous, la démonstration vidéo :

Crédit photo : mclek – Shutterstock.com