AWS-SAM-CLI-Vulnerabilities

Vulnerabilidades de AWS SAM CLI (CVE-2025-3047 y CVE-2025-3048)

---

Este README proporciona un análisis detallado de dos vulnerabilidades de seguridad encontradas en la Interfaz de Línea de Comandos del Modelo de Aplicaciones Serverless de AWS (AWS SAM CLI) – CVE-2025-3047 y CVE-2025-3048 – junto con los problemas a nivel de código y sus correcciones. Ambas vulnerabilidades implican un manejo inadecuado de los enlaces simbólicos (symlinks) durante el proceso de compilación mediante contenedores Docker. Cada sección a continuación cubre un CVE con un resumen, el código afectado (con referencias al código fuente de SAM CLI), el parche y cómo resuelve el problema, y orientación sobre la remediación.

Estas fallas implican un manejo inadecuado de los enlaces simbólicos (symlinks) durante el proceso sam build --use-container. Ambos problemas afectan a los entornos de desarrollo locales (no impactan los servicios o recursos implementados de AWS)​, pero podrían permitir acceso no autorizado a archivos en la máquina host al abusar de la forma en que AWS SAM CLI procesa los enlaces simbólicos. Se recomienda encarecidamente actualizar AWS SAM CLI a las versiones parcheadas (1.133.0+ para CVE-2025-3047, y 1.134.0+ para CVE-2025-3048)​.

CVE-2025-3047 – Path Traversal por enlaces simbólicos en la compilación con contenedores

GHSA-px37-jpqx-97q9 es una vulnerabilidad de path traversal en AWS SAM CLI <= v1.132.0 que permitía el acceso no autorizado a archivos en la máquina host durante sam build --use-container. Al compilar una aplicación serverless dentro de un contenedor Docker, SAM CLI seguía los enlaces simbólicos del proyecto por defecto. Un atacante que pudiera colocar un enlace simbólico malicioso en el proyecto (apuntando a un archivo sensible del host) podría aprovechar los permisos elevados del contenedor Docker para que ese archivo se montara en el contenedor y se copiara a una ubicación accesible dentro del contenedor. En efecto, esto significaba que los archivos privilegiados del host (fuera del directorio del proyecto) podían leerse y exfiltrarse a través del contenedor de compilación. El problema se corrigió en v1.133.0. (Para preservar la compatibilidad hacia atrás en casos legítimos, SAM CLI v1.133.0 introdujo una bandera opcional --mount-symlinks para volver a habilitar el comportamiento anterior si fuera necesario​).

Causa raíz y componente afectado: El problema central radica en cómo AWS SAM CLI monta los directorios del proyecto y sus enlaces simbólicos en el contenedor Docker utilizado para las compilaciones. En el código de AWS SAM CLI (módulo samcli.local.docker.container), antes de la corrección, todos los enlaces simbólicos de nivel superior en el directorio del proyecto se resolvían automáticamente y se montaban por bind en el contenedor con los mismos privilegios elevados que el proceso del contenedor. El contenedor se ejecuta como root por defecto, por lo que resolver y montar un enlace simbólico que apunte a una ruta sensible del host daría al contenedor acceso a ese archivo, algo que un usuario no privilegiado del host normalmente no tendría. El código vulnerable no restringía suficientemente qué enlaces simbólicos seguir/montar.

Específicamente, en la función que crea los montajes de volúmenes Docker para la compilación, SAM CLI trataba incondicionalmente los enlaces simbólicos como archivos/directorios reales para montar. La vulnerabilidad residía en la lógica de orquestación de contenedores de SAM CLI, concretamente en el método Container.create de samcli/local/docker/container.py. En las versiones vulnerables, este método siempre intentaba resolver y montar los destinos de los enlaces simbólicos del proyecto dentro del contenedor Docker, independientemente del contexto. El código problemático se muestra a continuación, de 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) 
}

En el código anterior, _create_mapped_symlink_files() escanea los enlaces simbólicos bajo el directorio del proyecto y los prepara para ser montados. Debido a que se incluía incondicionalmente, todos los enlaces simbólicos (incluidos los que apuntan fuera del proyecto) se montaban en el contenedor​. (ver aws/aws-sam-cli#7865)

La falla aquí es que durante un sam build --use-container, SAM CLI trata los enlaces simbólicos como archivos para montar en el contenedor. Si un enlace simbólico apuntara, por ejemplo, a /etc/shadow en el host, el contenedor Docker (que podría ejecutarse con privilegios elevados) montaría ese archivo mediante bind. Esto es un path traversal basado en enlaces simbólicos clásico, que resulta en escalada de privilegios – los archivos del host a los que el usuario normalmente no tendría acceso podrían ser leídos por el contenedor y terminar en la salida de la compilación.

Parche (código corregido en v1.133.0): La corrección introduce una noción de contexto de compilación y desactiva la resolución de enlaces simbólicos durante las compilaciones en contenedores. En la versión parcheada, Container.create recibe un parámetro adicional que indica el contexto (BUILD vs INVOKE), y solo resolverá enlaces simbólicos si el contexto es invocación (cuando se ejecutan funciones localmente), no durante las compilaciones. A continuación se muestra el código corregido de la versión parcheada:

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

En el código parcheado, _create_mapped_symlink_files() está envuelto tras una comprobación de contexto. El nuevo enum ContainerContext define contextos como BUILD e INVOKE, y _resolve_symlinks(context) devuelve False para el contexto de compilación​. Por lo tanto, mapped_symlinks será un diccionario vacío durante las compilaciones, lo que significa que ningún enlace simbólico se monta en el contenedor por defecto.