murataydemir/aws-sam-cli-vulnerabilitiesProblem mit AWS SAM CLI (CVE-2025-3047, CVE-2025-3048)
Diese README bietet eine detaillierte Analyse von zwei Sicherheitslücken im AWS Serverless Application Model CLI (AWS SAM CLI) – CVE-2025-3047 und CVE-2025-3048 – zusammen mit den Code-Problemen und deren Behebungen. Beide Schwachstellen betreffen die unsachgemäße Handhabung von symbolischen Links (Symlinks) während des Build-Prozesses mit Docker-Containern. Jeder Abschnitt unten behandelt eine CVE mit einer Zusammenfassung, betroffenem Code (mit Verweisen auf den SAM CLI Quellcode), dem Patch und dessen Lösung des Problems sowie Hinweisen zur Behebung.
Diese Fehler betreffen die unsachgemäße Handhabung von symbolischen Links (Symlinks) während des sam build --use-container-Prozesses. Beide Probleme betreffen lokale Entwicklungsumgebungen (sie wirken sich nicht auf bereitgestellte AWS-Dienste oder -Ressourcen aus), könnten jedoch unbefugten Zugriff auf Dateien auf dem Host-Rechner ermöglichen, indem missbräuchlich die Art und Weise ausgenutzt wird, wie AWS SAM CLI Symlinks verarbeitet. Ein Upgrade von AWS SAM CLI auf die gepatchten Versionen (1.133.0+ für CVE-2025-3047 und 1.134.0+ für CVE-2025-3048) wird dringend empfohlen.
GHSA-px37-jpqx-97q9 ist eine Path-Traversal-Sicherheitslücke in AWS SAM CLI <= v1.132.0, die unbefugten Dateizugriff auf dem Host-Rechner während sam build --use-container ermöglichte. Beim Erstellen einer serverlosen Anwendung in einem Docker-Container folgte SAM CLI standardmäßig Symlinks im Projekt. Ein Angreifer, der einen bösartigen Symlink im Projekt platzieren konnte (der auf eine sensible Host-Datei verweist), konnte die erhöhten Berechtigungen des Docker-Containers ausnutzen, um diese Datei in den Container einzubinden und an einen zugänglichen Ort im Container zu kopieren. Im Klartext bedeutete dies, dass privilegierte Host-Dateien (außerhalb des Projektverzeichnisses) gelesen und über den Build-Container exfiltriert werden konnten. Das Problem wurde in v1.133.0 behoben. (Um die Rückwärtskompatibilität für legitime Fälle zu erhalten, führte SAM CLI v1.133.0 ein Opt-in-Flag --mount-symlinks ein, um das alte Verhalten bei Bedarf wieder zu aktivieren.)
Ursache und betroffene Komponente: Das Kernproblem liegt darin, wie AWS SAM CLI Projektverzeichnisse und deren Symlinks in den für Builds verwendeten Docker-Container einbindet. Im AWS SAM CLI Code (Modul samcli.local.docker.container) wurden vor der Behebung alle Symlinks der obersten Ebene im Projektverzeichnis automatisch aufgelöst und mit denselben erhöhten Berechtigungen wie der Containerprozess in den Container eingebunden. Der Container läuft standardmäßig als root, sodass das Auflösen und Einbinden eines Symlinks, der auf einen sensiblen Host-Pfad verweist, dem Container Zugriff auf diese Datei geben würde, den ein unprivilegierter Host-Benutzer normalerweise nicht hätte. Der anfällige Code schränkte nicht ausreichend ein, welchen Symlinks gefolgt/eingebunden werden sollte.
Insbesondere in der Funktion, die Docker-Volume-Mounts für den Build erstellt, behandelte SAM CLI Symlinks bedingungslos als tatsächliche Dateien/Verzeichnisse zum Mounten. Die Schwachstelle befand sich in der Container-Orchestrierungslogik von SAM CLI, speziell in der Container.create-Methode von samcli/local/docker/container.py. In anfälligen Versionen versuchte diese Methode immer, Symlink-Ziele aus dem Projekt in den Docker-Container aufzulösen und einzubinden, unabhängig vom Kontext. Der problematische Code ist unten aus SAM CLI v1.132.0 dargestellt:
# samcli/local/docker/container.py (v1.132.0 - vulnerable snippet)
if self._host_dir:
mount_mode = "rw,delegated" if self._mount_with_write else "ro,delegated"
LOG.info("Mounting %s as %s:%s, inside runtime container", self._host_dir, self._working_dir, mount_mode)
_volumes = {
self._host_dir: {
"bind": self._working_dir,
"mode": mount_mode,
},
**self._create_mapped_symlink_files(), # Always resolve and mount symlinks (vulnerable)
}
Im obigen Code scannt _create_mapped_symlink_files() nach Symlinks im Projektverzeichnis und bereitet sie zum Mounten vor. Da dies bedingungslos enthalten war, wurden alle Symlinks (einschließlich solcher, die außerhalb des Projekts zeigen) in den Container eingebunden. (siehe aws/aws-sam-cli#7865)
Der Fehler besteht darin, dass SAM CLI während eines sam build --use-container Symlinks als Dateien behandelt, die in den Container eingebunden werden sollen. Wenn ein Symlink auf z.B. /etc/shadow auf dem Host zeigte, würde der Docker-Container (der möglicherweise mit erhöhten Rechten läuft) diese Datei per Bind-Mount einbinden. Dies ist ein klassischer symlink-basierter Path-Traversal, der zu Privilegieneskalation führt – Host-Dateien, auf die der Benutzer normalerweise keinen Zugriff hätte, könnten vom Container gelesen und dann in der Build-Ausgabe landen.
Patch (Behobener Code in v1.133.0): Die Behebung führt einen Build-Kontext ein und deaktiviert die Symlink-Auflösung während Container-Builds. In der gepatchten Version nimmt Container.create einen zusätzlichen Parameter an, der den Kontext angibt (BUILD vs INVOKE), und löst Symlinks nur dann auf, wenn der Kontext "Invocation" ist (beim lokalen Ausführen von Funktionen), nicht während Builds. Nachfolgend der korrigierte Code aus der gepatchten Version:
# samcli/local/docker/container.py (v1.133.0+ - patched snippet)
if self._host_dir:
mount_mode = "rw,delegated" if self._mount_with_write else "ro,delegated"
LOG.info("Mounting %s as %s:%s, inside runtime container", 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, # Only mount symlinks if explicitly allowed by context (not in build)
}
Im gepatchten Code wird _create_mapped_symlink_files() hinter eine Kontextabfrage gesetzt. Der neue ContainerContext-Enum definiert Kontexte wie BUILD und INVOKE, und _resolve_symlinks(context) gibt für den Build-Kontext False zurück. Daher ist mapped_symlinks während Builds standardmäßig ein leeres Dictionary, d.h. es werden keine Symlinks in den Container eingebunden.
Referenz zur Codeänderung: Die Behebung wurde in Pull Request#7865 (“fix: Resolve symlinks on local invoke only”) implementiert und als Teil von v1.133.0 veröffentlicht. Der GitHub-Diff zeigt die Einführung von ContainerContext und die bedingte Mount-Logik. Indem während des Builds keine Symlink-Ziele eingebunden werden, erhält der Container keinen Zugriff mehr auf Dateien außerhalb des Projektverzeichnisses. (Wenn ein Benutzer Symlinks zu Host-Pfaden erlauben möchte, muss er jetzt über das Flag --mount-symlinks optieren, das nach dieser Behebung hinzugefügt wurde.)