jostaub/ghostscript-cve-2023-43115Un petit article avec des exemples pour comprendre CVE-2023-43115
Un petit article avec des exemples pour aider à comprendre CVE-2023-43115.
[!WARNING] J'ai écrit ceci principalement pour comprendre le problème et en apprendre davantage sur la cybersécurité. Il peut donc y avoir des erreurs.
Pour utiliser le périphérique IJS (Improved Inkjet Printing), Ghostscript doit lancer un serveur IJS. Cela se fait en utilisant le chemin spécifié dans le paramètre IjsServer. Le paramètre IjsServer peut être configuré pour référencer n'importe quel fichier dans le système de fichiers, et Ghostscript exécute ensuite ce fichier désigné. On voit facilement comment cela pourrait potentiellement être utilisé abusivement, par exemple en exécutant la commande ghostscript suivante pour afficher "hello world".
❯ gs -sDEVICE=ijs -sIjsServer="bash -c 'echo Hello World>&2'"
GPL Ghostscript 9.55.0 (2021-09-27)
Copyright (C) 2021 Artifex Software, Inc. All rights reserved.
This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY:
see the file COPYING for details.
Hello World
En soi, ce n'est pas si problématique puisque ce paramètre doit être fourni par l'utilisateur. Cependant, il est également possible de définir ce périphérique et le paramètre IJsServer dans un script postscript.
Voir par exemple attack_example_*.ps (exécutez avec gs FILENAME). Cela pourrait permettre à une attaque d'exécuter du code sur la machine qui exécute ce script. Mais ce problème est connu et officiellement documenté et pourrait être évité en définissant LockSafetyParams sur true.
Pour exploiter cette CVE alors que LockSafetyParams est activé, un attaquant aurait besoin d'un exploit fonctionnel pour modifier LockSafetyParams. Cependant, si un tel exploit est disponible, il pourrait y avoir un certain nombre d'autres vecteurs d'attaque possibles selon la version utilisée.
L'auteur du correctif, Ken Sharp, a qualifié la solution de sécurité LockSafetyParams mentionnée de « hacky » car elle est implémentée en postscript et donc vulnérable au code postscript. Cela a conduit à plusieurs problèmes de sécurité par le passé où il était possible d'écraser ce paramètre (voir par exemple l'article sur CVE-2018-19475 ). Le correctif change le mécanisme de protection qui empêche de définir le chemin IjsServer à partir de LockSaftyParams vers le nouveau paramètre -dSAFER, qui ne peut pas être affecté par le code postscript.
[!NOTE] La Documentation de la version vulnérable 9.55.0 indique déjà d'utiliser le paramètre -dSAFER, ce qui semble être une erreur de documentation.