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.)
Wie der Patch das Problem löst: Nach dem Patch werden Symlinks im Projekt während der Build-Phase nicht mehr verfolgt. Sie bleiben einfach als Symlinks im Container (die auf nicht eingebundene Pfade verweisen) oder werden ignoriert, anstatt durch den Inhalt ihres Ziels ersetzt zu werden. Dies schließt die Lücke, durch die ein Angreifer den Build-Prozess dazu verleiten könnte, sensible Host-Dateien zu kopieren. Kurz gesagt: Die Ansicht des Build-Containers ist jetzt auf das Projektverzeichnis selbst beschränkt (plus explizit erlaubte Volumes), wodurch die unbeabsichtigte Privilegieneskalation beseitigt wird.
Behebung: Alle Benutzer sollten auf AWS SAM CLI v1.133.0 oder höher aktualisieren, um diesen Patch zu erhalten. Nach dem Upgrade ist das Standardverhalten sicher. Nur wenn Sie Ihrem Projekt explizit vertrauen und das alte Verhalten benötigen, sollten Sie sam build --use-container --mount-symlinks verwenden. Für die meisten Entwickler wird empfohlen, dieses Flag standardmäßig zu deaktivieren, um sicherzustellen, dass Symlinks den Arbeitsbereich nicht verlassen können. Es ist auch gute Praxis, Symlinks in Ihren Projekten zu überprüfen, um sicherzustellen, dass sie nicht auf sensible Speicherorte verweisen.
GHSA-pp64-wj43-xqcr ist eine verwandte Schwachstelle, die AWS SAM CLI <= v1.133.0 betrifft (behoben in v1.134.0). Eine Schwachstelle im Build-Artefakt-Zwischenspeicher von AWS SAM CLI könnte dazu führen, dass vertrauliche Dateien nach einem Build aus dem Container zurück in den Host-Arbeitsbereich gelangen. Wenn ein Projekt Symlinks enthielt, wurden nach der Ausführung von sam build --use-container die Inhalte der Symlink-Ziele als reguläre Dateien oder Ordner in das lokale Build-Cache-Verzeichnis kopiert. Dadurch könnte ein Entwickler ohne Zugriff auf bestimmte Host-Dateien Zugriff erhalten, weil die Inhalte dieser Dateien in der .aws-sam-Build-Ausgabe auf dem Host landen. Beispielsweise könnte ein Symlink im Projekt, der auf /secret/config verweist, dazu führen, dass der tatsächliche Inhalt von /secret/config im Ordner .aws-sam/build des Projekts erscheint, selbst wenn der Benutzer /secret/config nicht direkt lesen konnte.
Ursache und betroffene Komponente: Der Kern dieses Problems lag darin, wie SAM CLI Dateien aus dem Container (oder aus dem Build-Prozess) in das Verzeichnis der lokalen Build-Artefakte kopierte. Die für das Kopieren von Dateien verantwortliche Funktion befindet sich in samcli/lib/utils/osutils.py, insbesondere im benutzerdefinierten copytree-Dienstprogramm. In anfälligen Versionen verwendete diese Funktion Pythons shutil.copy2 ohne Angabe von follow_symlinks=False, was standardmäßig Symlinks folgt und die Dateiinhalte kopiert. Der untenstehende Ausschnitt (aus v1.133.0) zeigt die problematische Logik:
# samcli/lib/utils/osutils.py (v1.133.0 - vulnerable snippet)
# ... inside osutils.copytree ...
else:
try:
shutil.copy2(new_source, new_destination) # follow_symlinks is True by default (vulnerable)
except OSError as e:
if e.errno != errno.EINVAL:
raise e
Hier, wenn new_source ein Symlink ist, löst shutil.copy2 den Symlink auf und kopiert die Zieldatei nach new_destination. Es gab kein Flag, um anzuweisen, den Symlink zu erhalten. Somit führte ein Symlink zu einer sensiblen Datei dazu, dass der Inhalt dieser Datei im Zielverzeichnis erschien. (siehe aws/aws-sam-cli#7890)
Praktisch ausgedrückt: Stellen Sie sich vor, der Build-Prozess hätte einen Symlink config -> /etc/secret-config erstellt (vielleicht als Teil der Schichtung von Abhängigkeiten oder als Überbleibsel des Szenarios von CVE-2025-3047). Der obige Code würde den Inhalt von /etc/secret-config in die lokale Build-Ausgabe als config kopieren. Ein lokaler Benutzer, der /etc/secret-config nicht direkt lesen konnte, könnte nun einfach die Datei unter .aws-sam/build/.../config öffnen und deren Inhalt sehen.
Patch (Behobener Code in v1.134.0): Die Behebung war einfach – Symlinks erhalten, anstatt ihnen beim Kopieren zu folgen. In Pythons shutil wird dies durch Übergabe von follow_symlinks=False erreicht. Der gepatchte Code (v1.134.0) ändert den Kopieraufruf wie folgt:
# samcli/lib/utils/osutils.py (v1.134.0 - patched snippet)
else:
try:
shutil.copy2(new_source, new_destination, follow_symlinks=False) # Do not follow symlinks (fixed)
except OSError as e:
if e.errno != errno.EINVAL:
raise e
Mit follow_symlinks=False wird die Funktion, wenn new_source ein Symlink ist, den Symlink selbst kopieren anstatt die Datei, auf die er zeigt. Mit anderen Worten: Die Build-Ausgabe enthält einen Symlink mit demselben Ziel anstelle einer echten Datei mit dem Inhalt des Ziels.
Referenz zur Codeänderung: Die Änderung wurde in Pull Request#7890 (“fix: Keep symlinks when copying files after build”) vorgenommen und in v1.134.0 veröffentlicht. Der GitHub-Diff dieses PRs bestätigt die Hinzufügung des Parameters follow_symlinks=False zu shutil.copy2, zusammen mit aktualisierten Unit-Tests, um sicherzustellen, dass Symlinks erhalten bleiben. Die PR-Beschreibung stellt ausdrücklich fest: “Symlinks werden nicht mehr in Kopien der Dateien umgewandelt, sondern behalten ihren Symlink-Status.” Dies bedeutet, dass die Build-Artefakte Symlinks enthalten (die auf die ursprünglichen Dateipfade verweisen) anstelle von unbefugten Kopien der Dateidaten.
Wie der Patch das Problem löst: Nach dieser Behebung gibt das Dateikopieren nach dem Build in SAM CLI keine Dateiinhalte mehr preis. Wenn während des Builds ein Symlink erstellt wurde, bleibt er in der Ausgabe als Symlink erhalten. Der lokale Benutzer erhält keinen magischen Lesezugriff auf den Inhalt des Ziels – er sieht lediglich einen Symlink, der immer noch auf den ursprünglichen Pfad verweist. Sofern der Benutzer nicht bereits über die Berechtigung zum Lesen der Zieldatei verfügte, ist der Symlink in der Ausgabe harmlos (er würde einen Fehler verursachen, wenn er ohne entsprechende Zugriffsrechte dereferenziert wird). Im Wesentlichen wird die Vertraulichkeitsauswirkung gemindert: Vertrauliche Dateien werden nicht versehentlich in den Arbeitsbereich des Benutzers materialisiert. Diese Behebung ergänzt den Patch für CVE-2025-3047: Sie verhinderte, dass der Container Host-Dateien über Symlinks abgreift; die Behebung für CVE-2025-3048 verhindert, dass solche, die doch durchkamen (oder legitim vorhanden waren), als Klartextdateien in der Ausgabe persistiert werden.
Behebung: Benutzer sollten auf AWS SAM CLI v1.134.0 oder neuer aktualisieren, um diesen Patch zu erhalten. Sobald Sie v1.134.0+ verwenden, bewahrt der Build-Prozess Symlinks standardmäßig und behebt diese Schwachstelle. Nach dem Upgrade wird empfohlen, SAM-Anwendungen zu bereinigen und neu zu erstellen, um sicherzustellen, dass zwischengespeicherte Build-Artefakte mit dem neuen, sichereren Verhalten neu generiert werden (das AWS-Sicherheitsbulletin rät nach dem Upgrade zu einem frischen sam build --use-container). Für ältere Versionen gibt es keine Workarounds für dieses Problem außer dem manuellen Entfernen sensibler Symlinks oder dem Verzicht auf Container-Builds, daher ist ein Upgrade die einzig robuste Lösung. Behandeln Sie den lokalen SAM CLI Build-Ordner im Allgemeinen als sensible Ausgabe – mit dem Patch sollte er keine unerwarteten Geheimnisse mehr enthalten, aber es ist gute Praxis, darauf zu achten, was in Ihren Build-Artefakten landet.
Beide Schwachstellen CVE-2025-3047 und CVE-2025-3048 betreffen Schwächen in der Symlink-Behandlung, die zur Offenlegung vertraulicher Dateien während lokaler Builds führen könnten. CVE-2025-3047 könnte es ermöglichen, Dateien innerhalb des Docker-Containers zu lesen (und möglicherweise herauszukopieren), während CVE-2025-3048 dazu führen könnte, dass diese Dateien in der lokalen Ausgabe landen, wo ein Benutzer oder Angreifer sie später lesen könnte. Diese Schwachstellen wurden als mittelschwer eingestuft, da sie eine gewisse Benutzerinteraktion erfordern (Ausführen eines Builds auf einem bösartigen Projekt), aber zu hohen Vertraulichkeitsauswirkungen führen könnten. Die koordinierten Patches stellen sicher, dass SAM CLI standardmäßig weder Symlinks während containerisierter Builds folgt noch Symlink-Ziele in die Ausgabe kopiert.
Entwickler und DevSecOps-Profis, die SAM CLI verwenden, sollten sicherstellen, dass ihre CLI auf dem neuesten Stand ist (v1.134.0 oder später), und bei Projekten mit unerwarteten Symlinks wachsam bleiben. Wenn Sie geforkte oder angepasste Versionen von SAM CLI verwalten, müssen Sie dieselben Korrekturen integrieren. Durch das Verständnis dieser Codeänderungen kann man nachvollziehen, wie eine kleine Logikanpassung – wie das Hinzufügen einer Bedingung oder eines Funktionsparameters – ein ernstes Sicherheitsloch schließen kann. Berücksichtigen Sie stets die Sicherheit der Dateiverarbeitung, insbesondere im Hinblick auf Symlinks und Container-Interaktionen, um ähnliche Path-Traversal-Probleme in Ihren eigenen Projekten zu verhindern.
Referenzen:
container.py und osutils.py zur Veranschaulichung der Korrekturen.