Vulnerabilidade: fuga de contêiner do process.cwd e fds vazado do runc (CVE-2024-21626)

A Snyk descobriu uma vulnerabilidade em todas as versões do runc <=1.1.11 (usadas pelo mecanismo Docker) e outras tecnologias de conteinerização, como Kubernetes. O exploit desse problema pode resultar no escape do contêiner para o sistema operacional do host subjacente ao executar uma imagem maliciosa ou compilar uma imagem usando um Dockerfile ou uma imagem upstream maliciosa (ou seja, ao usar FROM). A vulnerabilidade CVE-2024-21626 foi associada a esse problema.

Como funciona a CVE-2024-21626?

Demonstração 1: fuga de contêiner por meio de docker build. O que você está vendo aqui é o exploit de docker build para fugir do contêiner e acessar o sistema de arquivos do host por meio de uma leitura arbitrária (neste exemplo, o arquivo /etc/shadow do host) e gravação (neste exemplo, a criação do arquivo DOCKER_BUILD_BREAKOUT).

Demonstração 2: fuga de contêiner por meio de docker run. O que você está vendo aqui mostra como a execução de uma imagem maliciosa de Docker baseada na mesma vulnerabilidade pode resultar na fuga do contêiner Docker para o sistema operacional do host.

A vulnerabilidade ocorre devido à ordem de operações na aplicação da diretiva WORKDIR definida no Dockerfile. WORKDIR define o diretório de trabalho inicial de todos os processos criados pelo Dockerfile, como os executados em tempo de compilação usando a diretiva RUN e os executados em runtime usando as diretivas CMD ou ENTRYPOINT. O diretório fornecido é acessado usando chdir antes que os descritores de arquivo de diretório privilegiados específicos do host tenham sido fechados. É possível especificar um desses descritores de arquivo privilegiados pelo diretório /proc/self/fd/ como argumento para chdir. Isso faz com que o descritor de arquivo privilegiado permaneça acessível mesmo após o próprio descritor de arquivo ser fechado durante as operações normais antes da transferência para o comando definido pelo Dockerfile, tanto em tempo de compilação como no runtime.

Em um ataque bem-sucedido, o processo em execução confirma se o diretório atual pertence ao host e percorre a estrutura de diretórios do host para acessar todo o sistema de arquivos root do host. Por padrão, os privilégios de acesso são os mesmos da solução de conteinerização em uso, como Docker Engine ou Kubernetes. Geralmente, é o usuário root e, portanto, é possível passar do acesso ao disco para a execução de comandos root completos no host.

Como mitigar a CVE-2024-21626

O runc mitigou essa vulnerabilidade garantindo que o diretório especificado na diretiva WORKDIR esteja presente no sistema de arquivos root do contêiner. Além disso, o runc implementou etapas adicionais de reforço para assegurar o fechamento adequado dos descritores de arquivos de diretórios privilegiados do host imediatamente após o uso.

A Snyk recomenda a tomada de medidas imediatas seguindo o aviso do runc para mitigar essa vulnerabilidade de segurança. A versão runc 1.1.12 inclui patches para esse problema. Tecnologias que empacotam o runc também devem ser atualizadas para suas respectivas versões corrigidas. Os avisos dos fornecedores devem ser seguidos ou implementados onde soluções hospedadas estão em uso (como serviços gerenciados de Kubernetes de provedores de nuvem populares).

Avaliação do risco

Essa vulnerabilidade depende de um contêiner malicioso em execução ou compilação dentro de uma infraestrutura vulnerável. Devido à natureza da vulnerabilidade, a detecção é difícil e exige runtime para ser mais precisa. Como os produtos existentes da Snyk não operam no runtime dos aplicativos, criamos duas ferramentas para viabilizar a detecção dessa vulnerabilidade.

Detecção de runtime

A nova equipe Helios da Snyk criou uma ferramenta de detecção em runtime baseada em eBPF para essa vulnerabilidade. Ela está disponível em leaky-vessels-runtime-detector e foi lançada sob a licença Apache-2.0. O eBPF é um mecanismo de instrumentação comum incorporado em diversos kernels modernos do Linux.

