murataydemir/aws-sam-cli-vulnerabilitiesIssue with AWS SAM CLI (CVE-2025-3047, CVE-2025-3048)
Ce README fournit une analyse détaillée de deux vulnérabilités de sécurité découvertes dans l'interface de ligne de commande AWS Serverless Application Model (AWS SAM CLI) – CVE-2025-3047 et CVE-2025-3048 – ainsi que les problèmes et correctifs au niveau du code. Les deux vulnérabilités impliquent une gestion inappropriée des liens symboliques (symlinks) pendant le processus de construction à l'aide de conteneurs Docker. Chaque section ci-dessous couvre une CVE avec un résumé, le code affecté (avec des références au code source de SAM CLI), le correctif et la manière dont il résout le problème, ainsi que des conseils de remédiation.
Ces défauts impliquent une gestion inappropriée des liens symboliques (symlinks) pendant le processus sam build --use-container. Les deux problèmes affectent les environnements de développement locaux (ils n'impactent pas les services ou ressources AWS déployés), mais pourraient permettre un accès non autorisé aux fichiers sur la machine hôte en abusant de la façon dont AWS SAM CLI traite les symlinks. Il est fortement recommandé de mettre à niveau AWS SAM CLI vers les versions corrigées (1.133.0+ pour CVE-2025-3047, et 1.134.0+ pour CVE-2025-3048).
GHSA-px37-jpqx-97q9 est une vulnérabilité de contournement de chemin dans AWS SAM CLI <= v1.132.0 qui permettait un accès non autorisé aux fichiers sur la machine hôte lors de sam build --use-container. Lors de la construction d'une application sans serveur à l'intérieur d'un conteneur Docker, SAM CLI suivait les liens symboliques dans le projet par défaut. Un attaquant capable de placer un lien symbolique malveillant dans le projet (pointant vers un fichier sensible de l'hôte) pouvait exploiter les privilèges élevés du conteneur Docker pour que ce fichier soit monté dans le conteneur et copié vers un emplacement accessible à l'intérieur du conteneur. En pratique, cela signifiait que des fichiers privilégiés de l'hôte (à l'extérieur du répertoire du projet) pouvaient être lus et exfiltrés via le conteneur de construction. Le problème a été corrigé dans v1.133.0. (Pour préserver la compatibilité ascendante dans les cas légitimes, SAM CLI v1.133.0 a introduit un drapeau d'adhésion --mount-symlinks pour réactiver l'ancien comportement si nécessaire.)
Cause racine et composant affecté : Le problème central réside dans la manière dont AWS SAM CLI monte les répertoires du projet et leurs liens symboliques dans le conteneur Docker utilisé pour les constructions. Dans le code d'AWS SAM CLI (module samcli.local.docker.container), avant le correctif, tous les liens symboliques de premier niveau dans le répertoire du projet étaient automatiquement résolus et montés par liaison (bind mount) dans le conteneur avec les mêmes privilèges élevés que le processus du conteneur. Le conteneur s'exécute en tant que root par défaut, donc résoudre et monter un lien symbolique pointant vers un chemin sensible de l'hôte donnait accès à ce fichier au conteneur, ce qu'un utilisateur non privilégié de l'hôte n'aurait normalement pas. Le code vulnérable ne restreignait pas suffisamment les liens symboliques à suivre/monter.
Plus précisément, dans la fonction qui crée les volumes Docker à monter pour la construction, SAM CLI traitait inconditionnellement les liens symboliques comme des fichiers/répertoires réels à monter. La vulnérabilité résidait dans la logique d'orchestration des conteneurs de SAM CLI, spécifiquement dans la méthode Container.create de samcli/local/docker/container.py. Dans les versions vulnérables, cette méthode tentait toujours de résoudre et de monter les cibles des liens symboliques du projet dans le conteneur Docker, indépendamment du contexte. Le code problématique est présenté ci-dessous, de SAM CLI v1.132.0 :
# samcli/local/docker/container.py (v1.132.0 - extrait vulnérable)
if self._host_dir:
mount_mode = "rw,delegated" if self._mount_with_write else "ro,delegated"
LOG.info("Montage de %s en %s:%s, dans le conteneur d'exécution", self._host_dir, self._working_dir, mount_mode)
_volumes = {
self._host_dir: {
"bind": self._working_dir,
"mode": mount_mode,
},
**self._create_mapped_symlink_files(), # Résout et monte toujours les symlinks (vulnérable)
}
Dans le code ci-dessus, _create_mapped_symlink_files() recherche les liens symboliques dans le répertoire du projet et les prépare pour le montage. Étant donné que cela était inclus inconditionnellement, tous les liens symboliques (y compris ceux pointant à l'extérieur du projet) étaient montés dans le conteneur. (voir aws/aws-sam-cli#7865)
Le défaut ici est que lors d'un sam build --use-container, SAM CLI traite les liens symboliques comme des fichiers à monter dans le conteneur. Si un lien symbolique pointait, par exemple, vers /etc/shadow sur l'hôte, le conteneur Docker (qui pourrait s'exécuter avec des privilèges élevés) montait ce fichier par liaison. C'est un classique contournement de chemin basé sur les liens symboliques, entraînant une escalade de privilèges – des fichiers de l'hôte auxquels l'utilisateur n'aurait normalement pas accès pouvaient être lus par le conteneur puis se retrouver dans la sortie de la construction.
Correctif (code corrigé dans v1.133.0) : Le correctif introduit une notion de contexte de construction et désactive la résolution des liens symboliques pendant les constructions conteneurisées. Dans la version corrigée, Container.create prend un paramètre supplémentaire indiquant le contexte (BUILD vs INVOKE), et ne résout les liens symboliques que si le contexte est l'invocation (lors de l'exécution locale de fonctions), pas pendant les constructions. Voici le code corrigé de la version patchée :
# samcli/local/docker/container.py (v1.133.0+ - extrait corrigé)
if self._host_dir:
mount_mode = "rw,delegated" if self._mount_with_write else "ro,delegated"
LOG.info("Montage de %s en %s:%s, dans le conteneur d'exécution", self._host_dir, self._working_dir, mount_mode)
mapped_symlinks = self._create_mapped_symlink_files() if self._resolve_symlinks(context) else {}
_volumes = {
self._host_dir: {
"bind": self._working_dir,
"mode": mount_mode,
},
**mapped_symlinks, # Ne monte les symlinks que si le contexte l'autorise explicitement (pas en construction)
}
Dans le code corrigé, _create_mapped_symlink_files() est encapsulé derrière une vérification de contexte. La nouvelle énumération ContainerContext définit des contextes comme BUILD et INVOKE, et _resolve_symlinks(context) renvoie False pour le contexte de construction. Ainsi, mapped_symlinks sera un dictionnaire vide pendant les constructions, ce qui signifie qu'aucun lien symbolique n'est monté dans le conteneur par défaut.
Référence de la modification de code : Le correctif a été implémenté dans Pull Request#7865 (“fix: Resolve symlinks on local invoke only”) et publié dans le cadre de la v1.133.0. Le diff GitHub montre l'introduction de ContainerContext et de la logique de montage conditionnelle. En ne montant pas les cibles des liens symboliques pendant la construction, le conteneur n'a plus accès aux fichiers en dehors du répertoire du projet. (Si un utilisateur souhaite autoriser les liens symboliques vers des chemins de l'hôte, il doit désormais adhérer via le drapeau --mount-symlinks, ajouté suite à ce correctif.)
Comment le correctif résout le problème : Après le correctif, les liens symboliques dans le projet ne sont plus suivis pendant la phase de construction. Ils restent simplement des liens symboliques dans le conteneur (pointant vers des chemins qui ne seront pas montés) ou sont ignorés, plutôt que d'être remplacés par le contenu de leur cible. Cela ferme la brèche par laquelle un attaquant pouvait tromper le processus de construction pour copier des fichiers sensibles de l'hôte. En bref, la vue du conteneur de construction est désormais confinée au répertoire du projet lui-même (plus les volumes explicitement autorisés), éliminant l'escalade de privilèges involontaire.
Remédiation : Tous les utilisateurs doivent mettre à niveau vers AWS SAM CLI v1.133.0 ou ultérieur pour obtenir ce correctif. Après la mise à niveau, le comportement par défaut est sûr. Ce n'est que si vous faites explicitement confiance à votre projet et avez besoin de l'ancien comportement que vous devez utiliser sam build --use-container --mount-symlinks. Pour la plupart des développeurs, il est recommandé de laisser ce drapeau désactivé (par défaut) pour garantir que les liens symboliques ne peuvent pas sortir de l'espace de travail. C'est aussi une bonne pratique de vérifier tout lien symbolique dans vos projets pour s'assurer qu'il ne pointe pas vers des emplacements sensibles.
GHSA-pp64-wj43-xqcr est une vulnérabilité connexe affectant AWS SAM CLI <= v1.133.0 (corrigée dans v1.134.0). Une vulnérabilité dans le mise en cache des artefacts de construction d'AWS SAM CLI pourrait permettre à des fichiers sensibles de fuir du conteneur vers l'espace de travail de l'hôte après une construction. Si un projet incluait des liens symboliques, après avoir exécuté sam build --use-container, le contenu des cibles des liens symboliques était copié dans le répertoire de cache de construction local sous forme de fichiers ou dossiers normaux. En pratique, un développeur sans accès à certains fichiers de l'hôte pouvait y accéder car le contenu de ces fichiers se retrouvait dans le dossier de sortie de construction .aws-sam sur l'hôte. Par exemple, un lien symbolique dans le projet pointant vers /secret/config pouvait entraîner l'apparition du contenu réel de /secret/config dans le dossier .aws-sam/build du projet après la construction du conteneur, même si l'utilisateur ne pouvait pas lire /secret/config directement.
Cause racine et composant affecté : Le cœur de ce problème résidait dans la façon dont SAM CLI copiait les fichiers hors du conteneur (ou du processus de construction) dans le répertoire des artefacts de construction du projet local. La fonction responsable de la copie des fichiers se trouve dans samcli/lib/utils/osutils.py, spécifiquement l'utilitaire personnalisé copytree. Dans les versions vulnérables, cette fonction utilisait shutil.copy2 de Python sans spécifier follow_symlinks=False, qui par défaut suit les liens symboliques et copie le contenu des fichiers. L'extrait ci-dessous (de v1.133.0) montre la logique problématique :
# samcli/lib/utils/osutils.py (v1.133.0 - extrait vulnérable)
# ... à l'intérieur de osutils.copytree ...
else:
try:
shutil.copy2(new_source, new_destination) # follow_symlinks est True par défaut (vulnérable)
except OSError as e:
if e.errno != errno.EINVAL:
raise e
Ici, si new_source est un lien symbolique, shutil.copy2 résout le lien et copie le fichier cible vers new_destination. Il n'y avait aucun drapeau pour lui dire de préserver le lien. Ainsi, un lien symbolique vers un fichier sensible entraînait l'apparition du contenu de ce fichier dans le répertoire de destination. (voir aws/aws-sam-cli#7890)
En termes pratiques, imaginez que le processus de construction a créé un lien symbolique config -> /etc/secret-config (peut-être dans le cadre de l'empilement de dépendances ou comme vestige du scénario de CVE-2025-3047). Le code ci-dessus copiait le contenu de /etc/secret-config dans la sortie de construction locale sous le nom config. Un utilisateur local qui ne pouvait pas lire /etc/secret-config directement pouvait désormais simplement ouvrir le fichier sous .aws-sam/build/.../config et voir son contenu.
Correctif (code corrigé dans v1.134.0) : Le correctif était simple – préserver les liens symboliques au lieu de les suivre lors de la copie. Dans shutil de Python, cela se fait en passant follow_symlinks=False. Le code corrigé (v1.134.0) modifie l'appel de copie comme suit :
# samcli/lib/utils/osutils.py (v1.134.0 - extrait corrigé)
else:
try:
shutil.copy2(new_source, new_destination, follow_symlinks=False) # Ne pas suivre les symlinks (corrigé)
except OSError as e:
if e.errno != errno.EINVAL:
raise e
Avec follow_symlinks=False, si new_source est un lien symbolique, la fonction copie le lien lui-même plutôt que le fichier pointé. En d'autres termes, la sortie de construction contiendra un lien symbolique avec la même cible, au lieu d'un fichier réel avec le contenu de la cible.
Référence de la modification de code : La modification a été effectuée dans Pull Request#7890 (“fix: Keep symlinks when copying files after build”) et publiée dans v1.134.0. Le diff GitHub de cette PR confirme l'ajout du paramètre follow_symlinks=False à shutil.copy2, ainsi que la mise à jour des tests unitaires pour garantir que les symlinks sont préservés. La description de la PR note explicitement : “Les liens symboliques cesseront d'être transformés en copies des fichiers et conserveront leur statut de lien symbolique.” Cela signifie que les artefacts de construction contiendront des liens symboliques (qui référencent les chemins de fichiers originaux) au lieu de copies non autorisées des données du fichier.
Comment le correctif résout le problème : Après ce correctif, la copie de fichiers post-construction de SAM CLI ne fuit plus le contenu des fichiers. Si un lien symbolique a été créé pendant la construction, il restera un lien symbolique dans la sortie. L'utilisateur local n'obtiendra pas miraculeusement un accès en lecture au contenu de la cible – il verra simplement un lien symbolique qui pointe toujours vers le chemin d'origine. À moins que l'utilisateur n'ait déjà la permission de lire le fichier cible, le lien symbolique dans la sortie est inoffensif (il générera une erreur s'il est déréférencé sans accès approprié). Essentiellement, l'impact sur la confidentialité est atténué : les fichiers sensibles ne sont pas accidentellement matérialisés dans l'espace de travail de l'utilisateur. Ce correctif complète celui de CVE-2025-3047 : il empêche le conteneur de récupérer des fichiers de l'hôte via des liens symboliques ; le correctif pour CVE-2025-3048 empêche que ceux qui ont réussi à passer (ou existent légitimement) soient persistés sous forme de fichiers bruts dans la sortie.
Remédiation : Les utilisateurs doivent mettre à niveau vers AWS SAM CLI v1.134.0 ou plus récent pour obtenir ce correctif. Une fois sur v1.134.0+, le processus de construction préservera les liens symboliques par défaut, corrigeant cette vulnérabilité. Après la mise à niveau, il est recommandé de nettoyer et reconstruire toutes les applications SAM pour s'assurer que les artefacts de construction en cache sont régénérés avec le nouveau comportement plus sûr (le bulletin de sécurité AWS conseille d'exécuter un sam build --use-container frais après la mise à niveau). Il n'existe pas de solutions de contournement pour ce problème dans les versions plus anciennes, à part la suppression manuelle des liens symboliques sensibles ou l'abandon des constructions conteneurisées, donc la mise à niveau est la seule solution robuste. En général, considérez le dossier de construction SAM CLI local comme une sortie sensible – avec le correctif, il ne devrait plus contenir de secrets inattendus, mais c'est une bonne pratique de surveiller ce qui se retrouve dans vos artefacts de construction.
CVE-2025-3047 et CVE-2025-3048 impliquent toutes deux des faiblesses dans la gestion des liens symboliques qui pourraient conduire à l'exposition de fichiers confidentiels lors des constructions locales. CVE-2025-3047 pourrait permettre la lecture de fichiers à l'intérieur du conteneur Docker (et potentiellement leur copie vers l'extérieur), tandis que CVE-2025-3048 pourrait permettre à ces fichiers de se retrouver dans la sortie locale où un utilisateur ou un attaquant pourrait les lire ultérieurement. Ces vulnérabilités ont été classées de gravité modérée, car elles nécessitent une certaine interaction de l'utilisateur (exécution d'une construction sur un projet malveillant) mais pourraient entraîner un impact élevé sur la confidentialité. Les correctifs coordonnés garantissent que, par défaut, SAM CLI ne suivra ni ne copiera les cibles des liens symboliques dans la sortie lors des constructions conteneurisées.
Les développeurs et les professionnels DevSecOps utilisant SAM CLI doivent s'assurer que leur CLI est à jour (v1.134.0 ou ultérieure) et rester prudents face aux projets contenant des liens symboliques inattendus. Si vous maintenez des versions forkées ou personnalisées de SAM CLI, vous devez incorporer ces mêmes correctifs. En comprenant ces modifications de code, on peut apprécier comment un petit ajustement logique – comme l'ajout d'une condition ou d'un paramètre de fonction – peut fermer une faille de sécurité sérieuse. Tenez toujours compte de la sécurité de la gestion des fichiers, en particulier en ce qui concerne les liens symboliques et les interactions avec les conteneurs, pour éviter des problèmes similaires de contournement de chemin dans vos propres projets.
Références :
container.py et osutils.py démontrant les correctifs