Sécurité ImageMagick

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

Travaillez-vous dans une entreprise de cybersécurité ? Voulez-vous voir votre entreprise annoncée dans HackTricks ? ou voulez-vous avoir accès à la dernière version de PEASS ou télécharger HackTricks en PDF ? Consultez les PLANS D'ABONNEMENT!
Découvrez The PEASS Family, notre collection exclusive de NFTs
Obtenez le swag officiel PEASS & HackTricks
Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez moi sur Twitter 🐦@carlospolopm.
Partagez vos astuces de piratage en soumettant des PR au repo hacktricks et au repo hacktricks-cloud.

Ce post a été copié depuis https://blog.doyensec.com/2023/01/10/imagemagick-security-policy-evaluator.html****

Lors de nos audits, nous tombons parfois sur des fichiers de configuration de la politique de sécurité d'ImageMagick (policy.xml), utiles pour limiter le comportement par défaut et les ressources consommées par la bibliothèque. Dans la nature, ces fichiers contiennent souvent une pléthore de recommandations culturelles de cargaison provenant d'Internet. Cela se produit normalement pour deux raisons :

Ses options sont généralement décrites sur la page de documentation en ligne de la bibliothèque, sans aucune ventilation claire de ce que chaque directive de sécurité autorisée par la politique réglemente. Bien que la complexité architecturale et la granularité des options définissables par la politique soient les principaux obstacles pour un novice, la base de connaissances correspondante pourrait être plus accueillante. Par défaut, ImageMagick est livré avec une politique non restreinte qui doit être ajustée par les développeurs en fonction de leur utilisation. Selon la documentation, « cela offre une utilité maximale pour les installations ImageMagick qui s'exécutent dans un environnement sandboxé, peut-être dans une instance Docker, ou derrière un pare-feu où les risques de sécurité sont considérablement réduits par rapport à un site Web public. » Une politique stricte et sécurisée est également disponible, cependant comme noté dans le passé, elle n'est pas toujours bien configurée.
ImageMagick prend en charge plus de 100 formats de fichiers majeurs (sans inclure les sous-formats) types de formats d'image. Les vulnérabilités infâmes affectant la bibliothèque au fil des ans ont produit un certain nombre de correctifs de sécurité urgents et de contournements impliquant l'ajout d'éléments de politique excluant les formats et fonctionnalités affectés (ImageTragick en 2016, RCE de @taviso via GhostScript en 2018, injection de shell de @insertScript via le mot de passe PDF en 2020, @alexisdanizan en 2021).

Vers des politiques plus sûres

Dans cette optique, nous avons décidé d'étudier les effets de toutes les options acceptées par le parseur de politique de sécurité d'ImageMagick et d'écrire un outil pour aider les développeurs et les équipes de sécurité à concevoir et à auditer ces fichiers. En raison du nombre d'options disponibles et de la nécessité de refuser explicitement tous les paramètres non sécurisés, il s'agit généralement d'une tâche manuelle, qui peut ne pas identifier les contournements subtils qui sapent la force d'une politique. Il est également facile de définir des politiques qui semblent fonctionner, mais qui n'offrent aucun avantage réel en termes de sécurité. Les vérifications de l'outil sont basées sur nos recherches visant à aider les développeurs à renforcer leurs politiques et à améliorer la sécurité de leurs applications, afin de s'assurer que les politiques offrent un avantage de sécurité significatif et ne peuvent pas être subverties par des attaquants.

L'outil peut être trouvé à imagemagick-secevaluator.doyensec.com/.

Approche de liste blanche vs liste noire

Un certain nombre de politiques apparemment sécurisées peuvent être trouvées en ligne, spécifiant une liste de codeurs non sécurisés similaires à :

  ...
  <policy domain="coder" rights="none" pattern="EPHEMERAL" />
  <policy domain="coder" rights="none" pattern="EPI" />
  <policy domain="coder" rights="none" pattern="EPS" />
  <policy domain="coder" rights="none" pattern="MSL" />
  <policy domain="coder" rights="none" pattern="MVG" />
  <policy domain="coder" rights="none" pattern="PDF" />
  <policy domain="coder" rights="none" pattern="PLT" />
  <policy domain="coder" rights="none" pattern="PS" />
  <policy domain="coder" rights="none" pattern="PS2" />
  <policy domain="coder" rights="none" pattern="PS3" />
  <policy domain="coder" rights="none" pattern="SHOW" />
  <policy domain="coder" rights="none" pattern="TEXT" />
  <policy domain="coder" rights="none" pattern="WIN" />
  <policy domain="coder" rights="none" pattern="XPS" />
  ...

Dans ImageMagick 6.9.7-7, un changement non répertorié a été effectué. L'analyseur de politique a changé de comportement en passant de l'interdiction de l'utilisation d'un codeur s'il y avait au moins une règle de permission none dans la politique à la prise en compte de la dernière règle correspondante dans la politique pour le codeur. Cela signifie qu'il est possible d'adopter une approche de liste blanche dans les politiques modernes, en refusant d'abord tous les droits des codeurs et en activant ceux qui ont été approuvés. Une politique plus sécurisée spécifierait :

  ...
  <policy domain="delegate" rights="none" pattern="*" />
  <policy domain="coder" rights="none" pattern="*" />
  <policy domain="coder" rights="read | write" pattern="{GIF,JPEG,PNG,WEBP}" />
  ...

