R.I.P. Timthumb et son CHMOD 777
C’est Li-An de l’écho des plugins qui l’a signalé sur le forum WordPress, TimThumb est définitivement mort et enterré, son créateur annonce officiellement la fin du support.
Une décision logique, quand on sait les ravages qu’ont créé les deux failles de sécurité successives découvertes dans ce plugin, d’une part, et surtout qu’il ne sert plus à rien aujourd’hui !
Les fonctions de gestion des images de WordPress font exactement la même chose que TimThumb
Ben Gillbank, le co-auteur de TimThumb avec Darren Hoyt l’explique lui-même : entre l’époque où il a développé son script et 2014, la gestion des images WordPress s’est suffisamment améliorée pour le rendre techniquement totalement inutile.
La présence de TimThumb dans un thème ou un plugin prouve que son auteur est une feignasse ^^ , qu’il ne met pas son framework à jour et qu’il n’utilise pas au maximum les fonctions de WordPress.
La fonction principale de TimThumb était, en effet, de permettre d’afficher, via un script de redimensionnement automatique, n’importe quelle taille d’image dans un thème, n’importe où. Le problème de base : l’accès en chmod 777 aux fichiers, dont avec un niveau de sécurité totalement insuffisant, puisque, via un script, n’importe quel internaute pouvait modifier les fichiers sur le site. (Et à partir de là, envoyer un script malicieux , etc…).
La fonction add_image_size , introduite dans la version 2.9 permet en effet de définir dans WordPress n’importe quelle taille d’image supplémentaire, en plus des trois “de base” (Réglages, Média, Vignette, Moyenne et Grande).
A partir de là, le redimensionnement des images n’avait plus besoin d’être fait via un script externe et TimThumb perdait toute son utilité.
Oui mais les images déjà existantes ?
Des plugins permettent de redimensionner des images déjà uploadées dans la bibliothèque des médias. Je préfère Force Regenerate Thumbnail qui, en plus de créer les nouvelles tailles d’images, supprime les anciennes. (Je l’avais d’ailleurs listé dans ma liste de plugins indispensables pour gérer les medias).
CHMOD késako ?
On m’a gentiment reproché de faire des articles parfois trop techniques. Le “CHMOD” est une notion essentielle pour sécuriser son site web, c’est une abbréviation pour “Change Mode”, qui indique qui est autorisé, au niveau serveur (donc Apache), à lire, exécuter et modifier des fichiers.
Pour comprendre, on a trois niveaux d’utilisateurs sur un serveur Apache :
- le propriétaire d’un fichier, qui a habituellement tous les droits dessus. Le propriétaire est un “user”, lequel “user” peut-être un script, ou un processus. En clair, les fichiers d’un site WordPress peuvent être “possédé” par le script qui les a créé (ce sera le cas quand un plugin créé un fichier, comme un cache), ou par le “user” ftp (en cas de téléchargement) ou n’importe quel type d’utilisateur défini au niveau du serveur.
- le groupe d’utilisateur ; on peut, toujours dans la configuration serveur, décider de grouper ensemble les “propriétaires script” et “ftp”.
- tous les autres, donc, entre autres, les “machins externes” et les hacks.
La manipulation exacte pour voir le CHMOD dépend du logiciel FTP choisi, mais, en gros, c’est toujours un clic droit, et ensuite choisir l’élément de menu “Propriétés”, “Autorisation” ou même “CHMOD”
Voilà comment se présente la fenêtre de gestion des autorisations dans mon logiciel FTP (SmartFTP) pour trois CHMOD ou niveaux de permissions différents :
Différents CHMOD pour un fichier
(A l’origine, le fichier en question, un des fichiers du core de WordPress, est en CHMOD 644)
C’est très simple.
A chaque niveau d’autorisation correspond un chiffre : 4 pour “Lire”, 6 pour “Ecrire” et 7 pour “Exécuter”. (Si aucune case n’est cochée on aura un 0)
Le premier chiffre est pour le propriétaire, le second pour le groupe et le troisième pour les autres.
Donc tout CHMOD qui se termine par autre chose que 0, 4 ou 5 [edit, rajouté] est dangereux.
Si un plugin exige un CHMOD 777 sur certains répertoires, vous oubliez, vous le désactivez, vous le supprimez.
C’était le cas de TimThumb, mais c’est toujours le cas de certains plugins de cache. C’est une des raisons pour lesquelles je préfère l’excellent WP Rocket.
Comment identifier un plugin ou un thème qui demande un CHMOD dangereux ?
Plusieurs possibilités :
- tout simplement poser la question, en particulier sur ThemeForest ; en anglais ça donne “before I buy it, I’d like to know if your plugin / theme requires any file or repertory in CHMOD 777 in order to function properly ?” (parce que quand c’est le cas, le développeur le sait)
- sur tout ce qui est gratuit, faire une recherche dans le répertoire contenu le thème ou le plugin, pour la chaîne “777”. Notepad++ est un utilitaire gratuit, très utile, qui permet de faire des recherches sur un ensemble de fichiers.
Et si la réponse est positive, je radote, je sais, mais c’est important… fuyez !
Pour la petite histoire, et en conclusion, Ben Gillbank et Darren Hoyt sont deux développeurs qui ont énormément contribué à WordPress. En plus de TimThumb, ils ont créé deux thèmes que j’ai beaucoup aimé, et que j’utilise toujours sur certains sites, Regulus et Mimbo. Sans mise à jour depuis des années, mais bien codés, au plus près des standards, la recette pour “tenir”.
(L’image qui illustre cet article est un montage de la photo de cimetière sous licence CC BY Tim Cheerman-Chase, du pouce de César sous licence CC BY NC de Lisa et de sorcière sous licence CC BY NC SA de Leo Reynolds).
Désolé mais un CHMOD 0777 ou 0755 sur un dossier ne pose aucun problème de sécurité. Et un CHMOD qui se termine par 4 (typiquement 0644) c’est valable pour les fichiers, pas pour les dossiers. La propriété “exécuter” sur les dossiers est quasiment tout le temps obligatoire (ça correspond simplement à pouvoir lister le contenu du dossier).
Si un script à besoin de stocker des fichiers (cache, images, etc) dans un dossier, c’est normal qu’il ait les droits en lecture/écriture/exécution dessus.
C’est simplement ridicule de dire :
“Donc tout CHMOD qui se termine par autre chose que 0 ou 4 est dangereux.
Si un plugin exige un CHMOD 777 sur certains répertoires, vous oubliez, vous le désactivez, vous le supprimez.”
Add_image_size à lui tout seul ne remplace pas TimThumb car les deux ne font pas la même chose : Add_image_size fait que pour chaque image uploadée wordpress crée une variante de plus de l’image, si la même image est affichée dans 10 formats, ça fait 10 images à générer alors que les 10 formats ne sont pas toujours utilisés, il s’agit en plus d’une génération au moment de l’upload.
TimThumb créait à la volée des images à un format quelconque, rien à voir avec les formats d’image de wordpress et en plus il disposait d’un cache pour éviter de trop solliciter le serveur.
TimThumb fournissait aussi divers filtres.
Quelque chose qui remplace TimThumb c’est par exemple BFIThumb : https://github.com/bfintal/bfi_thumb
+ 1 avec JB sur le CHMOD, c’est un peu approximatif (déjà chmod est une commande *nix qui manipule les droits sur le système de fichiers, c’est ce système de fichiers qui possède des utilisateurs et des types d’accès. Ensuite le 777 n’est pas une faille de sécurité béante, il est à éviter mais certains serveur web mal configurés ne laissent pas d’autres choix, ne serait-ce que pour uploader un fichier via wordpress. Et surtout pourquoi faire des raccourcis quand le codex explique tout cela clairement et en détail ? http://codex.wordpress.org/fr:Modifier_les_Permissions_sur_les_Fichiers :)
et pour les paranoiaques : http://codex.wordpress.org/Hardening_WordPress
Sauf que les images générées ne sont pas un vrai problème – un coup de Force Regenerate Thumbnail nettoie tout ça, le serveur n’est sollicité qu’au moment de l’upload de l’image, pas pendant la visite. Le gros avantage c’est clairement des miniatures gérées par WP et non pas par un script extérieur – on a vu ce que ça donnait. Dans un moteur comme WP il faut privilégier à tout prix les solutions internes aux externes. Enfin, un avantage certain des miniatures WP sur TimThumb (et quand je dis certain, c’est en fait un avantage massue): comme c’est WP qui gère la miniature, on peut PRÉCISÉMENT la redécouper comme on le désire avec un plugin genre Crop Thumbnail. Ce qui est impossible avec TimThumb (ah zut, la miniature montre la cravate du boss et pas son visage, c’est trop bête. Je vais dire au boss que c’est le script, il va rien dire). Rien que cette possibilité rajoute un camion de terre sur la tombe de TimThumb.
Je sens qu’un joli débat est sur le point d’éclater. La dangerosité des autorisations semble – pour ce que j’en ai lu – de la façon dont le serveur est configuré. Il semblerait par exemple que 777 soit obligé dans beaucoup de cas chez Infomaniak.
Je dis ça, j’y connais rien :-)
En ce qui concerne le CHMOD, comme vous avez pu le remarquer, c’est de la vulgarisation :) Voilà donc pourquoi faire des raccourcis (ah là la, le Meunier, son fils et l’âne, trop blog est trop compliqué, pas assez simple, trop simple, trop raccourci, trop détaillé… :D )
J’ai corrigé la formulation qui était effectivement erronée pour la “fin”, “tout CHMOD qui se termine par 7 est dangereux”. (désolée, il était 5 heures du matin, j’ai un peu trop résumé).
et bien que je sois opposée, en général, aux solutions simples, la règle de base “jamais de 777” est claire et facile. Aucun de mes blogs WP n’a de répertoire / fichier en 777 (à l’exception des caches, par lesquels justement, j’ai déjà eu des problèmes), et ils s’en portent très bien. Ma règle est peut-être ridicule, mais jusqu’à maintenant, en sept ans de blog :D les 4 règles de sécurité de base que je me suis imposées, sans plugin wordfence ou autre m’ont évité beaucoup d’emmerdes.
Je suis prête à accueillir un article invité d’un expert qui puisse expliquer, pour chacun des grands hébergeurs mutualisés, quelles sont les procédures de sécurité et les CHMOD acceptables sur quoi ou qu’est-ce, de façon claire et compréhensible. Et si le serveur est mal configuré, sur un mutualisé, ça laisse présager de nombreux autres problèmes, donc changer de serveur… (sur un VPS ou autre, changer la config…)
Parce que si on ouvre une porte pour pallier un problème, le problème est toujours là, ET en plus la porte est ouverte !
Bien évidemment, TimThumb et add_image_size ne fonctionnent pas de façon identique. Mais tant qu’à utiliser un script, autant utiliser Photon, qui fait partie de JetPack et qui utilise les services de WordPress…. j’aurais tendance à plus leur faire confiance qu’à un enième Timthumb-like-script
À remarquer qu’un plugin le fait de manière intéressante – création à la volée de la miniature: https://wordpress.org/plugins/wp-performance-pack/
Je l’ai chroniqué sans parler du tout de cette possibilité parce que sur le moment je n’y avais rien compris. Mais j’ignore s’il utilise les fonctions de WP pour le redimensionnement (je vais poser la question, tiens).
Je ne vais pas parler CHMOD, je serais bien incapable d’apporter quoi que ce soit de constructif sur la question, mais j’avoue que cette disparition de Timthumb me fait “quelque chose”. C’est un des premiers scripts populaires que j’ai découverts quand je me suis réellement intéressé au monde de la création de sites web et plus particulièrement via WordPress, donc dans mon esprit Timthumb arrive tout en faut dans la liste de ce qui a marqué mes débuts avec ce CMS.
Je n’ai pas eu la malchance de subir un piratage à cause de lui, j’utilisais des thèmes WooThemes à l’époque et ils avaient été pas mal réactifs lorsque les failles ont commencé à être exploitées, donc j’imagine que ça m’avait sauvé. et que dans le cas contraire j’aurais peut-être une dent contre le développeur, mais…
Bref, pour moi c’est certes une bonne nouvelle. Mais avec un petit pincement au cœur. Je suis sûr que je ne suis pas le seul dans ce cas.