Essa ferramenta pode identificar um contêiner em execução tentando explorar essa vulnerabilidade na infraestrutura subjacente, colocando em risco o host associado. Observe que ela não evita a vulnerabilidade e só alerta a respeito da exposição.

Embora nossa recomendação seja atualizar a infraestrutura de contêineres, você pode avaliar seu risco ou exposição usando essa ferramenta quando a atualização imediata não for possível. As organizações devem verificar com o provedor de infraestrutura de contêineres se a infraestrutura foi corrigida.

Instalação e uso

Para instalar e usar nossa ferramenta de detecção estática:

1. Clone o repositório em https://github.com/snyk/leaky-vessels-dynamic-detector.

2. Compile o binário Go usando go build.

3. Execute o detector no ambiente de CI usando sudo ./ebpf-detector.

Para obter mais detalhes, consulte o arquivo README.md.

Análise estática

Caso prefira não executar um binário externo em seu host ou pipeline de CI/CD, também desenvolvemos um detector de análise estática, disponível em https://github.com/snyk/leaky-vessels-static-detector, que analisa Dockerfiles e sinaliza possíveis tentativas de exploit.

A ferramenta examina as imagens analisando a instrução FROM ou consultando diretamente o daemon do Docker local ou registros públicos de contêineres, como Dockerhub ou GCR. O histórico da imagem não mostra todas as instruções incluídas em um Dockerfile, mas exibe as instruções WORKDIR e ONBUILD da imagem principal, o que pode indicar imagens possivelmente maliciosas.

Isso ajuda a proteger contra casos em que uma imagem base de terceiros foi comprometida e tenta explorar os comandos run ou build da imagem secundária. A abordagem estática tem uma taxa mais alta de falsos positivos (ruído), especialmente para exploits que usam flag --mount, mas pode detectar imagens que mereçam uma investigação mais detalhada.

A equipe da Snyk realizou verificações ad hoc de Dockerfiles de registros públicos com base nas imagens que constatamos serem usadas com mais frequência. Nossa pesquisa não foi exaustiva, mas não encontramos evidências que sugiram a exploração dessas vulnerabilidades. A Snyk recomenda que você continue monitorando seu próprio ambiente e verifique seus contêineres até que os patches estejam disponíveis e implantados.

Como sempre, o uso de imagens principais adequadamente mantidas de fontes confiáveis e o acompanhamento das versões mais recentes, incluindo a limpeza de caches de compilação e a verificação da procedência das imagens principais, é uma boa prática.

Instalação e uso

Para instalar e usar nossa ferramenta de detecção estática:

1. Clone o repositório em https://github.com/snyk/leaky-vessels-static-detector

2. Compile o binário Go usando go build.

3. Execute o detector usando ./static-detector dockerfile -f [CAMINHO_PARA_DOCKERFILE].

4. Para ver mais opções de execução, consulte o arquivo README.md.

CVE-2024-21626: resumo e orientações

Essa vulnerabilidade de escape de contêiner é grave e tem o potencial de causar danos a qualquer infraestrutura de host subjacente que execute ou compile contêineres.

A Snyk recomenda a atualização de qualquer instância do runc para a versão 1.1.12 ou posterior, assim como a atualização de qualquer software que dependa do runc. Além disso, não deixe de seguir todos os avisos de fornecedores relacionados a esse problema, já que serviços de hospedagem e infraestrutura de contêineres podem ser afetados.

A Snyk também divulgou várias outras vulnerabilidades de fuga de contêiner na nossa pesquisa, com CVEs atribuídas: CVE-2024-23652, CVE-2024-23651e CVE-2024-23653. Você pode ler o resumo das nossas descobertas sobre todas as CVEs aqui.

Este artigo foi publicado exclusivamente para fins informativos. A Snyk não se responsabiliza por quaisquer erros ou omissões nem pelos resultados obtidos com o uso dessas informações.