Sensibilité à la casse

Considérez la directive suivante:

  ...
  <policy domain="coder" rights="none" pattern="ephemeral,epi,eps,msl,mvg,pdf,plt,ps,ps2,ps3,show,text,win,xps" />
  ...

Avec cela, les conversions seront toujours autorisées, car les modèles de politique sont sensibles à la casse. Les codeurs et les modules doivent toujours être en majuscules dans la politique (par exemple, "EPS" et non "eps").

Limites de ressources

La création d'un déni de service dans ImageMagick est assez facile à réaliser. Pour obtenir un nouvel ensemble de charges utiles, il est pratique de rechercher des mots clés tels que "oom" dans les problèmes récemment ouverts signalés sur le référentiel Github de la bibliothèque. Cela pose un problème car une instance ImageMagick acceptant des entrées potentiellement malveillantes (ce qui est souvent le cas) sera toujours susceptible d'être exploitée. Pour cette raison, l'outil signale également si des limites raisonnables ne sont pas explicitement définies par la politique.

Fragmentation de la politique

Une fois qu'une politique est définie, il est important de s'assurer que le fichier de politique est en vigueur. Les packages ImageMagick inclus dans la distribution ou installés en tant que dépendances via plusieurs gestionnaires de packages peuvent spécifier des politiques différentes qui interfèrent les unes avec les autres. Une recherche rapide avec find sur votre machine locale identifiera plusieurs occurrences de fichiers policy.xml:

$ find / -iname policy.xml

# Example output on macOS
/usr/local/etc/ImageMagick-7/policy.xml
/usr/local/Cellar/imagemagick@6/6.9.12-60/etc/ImageMagick-6/policy.xml
/usr/local/Cellar/imagemagick@6/6.9.12-60/share/doc/ImageMagick-6/www/source/policy.xml
/usr/local/Cellar/imagemagick/7.1.0-45/etc/ImageMagick-7/policy.xml
/usr/local/Cellar/imagemagick/7.1.0-45/share/doc/ImageMagick-7/www/source/policy.xml

# Example output on Ubuntu
/usr/local/etc/ImageMagick-7/policy.xml
/usr/local/share/doc/ImageMagick-7/www/source/policy.xml
/opt/ImageMagick-7.0.11-5/config/policy.xml
/opt/ImageMagick-7.0.11-5/www/source/policy.xml

Les politiques peuvent également être configurées en utilisant l'argument CLI -limit, les méthodes de l'API MagickCore, ou avec des variables d'environnement.

Une politique restrictive de départ

En partant de la politique la plus restrictive décrite dans la documentation officielle, nous avons conçu une politique restrictive regroupant toutes nos observations :

<policymap xmlns="">
  <policy domain="resource" name="temporary-path" value="/mnt/magick-conversions-with-restrictive-permissions"/> <!-- the location should only be accessible to the low-privileged user running ImageMagick -->
  <policy domain="resource" name="memory" value="256MiB"/>
  <policy domain="resource" name="list-length" value="32"/>
  <policy domain="resource" name="width" value="8KP"/>
  <policy domain="resource" name="height" value="8KP"/>
  <policy domain="resource" name="map" value="512MiB"/>
  <policy domain="resource" name="area" value="16KP"/>
  <policy domain="resource" name="disk" value="1GiB"/>
  <policy domain="resource" name="file" value="768"/>
  <policy domain="resource" name="thread" value="2"/>
  <policy domain="resource" name="time" value="10"/>
  <policy domain="module" rights="none" pattern="*" /> 
  <policy domain="delegate" rights="none" pattern="*" />
  <policy domain="coder" rights="none" pattern="*" /> 
  <policy domain="coder" rights="write" pattern="{PNG,JPG,JPEG}" /> <!-- your restricted set of acceptable formats, set your rights needs -->
  <policy domain="filter" rights="none" pattern="*" />
  <policy domain="path" rights="none" pattern="@*"/>
  <policy domain="cache" name="memory-map" value="anonymous"/>
  <policy domain="cache" name="synchronize" value="true"/>
  <!-- <policy domain="cache" name="shared-secret" value="my-secret-passphrase" stealth="True"/> Only needed for distributed pixel cache spanning multiple servers -->
  <policy domain="system" name="shred" value="2"/>
  <policy domain="system" name="max-memory-request" value="256MiB"/>
  <policy domain="resource" name="throttle" value="1"/> <!-- Periodically yield the CPU for at least the time specified in ms -->
  <policy xmlns="" domain="system" name="precision" value="6"/>
</policymap>

Vous pouvez vérifier qu'une politique de sécurité est active en utilisant la commande identify:

identify -list policy
Path: ImageMagick/policy.xml
...

Vous pouvez également jouer avec la politique ci-dessus en utilisant notre outil d'évaluation tout en développant une politique sur mesure.