Si vous avez un serveur Mastodon qui traine quelque part, vous devez le mettre à jour au plus vite, en version 3.5.9, 4.0.5 ou 4.1.3 selon votre branche.
Ces versions corrigent quatre failles :
- https://nvd.nist.gov/vuln/detail/CVE-2023-36462 de sévérité 5.4 (ça va encore) ;
- https://nvd.nist.gov/vuln/detail/CVE-2023-36461 de sévérité 7.5 (ça commence à pouvoir poser problème) ;
- https://nvd.nist.gov/vuln/detail/CVE-2023-36459 de sévérité 9.3 (argh) ;
- Mais surtout https://nvd.nist.gov/vuln/detail/CVE-2023-36460 de sévérité 9.9 qui permet de faire du déni de service ou de l’exécution de code arbitraire, à distance, en envoyant un simple toot à votre instance. Oups. Elle se base sur un assez classique media type spoofing.
Le problème est d’autant plus grave que les instances Mastodon sont référencées de manière publique avec leur numéro de version, ce qui simplifie la vie d’éventuels attaquants.
Ce journal est placé sous licence CC-0 1.0.
# Quelques remarques
Posté par Misc (site web personnel) . Évalué à 10.
Le numéro de version public ne va pas changer grand chose quand la faille est public, quelqu'un va tenter et basta. Savoir ce qui tourne est important si tu veux rester discret, mais la, ça va sans doute pas être le cas. J'ai encore vu ce matin qu'on a tenter un exploit wordpress sur un site statique que je gère.
Pour CVE-2023-36461, même avec 7.5, ça va juste bloquer le serveur. C'est chiant, mais je m'affolerais pas.
CVE-2023-36459, c'est une xss et qui semble impliquer un click de quelqu'un (genre, soit avoir une personne qui retoot le message, soit quelqu'un qui fait le site web et le poste). C'est chiant aussi, mais je pense que les divers navigateurs bloquent aussi pas mal de xss de nos jours (je crois). Et surtout, ça laisse des traces.
Le dernier CVE-2023-36460, je pense que ça nécessite aussi une faille dans ImageMagick en plus, non ? Je ne crois pas qu'on puisse avoir de l'execution de code directement en lancant ImageMagick.
Du coup, faut mettre à jour par bonne pratique, mais est ce que j'ai loupé des choses dans les failles annoncées ?
[^] # Re: Quelques remarques
Posté par paulez (site web personnel) . Évalué à 2.
Avec CVE-2023-36460 si tu peux écrire un fichier à un chemin arbitraire, tu peux potentiellement remplacer un exécutable (ou simplement un script PHP) et donc exécuter du code arbitraire par ce biais.
[^] # Re: Quelques remarques
Posté par Misc (site web personnel) . Évalué à 4.
Ce qui revient à avoir une faille arbitraire dans ImageMagick, non ?
Le patch semble juste empêcher de faire passer un média arbitraire à ImageMagick.
Je vois bien comment ça pourrait poser probléme parce qu'ImageMagick a régulièrement des soucis (et donc, suffit de passer un fichier vérolé dans un format pourri, et voila), mais en pratique, quel attaque possible ne s'appuie pas sur une faille d'ImageMagick (et je compte le fait d'avoir un write arbitraire d'IM comm une faille d'IM ) ?
[^] # Re: Quelques remarques
Posté par paulez (site web personnel) . Évalué à 1.
J'ai du mal à comprendre ce que fait le patch exactement, mais si j'en crois le test qui est ajouté il corrige le comportement dans le cas d'un fichier mp3 qui embarquerait un "cover art". Je suppose un mix d'erreur de validation qui permettrait d'extraire des données à partir d'un fichier corrompu (peut-être des métadonnées dans un fichier mp3 déguisées en covert art pour en extraire le contenu à un chemin spécifique).
[^] # Re: Quelques remarques
Posté par barmic 🦦 . Évalué à 2.
Après il n'est pas rare qu'une attaque utilise s'appuie sur plusieurs problèmes. Une exécution de code arbitraire peu être suivi d'une élévation de privilège par exemple.
Je ne vois pas où tu veux en venir ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Quelques remarques
Posté par barmic 🦦 . Évalué à 5.
En regardant le patch c'est extrêmement critique en fait. Ils filtres les coders acceptables pour imagemagick. De ce que j'en comprends c'est une forme de préfixe qui permet à imagemagick de faire un peu de magie. Ça a l'air de permettre de pointer une url (c'est parti l'attaque par rebond) et de faire des captures d'écrans de fenêtres sous x11 (et j'imagine un tas d'autres choses). Donc avec ou sans bug d'imagemagick ça peu poser des problèmes.
Je vois aussi une limitation de la taille des fichiers qu'on lui transmets et un timeout, j'imagine pour éviter un DOS bête et méchant.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Quelques remarques
Posté par Misc (site web personnel) . Évalué à 3.
Si je comprends bien, tu parles de la policy (fichier policy.xml), mais justement, c'est ça que je pige pas.
Je m'attends à ce que ImageMagick, sauf faille de sécurité, soit utilisable sans avoir de fichier policy.xml. Avoir une sandbox est une bonne chose, mais on parle d'ImageMagick, si le logiciel sans fichier policy.xml est troué par défaut, c'est un souci.
Donc quand j'examine le patch en détail, il touche 8 fichiers.
On peut retirer les tests et le mp3 de test qui va avec, ainsi que la modif de application.rb qui est la pour charger un autre fichier.
Il reste 5 modifs. Une est le fichier policy.xml, une pour utiliser le fichier en question. On va mettre ça de coté.
Il reste donc les 3 derniers bouts, à savoir:
- une classe MediaTypeSpoofDetectorExtensions
- une modif de transcoder.rb
- une modif de attachmentable.rb
De ce que je comprends, la derniére modif change juste la validation pour utiliser le type MediaTypeSpoofDetectorExtensions, ce qui permet de ne pas laisser passer certains mp3 mal détectés. C'est curieux d'avoir 2 libs pour trouver le type mime, mais on.
Et il reste que transcoder.rb, qui va échouer si on ne peux pas faire de transcoding au lieu de laisser passer ça à ImageMagick.
Donc on a:
- une meilleur vérification des fichiers transcodés (notament les mp3)
- on arrête le traitement si le transcodage échoue (mais quel traitement ? que fait mastodon à part du retaillage ?)
- une policy qui va bloquer le traitement de tout sauf les fichiers d'images, et qui va interdire le module URL.
Mais donc, les modules en questions, est ce que ImageMagick va les appeler sans demande explicite de l'utilisateur ?
Les fonctions des coders (plutôt des encodeurs et décodeurs) implique aussi de demander de les utiliser. Si je dit "transforme ce jepg en pdf", ça va appeler le coder pdf. Mais ça se fait pas sans une demande explicite via la CLI. Donc je pige pas, surtout que ImageMagick n'est pas directement appelé par le code, mais via paperclip (de ce que je comprends), donc il y a déja une couche d'astraction qu'on peut supposer sur (ou qui n'est pas documenté comme non sure).
Est ce que passer un fichier spécifique à ImageMagick dans sa config par défaut va être un souci de sécurité, ou est ce qu'il s'agit d'une faille dans l'instance si il y a une faille dans IM (auquel cas, il y a pas d'urgence sauf timing de merde, mais je vois personne dire "faut mettre à jour IM tout de suite")
[^] # Re: Quelques remarques
Posté par barmic 🦦 . Évalué à 3.
Non ça n'est pas une question d'encodage. Tu as par exemple un coder "https" qui permet d'écrire ça :
C'est une fonctionnalité pour imagemagick, mais pour un logiciel comme mastodon il faut qu'il évite les injections potentielles. Tout comme ça peut être normal de lui demander des traitement qui sont CPU intensif et prennent 100% de ton CPU pendant plusieurs heures, mais c'est pas souhaitable pour mastodon.
Tu as pleins de façons d'utiliser imagemagick il ne peut pas deviner ce qui est normal ou non pour toi. C'est pour ça qu'ils ont ce système de policy et tu pourra trouver quelques exemples de pourquoi est-ce qu'il peut être intéressant de s'en servir dans leur documentation.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Quelques remarques
Posté par Misc (site web personnel) . Évalué à 3.
Mais ton example, c'est un souci si l'attaquant peut choisir le nom entier du fichier, mais est ce le cas ? Et est ce qu'on peut vraiment mettre une URL complète dans un message activitypub sans que ça contredise la spec ?
Car si c'est le cas (eg, que ke nom d'un attachement est non filtré sous le controle complet d'un attaquant) alors il y a le cas de ffmpeg:
https://github.com/mastodon/mastodon/blob/d0f00206dc115cb3a21281b532c59a166c21ce71/lib/paperclip/transcoder.rb
ffmpeg qui est dans la même catégorie que magick en terme de risque: "couteau suisse, parse des tonnes de format, écrit en C, va lire des trucs de l'internet".
ffmpeg -i https://foo.example.org/image.jpg est valide. Du coup, si la spec permet d'avoir un fichier avec un nom qui commence par http pour les attachements, il faut filtrer plus que magick, mais ça n'est pas adressé.
Et comme tu le dit, magick peut utiliser le coder "screenshot" ou "x" pour taper ailleurs que dans les fichiers, et sauf erreur de ma part, ça n'est pas filtré (ensuite, c'est sans doute non fonctionnel).
J'ai testé la policy via https://imagemagick-secevaluator.doyensec.com/ et il y a pas mal de manque. Par exemple, pas de limite de mémoire, de disque, rien.
Donc non, je tente vraiment de comprendre mais pour ça, il faut visiblement plus que le patch, car je ne trouve pas le souci en pratique (en partie car le patch fait 4 choses différentes).
[^] # Re: Quelques remarques
Posté par barmic 🦦 . Évalué à 2.
Le patch indique lui-même qu'il est incomplet et qu'il faudra améliorer tout ça.
Pour le reste je ne connais pas mastodon, je ne sais pas si l'utilisateur a un contrôle complet du paramètre fourni, je ne sais pas s'il y a des coders autre qu'au début du chemin (par exemple pour éviter de remonter le path, pour gérer des globings, etc), je ne sais pas si ffmpeg n'a pas déjà l'arsenal nécessaire,…
Je doute que tu trouve cette réponse ailleurs que dans les canaux de diffusions dédiés du projet mastodon.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.