Vulnerabilidade em embarcações com vazamento prejudica a segurança dos contêineres

Os pesquisadores descobriram uma lacuna no mecanismo de contêiner runc de código aberto, grande o suficiente para que os invasores possam navegar facilmente até os sistemas operacionais host subjacentes, onde podem causar todos os tipos de danos aos seus sistemas.

“Um invasor pode usar (esta vulnerabilidade) para obter acesso não autorizado ao sistema operacional host subjacente de dentro do contêiner”, aconselhou a empresa de segurança Snyk na quarta-feira em uma postagem de blog sobre esta vulnerabilidade e um conjunto de outras que apelidou de “Vasos Furados”.

Os mantenedores da interface de linha de comando runc identificaram primeiro o problema original – um descritor de arquivo com vazamento – e correram para lançar uma atualização, runc v1.12, que corrige o problema principal (descrito em CVE-2024-21626).

Até que todos atualizem, no entanto, os usuários de ferramentas como Docker, Kubernetes e serviços de contêiner baseados em nuvem devem estar atentos a patches de seus fornecedores, aconselhou Snyk.

O Docker, entre outras ferramentas, usa runc como mecanismo de tempo de execução de contêiner padrão. O Docker criou originalmente o runc e depois o legou à Open Container Initiative para mantê-lo como um projeto de código aberto neutro em termos de fornecedor.

Na quarta-feira, o Docker lançou rapidamente patches para runc, junto com vulnerabilidades associadas encontradas no mecanismo de código aberto Moby Docker e no BuildKit.

O GitHub classificou a vulnerabilidade com 8,6, um “alto nível de gravidade” na escala de classificação CVSS, o que significa que a falha pode resultar em tempo de inatividade significativo e/ou perda de dados, embora seja difícil de explorar. Docker apontou, também poderia ser usado para envenenar a integridade do cache de construção.

Os pesquisadores da Snyk relataram não ter encontrado nenhuma exploração no mundo que faça uso desse bug.

Os danos que os vasos com vazamento podem causar

Com tal vulnerabilidade, um invasor pode acessar e assumir o controle do sistema operacional subjacente. A partir daí, eles poderiam acessar outros dados do sistema (como credenciais) e lançar novos ataques.

“Com a adoção generalizada de tecnologias de conteinerização em ambientes de desenvolvimento e produção, tais explorações representam riscos significativos para a integridade dos dados, confidencialidade e estabilidade do sistema”, apontou um boletim da Red Hat na quinta-feira.

Um sistema pode ser afetado pela execução de uma imagem envenenada com o código de ataque ou pela construção de um contêiner usando um Dockerfile malicioso ou uma imagem upstream.

“Essas vulnerabilidades só podem ser exploradas se um usuário se envolver ativamente com conteúdo malicioso, incorporando-o ao processo de construção ou executando um contêiner a partir de uma imagem suspeita”, escreveu a engenheira sênior de segurança do Docker, Gabriela Georgieva, em um blog na quarta-feira.

“Pedimos veementemente a todos os clientes que priorizem a segurança, aplicando as atualizações disponíveis assim que forem lançadas. A aplicação oportuna dessas atualizações é a medida mais eficaz para proteger seus sistemas contra essas vulnerabilidades e manter um ambiente Docker seguro e confiável.”

A Red Hat aconselhou inspecionar Dockerfiles com as diretivas Run e WORKDIR para garantir que eles não tenham escapes ou caminhos maliciosos. Para aqueles com kernels Linux que suportam eBPF, Snyk lançou um detector para a vulnerabilidade, leaky-vessels-runtime-detector.

Essas demonstrações mostram um contêiner capaz de ler /etc/shadow por meio dos comandos docker run ou docker build.

Eles estão extraindo imagens criadas especificamente com o exploit pré-carregado pic.twitter.com/zMRaYufps1

-Matt Johansen (@mattjay) 31 de janeiro de 2024

BuildKit também é afetado por vasos com vazamento

Snyk relatou três vulnerabilidades mais estreitamente relacionadas no BuildKit, frequentemente usadas em conjunto com runc. Todos também são classificados com alto nível de gravidade:

• CVE-2024-23651:Corrida de cache de montagem do Buildkit
• CVE-2024-23653:Verificação de privilégio do Buildkit GRPC SecurityMode
• CVE-2024-23652:Buildkit Build-time Container Teardown Exclusão arbitrária

O mecanismo runc é “um dos tempos de execução de contêiner de nível mais baixo, então os usuários geralmente não interagem diretamente com o runc, eles interagem com alguma outra abstração na parte superior que então usa o runc para executar comandos”, explicou Jimmy Mesta, CTO e co. -fundador da empresa de segurança Kubernetes KSOC, em uma postagem no blog. “runc funciona com outros softwares, como o BuildKit, para realizar atividades como descompactar as camadas de imagem e iniciar processos de contêiner, colocar o sistema de arquivos no lugar e limpar esses processos e arquivos assim que o contêiner for excluído. No tempo de execução do contêiner, o BuildKit seria o que construiria a imagem, enquanto o runC faria a execução real de cada etapa.”

Esta não é a primeira vez que Runc é atormentado por uma saída de emergência não intencional. Em 2019, o TNS relatou o Runcescape (CVE-2019-5736) descoberto por pesquisadores poloneses que investigavam sandboxes baseadas em namespaces.

A postagem Vulnerabilidade em embarcações com vazamento afunda a segurança de contêineres apareceu pela primeira vez em The New Stack.