Rassurez vous, si vous êtes en 4.0 ou plus, la faille a été corrigée, mais sinon oui, parfois une faille mets des années à être découverte et corrigée, en attendant, il est rare qu’elle soit exploitée, si non connue du grand public.
Pourquoi 4 ans ?
La faille a été introduite avec la version 3.0 de WordPress et depuis, personne n’avait vu la faille. Je suis prêt à parier que de nombreuses personnes ont lu le code sans voir la faille.
Il n’est pas rare qu’une faille vive autant de temps, ce n’est pas dangereux d’avoir cette faille si elle n’est pas connue ET non corrigée.
C’est justement le cas ici, la faille a été découverte, puis donnée aux développeurs WordPress discrètement – le responsible disclosure – puis corrigée en version 4.0.
Ce n’est pas parce qu’il a fallu 4 ans pour corriger, que la faille est pour autant difficile à trouver, mais c’est aussi que personne ne s’était penché de nouveau dessus, finalement ce n’est qu’une seule ligne de code !
Le danger ?
Il y a effectivement un danger, le danger vient de la fonction wptexturize() qui permets de transformer certains caractères en d’autres comme les quotes anglaises, les points de suspension, les œ etc
Mais le code est vulnérable, encore faut-il le voir, ce qui est pas évident à voir d’un coup d’oeil. Voici le code qui pose problème :
[pastacode lang=”php” message=”wp-includes/formatting.php” highlight=”” provider=”manual” manual=”%24textarr%20%3D%20preg_split(‘%2F(%3C.*%3E%7C%5B.*%5D)%2FUs’%2C%20%24text%2C%20-1%2C%20PREG_SPLIT_DELIM_CAPTURE)%3B”/]
Voilà, vous voyez la faille ? Non, c’est normal !
Un peu d’explications
WordPress autorise quelques tags HTML dans les commentaires, comme <a>, <b>, et du code avec <code>.
Certains ont en liste blanche des attributs, différents pour chaque tag. Evidemment, l’attribut href est important pour les tags <a>, alors que l’attribut onmouseover serait lui indésirable.
Le problème survient quand un texte est formaté par la fonction wptexturize() qui est exécutée pour chaque commentaire et les autres blocs de texte.
Afin d’éviter d’interférer avec le formatage HTML, wptexturize() va d’abord découper le texte en segments. Cette découpe a pour but de séparer les tags HTML qui ne doivent pas être modifiés, du contenu qui doit l’être.
En plus des tags HTML, le code doit aussi prendre en compte les shortcodes entre crochets qui ne doivent pas être modifiés non plus.
Un texte contenant un mélange de crochets et tags peut mettre en difficulté la découpe et ainsi résulter en des morceaux non traités correctement.
Un pirate peut alors exploiter le bug pour ajouter des attributs dans le code HTML autorisé. Un attribut style peut être créé afin de couvrir la fenêtre entière pour forcer l’exécution d’un mouseover par exemple.
Il peut aussi insérer une nouvelle balise <script> pour charger du code JavaScript plus complexe, via un fichier exécuté depuis un autre site web.
Ce script peut aussi utiliser jQuery et les requêtes AJAX pour récupérer vos jetons de sécurité et ainsi poster des formulaires à votre place.
C’est bon, vous la voyez maintenant ?
Êtes-vous vulnérable ?
Théoriquement si vous êtes en 4.0 ou plus, la faille est bouchée car ce code a été refondu. Si vous n’êtes pas encore passés à la 3.0, vous n’êtes pas vulnérables à cette faille, pas celle-ci non, d’autres … Tenez vous à jour !
Si vous avez besoin de rester en 3.9.2 pour certains de vos clients, la meilleure solution est de patcher le core pour ne plus lancer cette fonction wptexturize().
Ouvrez wp-includes/formatting.php et cherchez function wptexturize(, puis ajoutez une ligne juste sous cette déclaration, comme ceci :
[pastacode lang=”php” message=”Hack wp-includes/formatting.php” highlight=”” provider=”manual” manual=”function%20wptexturize(%20%24text%20)%20%7B%0A%20%20%20%20%20%20%20%20return%20%24text%3B%20%2F%2F%20Celle-ci%0A…”/]
La meilleure solution est bien sûr de passer en 4.0.1 ou plus.
Inspiration et traduction de http://klikki.fi/adv/wordpress.html
