C'est un concours ou bien ?

Zone de dépôt de media

Depuis deux semaines il ne se passe pas une journée sans que je reçoive un mail me signalant une faille de sécurité dans Dotclear. Tous ces mails commencent invariablement par : « If you upload a malicious file in the … », la suite pouvant être une archive de thème ou de plugin, une archive de langue, un fichier média, … La liste est longue.

Dernièrement c’était plus précisément dans le cas où on upload un fichier se finissant par .php. (avec le . final), dans ce cas c’est exécutable comme un script PHP, ou encore le cas des fichiers se finissant par .<quelque-chose>html, ou bien encore …

Bref on en finit plus !

J’en avais déjà causé ici-même en octobre dernier et rien n’a réellement changé dans Dotclear depuis !

Certes on filtre les extensions avec un réglage stocké dans les paramètres du blog, voir le paramètre media_exclusion de la section system dans Réglages système → about:config qui est normalement (en tout cas jusqu’à la 2.11.2) initialisé avec une belle expression régulière :

/.(phps?|pht(ml)?|phl|s?html?|js|htaccess)[0-9]*$/i

Mais ça ne protège pas énormément, c’est clair. D’ailleurs si quelqu’un a la definitive and ultimate premium regexp, je la prends avec plaisir !

Dépôt d'un média refusé

Pour ma part, j’ai un peu exploré ce qui se faisait ici et là et j’ai trouvé quelques pistes (plus ou moins applicables) :

  1. Ne pas permettre à l’utilisateur de définir le nom du fichier déposé et utiliser en lieu et place un nom de fichier aléatoire (ou déterminé) qui sera servi ensuite avec le mime-type correspondant tout en stockant dans la base de données le nom d’origine.
  2. Contrôler le contenu du fichier déposé, éventuellement en modifiant son entête pour un fichier de type non reconnu. Un fichier image ou qui se prétend l’être, peut être contrôlé avec une simple fonction qui détermine les dimensions de l’image ; dans le cas où ça échoue, c’est probablement autre chose.
  3. Stocker les fichiers déposés en dehors de ce qui est servi par le serveur web et mettre en place un système qui sert ces fichiers à la demande.
  4. Interdire purement et simplement le dépôt de fichier ; ça c’est facile et c’est déjà possible dans Dotclear avec une regexp qui interdit tout !

Bref, y’a de quoi faire !

Sauf que (je reprends les propositions ci-dessus dans l’ordre) :

  1. Ça revient à réécrire le gestionnaire de média et de trouver un moyen de modifier toutes les URLs des médias déjà publiés dans des billets ou autre.
  2. Pour les images, ça peut, mais pour le reste, ça va être compliqué et risque de produire un code assez monstrueux.
  3. Mettre le dossier public en dehors du serveur web c’est toujours possible, sauf que du coup va falloir un système pour les récupérer. Et c’est un peu le même problème que la 1re, va éventuellement falloir assurer le remplacement des URLs des médias déjà publiés.
  4. No comment :-)

Bien sûr, toutes ces failles nécessitent d’avoir un accès à l’administration (personne ne dit comment), et les droits pour déposer des fichiers.

Mais revenons à mon sujet initial.

J’ai l’impression qu’il y a une sorte de concours dans la recherche de faille de type XSS concernant les logiciels libres — ou alors c’est seulement avec Dotclear ? Wordpress de son côté utilise un contrôle inversé, une série d’extension (mime-type) est autorisée, le reste est refusé, mais ça n’empêche pas de déposer des trucs potentiellement dangereux dans un .html par exemple.

Parce qu’en définitive on peut, à l’envi et à l’infini, faire varier les potentielles extensions potentiellement maléfiques qu’on pourrait utiliser pour déposer des trucs dans Dotclear et générer ainsi des zilliards d’avis de vulnérabilité !

M’est avis, qu’il y a aussi à voir du côté du PEBKAC, et là, par contre, j’ai pas la moindre idée de la regexp qu’on pourrait utiliser !

Ajouter un commentaire

Les champs suivis d'un * sont obligatoires

Les commentaires peuvent être formatés en utilisant la syntaxe Markdown Extra.

Ajouter un rétrolien

URL de rétrolien : https://open-time.net/trackback/13158

Haut de page