murataydemir/aws-sam-cli-vulnerabilitiesProblema com o AWS SAM CLI (CVE-2025-3047, CVE-2025-3048)
Este README fornece uma análise detalhada de duas vulnerabilidades de segurança encontradas no AWS Serverless Application Model CLI (AWS SAM CLI) – CVE-2025-3047 e CVE-2025-3048 – juntamente com os problemas e correções ao nível do código. Ambas as vulnerabilidades envolvem o tratamento inadequado de ligações simbólicas (symlinks) durante o processo de construção com contêineres Docker. Cada seção abaixo cobre uma CVE com um resumo, código afetado (com referências ao código-fonte do SAM CLI), a correção e como esta resolve o problema, e orientações sobre remediação.
Estas falhas envolvem o tratamento inadequado de ligações simbólicas (symlinks) durante o processo sam build --use-container. Ambas as questões afetam ambientes de desenvolvimento locais (não impactam serviços ou recursos AWS implantados), mas podem permitir acesso não autorizado a arquivos na máquina anfitriã ao abusar da forma como o AWS SAM CLI processa symlinks. É fortemente recomendado atualizar o AWS SAM CLI para as versões corrigidas (1.133.0+ para CVE-2025-3047 e 1.134.0+ para CVE-2025-3048).
O GHSA-px37-jpqx-97q9 é uma vulnerabilidade de path traversal no AWS SAM CLI <= v1.132.0 que permitia acesso não autorizado a arquivos na máquina anfitriã durante sam build --use-container. Ao construir uma aplicação serverless dentro de um contêiner Docker, o SAM CLI seguia symlinks no projeto por padrão. Um atacante que conseguisse plantar um symlink malicioso no projeto (apontando para um arquivo sensível do anfitrião) poderia aproveitar as permissões elevadas do contêiner Docker para fazer com que esse arquivo fosse montado no contêiner e copiado para um local acessível dentro do contêiner. Na prática, isso significava que arquivos privilegiados do anfitrião (fora do diretório do projeto) podiam ser lidos e exfiltrados por meio do contêiner de construção. O problema foi corrigido na versão v1.133.0. (Para preservar a compatibilidade com versões anteriores em casos legítimos, o SAM CLI v1.133.0 introduziu uma flag opcional --mount-symlinks para reativar o comportamento antigo, se necessário.)
Causa Raiz e Componente Afetado: O núcleo do problema reside na forma como o AWS SAM CLI monta os diretórios do projeto e seus symlinks no contêiner Docker usado para as construções. No código do AWS SAM CLI (módulo samcli.local.docker.container), antes da correção, todos os symlinks de nível superior no diretório do projeto eram automaticamente resolvidos e montados via bind mount no contêiner com as mesmas permissões elevadas do processo do contêiner. O contêiner é executado como root por padrão, portanto resolver e montar um symlink que aponta para um caminho sensível do anfitrião daria ao contêiner acesso a esse arquivo, algo que um usuário anfitrião sem privilégios normalmente não teria. O código vulnerável não restringia suficientemente quais symlinks seguir/montar.
Especificamente, na função que cria os mounts de volume Docker para a construção, o SAM CLI tratava incondicionalmente os symlinks como arquivos/diretórios reais a serem montados. A vulnerabilidade residia na lógica de orquestração de contêineres do SAM CLI, especificamente no método Container.create de samcli/local/docker/container.py. Em versões vulneráveis, esse método sempre tentava resolver e montar os alvos dos symlinks do projeto no contêiner Docker, independentemente do contexto. O código problemático é mostrado abaixo, da versão v1.132.0 do SAM CLI:
# 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)
}
No código acima, _create_mapped_symlink_files() verifica a existência de symlinks no diretório do projeto e os prepara para serem montados. Como isso era incluído incondicionalmente, todos os symlinks (incluindo aqueles que apontam para fora do projeto) seriam montados no contêiner. (ver aws/aws-sam-cli#7865)
A falha aqui é que durante um sam build --use-container, o SAM CLI trata os symlinks como arquivos a serem montados no contêiner. Se um symlink apontasse, por exemplo, para /etc/shadow no anfitrião, o contêiner Docker (que pode ser executado com privilégios elevados) faria o bind mount desse arquivo. Isso é um clássico path traversal baseado em symlink, resultando em escalada de privilégios – arquivos do anfitrião aos quais o usuário normalmente não teria acesso poderiam ser lidos pelo contêiner e, em seguida, parar na saída da construção.
Correção (Código Corrigido na v1.133.0): A correção introduz a noção de contexto de construção e desativa a resolução de symlinks durante as construções em contêiner. Na versão corrigida, Container.create recebe um parâmetro extra que indica o contexto (BUILD vs INVOKE), e só resolverá symlinks se o contexto for de invocação (ao executar funções localmente), não durante as construções. Abaixo está o código da versão corrigida:
# 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)
}
No código corrigido, _create_mapped_symlink_files() é envolvido por uma verificação de contexto. O novo enum ContainerContext define contextos como BUILD e INVOKE, e _resolve_symlinks(context) retorna False para o contexto de construção. Assim, mapped_symlinks será um dicionário vazio durante as construções, o que significa que nenhum symlink é montado no contêiner por padrão.
Referência da Alteração no Código: A correção foi implementada no Pull Request#7865 (“fix: Resolve symlinks on local invoke only”) e lançada como parte da v1.133.0. O diff no GitHub mostra a introdução do ContainerContext e da lógica de montagem condicional. Ao não montar os alvos dos symlinks durante a construção, o contêiner deixa de ter acesso a arquivos fora do diretório do projeto. (Se um usuário quiser permitir symlinks para caminhos do anfitrião, agora é necessário optar por isso através da flag --mount-symlinks, que foi adicionada após esta correção.)