Leaky Vessels: vulnerabilidades de fuga de contêiner no Docker e runc (janeiro de 2024)
31 de janeiro de 2024
0 minutos de leituraObservações sobre o Leaky Vessels
Continuaremos atualizando este blog com notícias importantes, incluindo com informações sobre a divulgação de possíveis novas vulnerabilidades relacionadas. Este post inclui links para blogs detalhados sobre cada uma das vulnerabilidades divulgadas, bem como duas ferramentas de código aberto para ajudar na detecção de exploits.
Rory McNamara, pesquisador de segurança da equipe do Snyk Security Labs, identificou quatro vulnerabilidades, apelidadas de "Leaky Vessels", nos componentes principais da infraestrutura de contêineres. Essas vulnerabilidades permitem escapar dos contêineres. Um invasor poderia usar esses escapes de contêiner para obter acesso não autorizado de dentro do contêiner ao sistema operacional do host subjacente. Depois de obter esse acesso, seria possível acessar qualquer dado do sistema, incluindo dados confidenciais (credenciais, informações de clientes etc.) e lançar novos ataques. Após a descoberta e verificação, a equipe do Security Labs iniciou o processo de divulgação responsável das vulnerabilidades, começando por notificar o Docker. Após uma revisão, o Docker encaminhou uma das vulnerabilidades ao grupo de segurança runc de código aberto. Veja a seguir a cronologia da divulgação.
Como essas vulnerabilidades afetam componentes amplamente utilizados do mecanismo de contêineres e ferramentas de compilação de contêineres de baixo nível, a Snyk recomenda enfaticamente que os usuários verifiquem a disponibilidade de atualizações dos fornecedores de compilação e runtime de contêineres, incluindo Docker, Kubernetes, serviços de contêineres na nuvem e comunidades de código aberto. Atualize os sistemas que executam mecanismos de contêineres e ferramentas de compilação de contêineres assim que as correções forem liberadas pelos fornecedores.
Sobre as vulnerabilidades
Em 31 de janeiro de 2024, os mantenedores do runc, uma ferramenta de CLI para gerar e executar contêineres no Linux, anunciaram uma vulnerabilidade (CVE-2024-21626) que permite uma fuga da ordem de operações em contêineres baseada no comando WORKDIR. A exploração dessa vulnerabilidade pode resultar em um escape do contêiner para o sistema operacional do host subjacente. Isso poderia ocorrer executando uma imagem maliciosa ou compilando uma imagem de contêiner com um Dockerfile ou imagem upstream maliciosa (por exemplo, ao usar FROM). De acordo com os mantenedores, uma versão corrigida, runc 1.1.12, foi lançada em 31 de janeiro de 2024, por volta das 15h do horário da Costa Leste.
Você pode ler mais detalhes neste blog resumido, que descreve a vulnerabilidade do runc em si. Além disso, Rory e a equipe do Snyk Labs identificaram outras três vulnerabilidades de escape de contêiner. Confira todas as quatro abaixo, com links para as respectivas CVEs e blogs de visão geral:
CVE-2024-21626: fuga de contêiner do process.cwd e fds vazado do runc
CVE-2024-23653: verificação de privilégio do SecurityMode do gRPC do buildkit
CVE-2024-23652: exclusão arbitrária de desmontagem de contêiner em tempo de compilação do buildkit
Ferramentas da Snyk disponíveis para ajudar a detectar essas vulnerabilidades
As vulnerabilidades citadas afetam a infraestrutura subjacente de contêineres e ferramentas de compilação, em vez de imagens de contêiner. O Snyk Container foi projetado para ajudar os desenvolvedores a eliminar vulnerabilidades de imagens de contêiner. Por isso, essas vulnerabilidades estão fora do escopo de avaliação atual do projeto dos produtos da Snyk. No entanto, a Snyk desenvolveu duas ferramentas de código aberto que servem como implementações de referência para detectar tentativas de exploit. Essas ferramentas não estão cobertas pelo suporte da Snyk, mas são exemplos para a comunidade.
Detecção de exploit de runtime (leaky-vessels-runtime-detector)
A nova equipe Helios da Snyk criou uma ferramenta de detecção de runtime para essa vulnerabilidade que pode ser encontrada em leaky-vessels-runtime-detector, lançada sob a licença Apache-2.0. Autônoma e lançada sob a licença Apache-2.0, ela oferece uma implementação de referência para detectar as vulnerabilidades conforme são executadas. A ferramenta vincula hooks eBPF a funções de kernel e usuário e a um detector de pacotes. Isso permite relatar invocações de compilação e execução de contêineres que correspondem a qualquer padrão que indique uma possível tentativa de exploração. Nem todas as distribuições ou versões do Linux oferecem suporte ao eBPF. É improvável que os clientes possam utilizá-lo em provedores de serviços de nuvem.
Detecção de comando estático de contêiner (leaky-vessels-static-detector)
A segunda ferramenta é um programa de análise estática, leaky-vessels-static-detector, também lançada sob a licença Apache-2.0, que verifica Dockerfiles e camadas de imagem para detectar comandos que aparentam tentar explorar as vulnerabilidades. Ela gera uma saída no formato JSON que indica se detectou algum comando suspeito. É importante notar que cada ocorrência precisará ser inspecionada manualmente para determinar se é realmente um exploit ou uso legítimo de comandos de compilação de contêiner.
Estamos lançando essas duas ferramentas como código aberto com o objetivo de oferecer à comunidade implementações de referência para detectar possíveis tentativas de exploit. É provável que a ferramenta de runtime ofereça descobertas com um nível mais alto de confiança do que a ferramenta estática. No entanto, considerando a natureza dos exploits e comandos de compilação, as duas ferramentas poderão gerar falsos negativos e falsos positivos. A comunidade pode usar as ferramentas como exemplos para criar suas próprias ou executá-las em seus ambientes. Observe que essas ferramentas não corrigem as vulnerabilidades nem bloqueiam sua exploração, apenas ajudam a identificar áreas de risco. Para os clientes, o caminho mais prudente é atualizar as plataformas de orquestração de contêineres afetadas assim que os patches ficarem disponíveis.
Há exploits ativos?
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. Considerando a natureza dos problemas, a Snyk criou duas ferramentas de código aberto, descritas acima: uma dinâmica para ajudar a demonstrar a detecção das ações das vulnerabilidades no runtime e outra estática para verificar imagens e Dockerfiles como um indicador de possíveis exploits.
Como se preparar para a correção
A correção deve ser feita nos níveis de infraestrutura e ferramentas de código. Fique de olho nos anúncios ou lançamentos, se for o caso, do fornecedor ou do vendedor dos sistemas de compilação e orquestração de contêineres. Você provavelmente precisará atualizar daemons do Docker e implementações do Kubernetes, além de todas as ferramentas de compilação de contêineres que usa em pipelines de CI/CD, em servidores de compilação e nas estações de trabalho dos desenvolvedores. Também é importante verificar os contêineres existentes usando ferramentas como as criadas pela Snyk para determinar se nós de orquestração ou infraestrutura de compilação já foram afetados.
Veja a seguir algumas atualizações que coletamos de ferramentas e serviços amplamente utilizados:
Data | Entidade | Informações |
|---|---|---|
31/01/2024 | Mantenedores do | Lançamento da versão 1.1.12 para abordar as vulnerabilidades relevantes |
31/01/2024 | Snyk | Lançamento das implementações de referência leaky-vessels-dynamic-detector e leaky-vessels-static-detector para a comunidade identificar contêineres e imagens possivelmente suspeitos |
31/01/2024 | containerd | Versão lançada 1.6.28 |
31/01/2024 | Docker | O Docker lançou o buildkit 0.12.5 e o moby 25.0.2 e 24.0.9 |
31/01/2024 | GCP | Lançamento de uma atualização para o |
31/01/2024 | Ubuntu | Lançamento de uma atualização para o |
31/01/2024 | AWS | Lançamento de uma atualização para o |
Anatomia de uma divulgação
A cronologia das vulnerabilidades pode ser complexa, principalmente quando há várias entidades envolvidas. É imperativo que as divulgações sejam tratadas de forma responsável para que malfeitores não tomem conhecimento delas antes da imediata disponibilidade das correções.
Neste caso, as vulnerabilidades foram descobertas há dois meses. Desde então, a Snyk iniciou o processo de divulgação responsável. Veja a seguir a cronologia de alguns marcos importantes no processo.
Período | Item |
|---|---|
Semana de 20/11/2023 | Rory McNamara descobriu as vulnerabilidades. Ele iniciou o processo interno de verificação e pesquisa adicional para validar as descobertas e criar POCs de exploits. |
11/12/2023 | Divulgação inicial enviada ao Docker com todas as vulnerabilidades. O Docker confirmou o recebimento no mesmo dia. |
12/12/2023 | A Snyk recebeu uma solicitação do Docker para encaminhar a vulnerabilidade do WORKDIR à equipe |
13/12/2023 | Rory foi adicionado como colaborador do GitHub Security Advisory (GHSA) para as vulnerabilidades Arbitrary Delete e |
19/12/2023 | Rory foi adicionado como colaborador do GHSA para o WORKDIR pelo |
20/12/2023 | Rory foi adicionado como colaborador do GHSA para a vulnerabilidade de corrida de cache. |
02/01/2024 | CVE do |
17/01/2024 | O |
24/01/2024 | CVEs das vulnerabilidades do Docker atribuídas (CNA do GitHub). |
31/01/2024 | Todas as quatro vulnerabilidades Leaky Vessels foram anunciadas ao público em geral. |
31/01/2024 | O runc lançou a versão 1.1.12, que corrige as vulnerabilidades. |
31/01/2024 | A Snyk lançou as implementações de referência leaky-vessels-dynamic-detector e leaky-vessels-static-detector para a comunidade identificar contêineres e imagens possivelmente suspeitos. |
Cada etapa ao longo do caminho envolve colaboração intra e interorganizacional, não apenas entre organizações comerciais, mas muitas vezes entre as equipes que mantêm os componentes, frequentemente compostas por uma faixa representativa da comunidade.
Sobre a equipe do Snyk Security Labs
A equipe Snyk Security Labs já ajudou a divulgar de forma responsável mais de 3.200 vulnerabilidades nos principais pacotes de diversos ecossistemas. Trabalhamos em estreita colaboração com mantenedores de pacotes de código aberto para garantir que todas as vulnerabilidades sejam tratadas com responsabilidade e eficiência. Nossa experiência em segurança é um dos motivos da confiança conquistada pela Snyk entre tantos nomes importantes do setor de segurança. Se você acreditar que encontrou uma vulnerabilidade e não souber como proceder para sua divulgação responsável, preencha este formulário, e nossas equipes poderão ajudar.
A Snyk foi afetada?
Para obter informações sobre como a Snyk lida com vulnerabilidades no nosso próprio ambiente, acesse o Snyk Trust Portal.
Resumo
Atualizaremos este blog à medida que tivermos mais informações. Realizaremos um webinar na terça-feira, 6 de fevereiro às 11h do horário da Costa Leste: Vulnerabilidades de fuga de contêiner Leaky Vessels – o que você precisa saber. Os especialistas técnicos da Snyk apresentarão uma análise técnica aprofundada de uma das vulnerabilidades Leaky Vessels, suas causas, como pode ser explorada e, o mais importante, como pode ser mitigada com atualizações e monitoramento.
Recomendamos entrar em contato se tiver alguma dúvida sobre as vulnerabilidades. Para as ferramentas de código aberto, crie um ticket nas respectivas ferramentas (dynamic-detector e static-detector) no GitHub ou entre em contato pela comunidade da Snyk no Discord.
Para obter mais informações sobre Leaky Vessels, confira:
Leaky Vessels: explicação da vulnerabilidade do runc (YouTube)
Análise detalhada do Leaky Vessels: como escapar do Docker, um syscall por vez (blog)
Lição prática: vulnerabilidade de fuga de contêiner do process.cwd do runc (Snyk Learn)
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.
Log de alterações
31 de janeiro de 2024, 15h do horário da Costa Leste: Lançamento inicial
31 de janeiro de 2024, 18h do horário da Costa Leste: Adição de URLs das CVEs; adição de atualizações da AWS, containerd, GCP, Docker e Ubuntu
7 de fevereiro de 2024, 13h do horário da Costa Leste: Adição de vídeo do YouTube e links para análises profundas à seção "Resumo"
8 de fevereiro de 2024, 10h do horário da Costa Leste: Adição de aula do Snyk Learn à seção "Resumo"