AWS-SAM-CLI-Vulnerabilities

Vulnerabilità di AWS SAM CLI (CVE-2025-3047 e CVE-2025-3048)

---

Questo README fornisce un'analisi dettagliata di due vulnerabilità di sicurezza riscontrate nell'AWS Serverless Application Model CLI (AWS SAM CLI) – CVE-2025-3047 e CVE-2025-3048 – insieme ai problemi a livello di codice e alle relative correzioni. Entrambe le vulnerabilità comportano una gestione impropria dei collegamenti simbolici (symlink) durante il processo di build tramite container Docker. Ciascuna sezione di seguito tratta una CVE con un riepilogo, il codice interessato (con riferimenti al codice sorgente del SAM CLI), la patch e il modo in cui risolve il problema, e indicazioni sui rimedi.

Queste falle comportano una gestione impropria dei collegamenti simbolici (symlink) durante il processo sam build --use-container. Entrambi i problemi interessano gli ambienti di sviluppo locali (non hanno alcun impatto sui servizi o sulle risorse AWS distribuiti)​, ma potrebbero consentire un accesso non autorizzato ai file della macchina host abusando del modo in cui AWS SAM CLI elabora i symlink. È fortemente consigliato aggiornare AWS SAM CLI alle versioni corrette (1.133.0+ per la CVE-2025-3047 e 1.134.0+ per la CVE-2025-3048)​.

CVE-2025-3047 – Path traversal tramite symlink nella build in container

GHSA-px37-jpqx-97q9 è una vulnerabilità di path traversal in AWS SAM CLI <= v1.132.0 che consentiva un accesso non autorizzato ai file sulla macchina host durante sam build --use-container. Quando si compilava un'applicazione serverless all'interno di un container Docker, SAM CLI seguiva i symlink nel progetto per impostazione predefinita. Un attaccante in grado di inserire un symlink dannoso nel progetto (che punta a un file sensibile dell'host) poteva sfruttare i permessi elevati del container Docker per far montare quel file nel container e copiarlo in una posizione accessibile al suo interno. In pratica, ciò significava che i file privilegiati dell'host (fuori dalla directory del progetto) potevano essere letti ed esfiltrati tramite il container di build. Il problema è stato risolto nella v1.133.0. (Per preservare la compatibilità all'indietro per i casi legittimi, SAM CLI v1.133.0 ha introdotto un flag di attivazione esplicita --mount-symlinks per riattivare il vecchio comportamento, se necessario​.)

Causa principale e componente interessato: Il problema centrale risiede nel modo in cui AWS SAM CLI monta le directory del progetto e i relativi symlink nel container Docker utilizzato per le build. Nel codice di AWS SAM CLI (modulo samcli.local.docker.container), prima della correzione, tutti i symlink di primo livello nella directory del progetto venivano automaticamente risolti e montati tramite bind mount nel container con gli stessi privilegi elevati del processo del container. Il container viene eseguito come root per impostazione predefinita, quindi risolvere e montare un symlink che punta a un percorso sensibile dell'host avrebbe dato al container l'accesso a quel file, accesso che un utente host non privilegiato normalmente non avrebbe. Il codice vulnerabile non limitava sufficientemente quali symlink seguire/montare.

Nello specifico, nella funzione che crea i mount dei volumi Docker per la build, SAM CLI trattava incondizionatamente i symlink come file/directory reali da montare. La vulnerabilità risiedeva nella logica di orchestrazione dei container di SAM CLI, in particolare nel metodo Container.create di samcli/local/docker/container.py. Nelle versioni vulnerabili, questo metodo tentava sempre di risolvere e montare le destinazioni dei symlink dal progetto nel container Docker, indipendentemente dal contesto. Il codice problematico è mostrato di seguito, tratto da SAM CLI v1.132.0:

# 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) 
}

Nel codice sopra, _create_mapped_symlink_files() analizza i symlink nella directory del progetto e li prepara per il montaggio. Poiché questo veniva incluso incondizionatamente, tutti i symlink (compresi quelli che puntano all'esterno del progetto) venivano montati nel container​. (vedi aws/aws-sam-cli#7865)

Il difetto qui è che durante un sam build --use-container, SAM CLI tratta i symlink come file da montare nel container. Se un symlink puntava, ad esempio, a /etc/shadow sull'host, il container Docker (che potrebbe essere eseguito con privilegi elevati) montava quel file tramite bind mount. Questo è un classico path traversal basato su symlink, che porta a una elevazione dei privilegi – i file dell'host a cui l'utente normalmente non avrebbe alcun accesso potevano essere letti dal container e poi finire nell'output di build.

Patch (codice corretto in v1.133.0): La correzione introduce una nozione di contesto di build e disabilita la risoluzione dei symlink durante le build in container. Nella versione corretta, Container.create accetta un parametro aggiuntivo che indica il contesto (BUILD vs INVOKE), e risolve i symlink solo se il contesto è di invocazione (quando si eseguono funzioni localmente), non durante le build. Di seguito è riportato il codice corretto della versione patchata:

# 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) 
}

Nel codice corretto, _create_mapped_symlink_files() è racchiuso dietro un controllo del contesto. Il nuovo enum ContainerContext definisce contesti come BUILD e INVOKE, e _resolve_symlinks(context) restituisce False per il contesto di build​. Pertanto, mapped_symlinks sarà un dict vuoto durante le build, il che significa che nessun symlink viene montato nel container per impostazione predefinita.

Riferimento alla modifica del codice: La correzione è stata implementata nella Pull Request#7865 (“fix: Resolve symlinks on local invoke only”) e rilasciata come parte della v1.133.0. Il diff su GitHub mostra l'introduzione di ContainerContext e della logica di montaggio condizionale. Non montando le destinazioni dei symlink durante la build, il container non ottiene più accesso ai file esterni alla directory del progetto. (Se un utente vuole comunque consentire i symlink verso percorsi dell'host, ora deve attivarli esplicitamente tramite il flag --mount-symlinks​, aggiunto dopo questa correzione.)