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.)
Como a Correção Resolve o Problema: Após a correção, qualquer symlink no projeto não será mais seguido durante a fase de construção. Eles simplesmente permanecerão como symlinks no contêiner (apontando para caminhos que não serão montados) ou serão ignorados, em vez de serem substituídos pelo conteúdo de seus alvos. Isso fecha a brecha onde um atacante poderia enganar o processo de construção para copiar arquivos sensíveis do anfitrião. Em resumo, a visão do contêiner de construção agora está confinada ao próprio diretório do projeto (além de volumes explicitamente permitidos), eliminando a escalada de privilégios não intencional.
Remediação: Todos os usuários devem atualizar para AWS SAM CLI v1.133.0 ou posterior para obter esta correção. Após a atualização, o comportamento padrão é seguro. Somente se você confiar explicitamente no seu projeto e precisar do comportamento antigo é que deve usar sam build --use-container --mount-symlinks. Para a maioria dos desenvolvedores, é recomendado deixar essa flag desativada (o padrão) para garantir que os symlinks não possam atravessar para fora do espaço de trabalho. Também é uma boa prática revisar quaisquer symlinks nos seus projetos para garantir que eles não apontem para locais sensíveis.
O GHSA-pp64-wj43-xqcr é uma vulnerabilidade relacionada que afeta o AWS SAM CLI <= v1.133.0 (corrigida na v1.134.0). Uma vulnerabilidade no cache de artefatos de construção do AWS SAM CLI poderia permitir que arquivos sensíveis vazassem do contêiner de volta para o espaço de trabalho do anfitrião após uma construção. Se um projeto incluísse symlinks, após executar sam build --use-container, o conteúdo dos alvos dos symlinks seria copiado para o diretório de cache de construção local como arquivos ou pastas normais. Na prática, um desenvolvedor sem acesso a certos arquivos do anfitrião poderia obter acesso porque o conteúdo desses arquivos acabaria na saída de construção .aws-sam no anfitrião. Por exemplo, um symlink no projeto apontando para /secret/config poderia resultar no conteúdo real de /secret/config aparecendo na pasta .aws-sam/build do projeto após a construção no contêiner, mesmo que o usuário não pudesse ler /secret/config diretamente.
Causa Raiz e Componente Afetado: O núcleo deste problema estava na forma como o SAM CLI copiava arquivos do contêiner (ou do processo de construção) para o diretório de artefatos de construção do projeto local. A função responsável pela cópia de arquivos está em samcli/lib/utils/osutils.py, especificamente no utilitário personalizado copytree. Em versões vulneráveis, essa função usava shutil.copy2 do Python sem especificar follow_symlinks=False, que por padrão segue symlinks e copia o conteúdo dos arquivos. O trecho abaixo (da v1.133.0) mostra a lógica problemática:
# 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
Aqui, se new_source for um symlink, o shutil.copy2 resolverá o symlink e copiará o arquivo alvo para new_destination. Não havia uma flag para instruí-lo a preservar o symlink. Assim, um symlink para um arquivo sensível resultaria no conteúdo desse arquivo aparecendo no diretório de destino. (ver aws/aws-sam-cli#7890)
Em termos práticos, imagine que o processo de construção criou um symlink config -> /etc/secret-config (talvez como parte da camada de dependências ou como resquício do cenário da CVE-2025-3047). O código acima copiaria o conteúdo de /etc/secret-config para a saída de construção local como config. Um usuário local que não pudesse ler /etc/secret-config diretamente poderia simplesmente abrir o arquivo em .aws-sam/build/.../config e ver seu conteúdo.
Correção (Código Corrigido na v1.134.0): A correção foi direta – preservar os symlinks em vez de segui-los ao copiar. No shutil do Python, isso é feito passando follow_symlinks=False. O código corrigido (v1.134.0) altera a chamada de cópia da seguinte forma:
# 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
Com follow_symlinks=False, se new_source for um symlink, a função copiará o próprio symlink em vez do arquivo para o qual ele aponta. Em outras palavras, a saída da construção conterá um symlink com o mesmo alvo, em vez de um arquivo real com o conteúdo do alvo.
Referência da Alteração no Código: A alteração foi feita no Pull Request#7890 (“fix: Keep symlinks when copying files after build”) e lançada na v1.134.0. O diff do GitHub deste PR confirma a adição do parâmetro follow_symlinks=False ao shutil.copy2, juntamente com testes de unidade atualizados para garantir que os symlinks sejam preservados. A descrição do PR observa explicitamente: “Os symlinks deixarão de ser transformados em cópias dos arquivos e manterão seu status de symlink.” Isso significa que os artefatos de construção conterão symlinks (que referenciam os caminhos originais dos arquivos) em vez de cópias não autorizadas dos dados dos arquivos.
Como a Correção Resolve o Problema: Após esta correção, a cópia de arquivos pós-construção do SAM CLI não vaza mais o conteúdo dos arquivos. Se um symlink foi criado durante a construção, ele permanecerá como symlink na saída. O usuário local não ganhará magicamente acesso de leitura ao conteúdo do alvo – ele verá apenas um symlink que ainda aponta para o caminho original. A menos que o usuário já tivesse permissão para ler o arquivo alvo, o symlink na saída é inofensivo (ocorrerá um erro se for desreferenciado sem o acesso adequado). Essencialmente, o impacto de confidencialidade é mitigado: arquivos sensíveis não são inadvertidamente materializados no espaço de trabalho do usuário. Esta correção complementa o patch da CVE-2025-3047: ele impediu o contêiner de capturar arquivos do anfitrião via symlinks; a correção da CVE-2025-3048 impede que qualquer um que tenha passado (ou existisse legitimamente) seja persistido como arquivos simples na saída.
Remediação: Os usuários devem atualizar para AWS SAM CLI v1.134.0 ou mais recente para obter esta correção. Uma vez na v1.134.0+, o processo de construção preservará os symlinks por padrão, corrigindo esta vulnerabilidade. Após a atualização, é recomendado limpar e reconstruir quaisquer aplicações SAM para garantir que os artefatos de construção em cache sejam regenerados sob o novo comportamento mais seguro (o boletim de segurança da AWS aconselha executar um novo sam build --use-container após a atualização). Não há workarounds para este problema em versões mais antigas, exceto remover manualmente symlinks sensíveis ou não usar construções em contêiner; portanto, atualizar é a única solução robusta. Em geral, trate a pasta de construção local do SAM CLI como saída sensível – com o patch, ela não deve mais conter segredos inesperados, mas é uma boa prática ficar de olho no que acaba nos seus artefatos de construção.
Tanto a CVE-2025-3047 quanto a CVE-2025-3048 envolvem fraquezas no manuseio de symlinks que poderiam levar à exposição de arquivos confidenciais durante construções locais. A CVE-2025-3047 poderia permitir que arquivos fossem lidos dentro do contêiner Docker (e potencialmente copiados para fora), enquanto a CVE-2025-3048 poderia permitir que esses arquivos fossem parar na saída local, onde um usuário ou atacante poderia lê-los posteriormente. Essas vulnerabilidades foram classificadas com severidade moderada, pois exigem alguma interação do usuário (executar uma construção em um projeto malicioso), mas podem resultar em alto impacto de confidencialidade. Os patches coordenados garantem que, por padrão, o SAM CLI não seguirá symlinks durante construções em contêiner nem copiará os alvos dos symlinks para a saída.
Desenvolvedores e profissionais de DevSecOps que usam o SAM CLI devem garantir que sua CLI esteja atualizada (v1.134.0 ou posterior) e permanecer cautelosos em relação a projetos que contenham symlinks inesperados. Se você mantém versões forked ou personalizadas do SAM CLI, deve incorporar essas mesmas correções. Ao compreender essas alterações de código, percebe-se como um pequeno ajuste de lógica – como adicionar uma condicional ou um parâmetro de função – pode fechar um grave buraco de segurança. Sempre considere a segurança do manuseio de arquivos, especialmente quando se trata de symlinks e interações com contêineres, para evitar problemas semelhantes de path traversal em seus próprios projetos.
Referências:
container.py e osutils.py demonstrando as correções