🔥 Fique por dentro das novidades mais quentes do momento! 🔥
Confira agora e compartilhe com seus amigos!
Apoie esse projeto de divulgacao de noticias! Clique aqui
Uma vulnerabilidade de segurança de alta gravidade foi divulgada no Docker Engine e pode permitir que um invasor ignore plug-ins de autorização (AuthZ) em circunstâncias específicas.
A vulnerabilidade, rastreada como CVE-2026-34040 (pontuação CVSS: 8,8), decorre de uma correção incompleta para CVE-2024-41110, uma vulnerabilidade de gravidade máxima no mesmo componente que veio à tona em julho de 2024.
“Usando uma solicitação de API especialmente criada, um invasor pode fazer com que o daemon do Docker encaminhe a solicitação para um plugin de autorização sem o corpo”, disseram os mantenedores do Docker Engine em um comunicado divulgado no final do mês passado. "O plug-in de autorização pode permitir uma solicitação que de outra forma teria sido negada se o órgão tivesse sido encaminhado a ele."
“Qualquer pessoa que dependa de plug-ins de autorização que examinam o corpo da solicitação para tomar decisões de controle de acesso será potencialmente impactada.”
Múltiplas vulnerabilidades de segurança, incluindo Asim Viladi Oglu Manizada, Cody, Oleh Konko e Vladimir Tokarev, foram creditadas por descobrir e relatar o bug de forma independente. O problema foi corrigido no Docker Engine versão 29.3.1.
De acordo com um relatório publicado pelo pesquisador do Cyera Research Labs, Tokarev, a vulnerabilidade decorre do fato de que a correção para CVE-2024-41110 não lidou adequadamente com corpos de solicitação HTTP superdimensionados, abrindo assim a porta para um cenário em que uma única solicitação HTTP preenchida pode ser usada para criar um contêiner privilegiado com acesso ao sistema de arquivos do host.
Em um cenário de ataque hipotético, um invasor que tenha acesso à API Docker restrito por um plug-in AuthZ pode prejudicar o mecanismo preenchendo uma solicitação de criação de contêiner para mais de 1 MB, fazendo com que ele seja descartado antes de chegar ao plug-in.
"O plug-in permite a solicitação porque não vê nada para bloquear", disse Tokarev em um relatório compartilhado com o The Hacker News. "O daemon do Docker processa a solicitação completa e cria um contêiner privilegiado com acesso root ao host: suas credenciais da AWS, chaves SSH, configurações do Kubernetes e tudo mais na máquina. Isso funciona em todos os plug-ins AuthZ do ecossistema."
Além do mais, um agente de codificação de inteligência artificial (IA) como o OpenClaw executado em uma sandbox baseada em Docker pode ser levado a executar uma injeção de prompt oculta em um repositório GitHub especificamente criado como parte de um fluxo de trabalho regular do desenvolvedor, resultando na execução de código malicioso que explora CVE-2026-34040 para ignorar a autorização usando a abordagem acima e criar um contêiner privilegiado e montar o sistema de arquivos host.
Com esse nível de acesso implementado, o invasor pode extrair credenciais para serviços em nuvem e abusar delas para assumir o controle de contas em nuvem, clusters Kubernetes e até mesmo SSH em servidores de produção.
Não termina aí. Cyera também alertou que os agentes de IA podem descobrir o desvio por conta própria e acioná-lo construindo uma solicitação HTTP preenchida ao encontrar erros ao tentar acessar arquivos como kubeconfig como parte de uma tarefa de depuração legítima emitida por um desenvolvedor (por exemplo, depurar o problema de falta de memória do K8s). Essa abordagem elimina a necessidade de plantar um repositório envenenado contendo instruções maliciosas.
“O plugin AuthZ negou a solicitação de montagem”, explicou Cyera. "O agente tem acesso à API Docker e sabe como o HTTP funciona. CVE-2026-34040 não requer nenhum código de exploração, privilégio ou ferramentas especiais. É uma única solicitação HTTP com preenchimento extra. Qualquer agente que possa ler a documentação da API Docker pode construí-la."
Como soluções temporárias, é recomendável evitar o uso de plug-ins AuthZ que dependem da inspeção do corpo da solicitação para tomar decisões de segurança, limitar o acesso à API do Docker a partes confiáveis seguindo o princípio do menor privilégio ou executar o Docker no modo sem raiz.
“No modo sem root, até mesmo a ‘raiz’ de um contêiner privilegiado é mapeada para um UID de host não privilegiado”, disse Tokarev. “O raio de explosão cai de ‘comprometimento total do host’ para ‘usuário sem privilégios comprometido’. Para ambientes que não podem ficar totalmente sem root, --userns-remap fornece mapeamento UID semelhante."
A vulnerabilidade, rastreada como CVE-2026-34040 (pontuação CVSS: 8,8), decorre de uma correção incompleta para CVE-2024-41110, uma vulnerabilidade de gravidade máxima no mesmo componente que veio à tona em julho de 2024.
“Usando uma solicitação de API especialmente criada, um invasor pode fazer com que o daemon do Docker encaminhe a solicitação para um plugin de autorização sem o corpo”, disseram os mantenedores do Docker Engine em um comunicado divulgado no final do mês passado. "O plug-in de autorização pode permitir uma solicitação que de outra forma teria sido negada se o órgão tivesse sido encaminhado a ele."
“Qualquer pessoa que dependa de plug-ins de autorização que examinam o corpo da solicitação para tomar decisões de controle de acesso será potencialmente impactada.”
Múltiplas vulnerabilidades de segurança, incluindo Asim Viladi Oglu Manizada, Cody, Oleh Konko e Vladimir Tokarev, foram creditadas por descobrir e relatar o bug de forma independente. O problema foi corrigido no Docker Engine versão 29.3.1.
De acordo com um relatório publicado pelo pesquisador do Cyera Research Labs, Tokarev, a vulnerabilidade decorre do fato de que a correção para CVE-2024-41110 não lidou adequadamente com corpos de solicitação HTTP superdimensionados, abrindo assim a porta para um cenário em que uma única solicitação HTTP preenchida pode ser usada para criar um contêiner privilegiado com acesso ao sistema de arquivos do host.
Em um cenário de ataque hipotético, um invasor que tenha acesso à API Docker restrito por um plug-in AuthZ pode prejudicar o mecanismo preenchendo uma solicitação de criação de contêiner para mais de 1 MB, fazendo com que ele seja descartado antes de chegar ao plug-in.
"O plug-in permite a solicitação porque não vê nada para bloquear", disse Tokarev em um relatório compartilhado com o The Hacker News. "O daemon do Docker processa a solicitação completa e cria um contêiner privilegiado com acesso root ao host: suas credenciais da AWS, chaves SSH, configurações do Kubernetes e tudo mais na máquina. Isso funciona em todos os plug-ins AuthZ do ecossistema."
Além do mais, um agente de codificação de inteligência artificial (IA) como o OpenClaw executado em uma sandbox baseada em Docker pode ser levado a executar uma injeção de prompt oculta em um repositório GitHub especificamente criado como parte de um fluxo de trabalho regular do desenvolvedor, resultando na execução de código malicioso que explora CVE-2026-34040 para ignorar a autorização usando a abordagem acima e criar um contêiner privilegiado e montar o sistema de arquivos host.
Com esse nível de acesso implementado, o invasor pode extrair credenciais para serviços em nuvem e abusar delas para assumir o controle de contas em nuvem, clusters Kubernetes e até mesmo SSH em servidores de produção.
Não termina aí. Cyera também alertou que os agentes de IA podem descobrir o desvio por conta própria e acioná-lo construindo uma solicitação HTTP preenchida ao encontrar erros ao tentar acessar arquivos como kubeconfig como parte de uma tarefa de depuração legítima emitida por um desenvolvedor (por exemplo, depurar o problema de falta de memória do K8s). Essa abordagem elimina a necessidade de plantar um repositório envenenado contendo instruções maliciosas.
“O plugin AuthZ negou a solicitação de montagem”, explicou Cyera. "O agente tem acesso à API Docker e sabe como o HTTP funciona. CVE-2026-34040 não requer nenhum código de exploração, privilégio ou ferramentas especiais. É uma única solicitação HTTP com preenchimento extra. Qualquer agente que possa ler a documentação da API Docker pode construí-la."
Como soluções temporárias, é recomendável evitar o uso de plug-ins AuthZ que dependem da inspeção do corpo da solicitação para tomar decisões de segurança, limitar o acesso à API do Docker a partes confiáveis seguindo o princípio do menor privilégio ou executar o Docker no modo sem raiz.
“No modo sem root, até mesmo a ‘raiz’ de um contêiner privilegiado é mapeada para um UID de host não privilegiado”, disse Tokarev. “O raio de explosão cai de ‘comprometimento total do host’ para ‘usuário sem privilégios comprometido’. Para ambientes que não podem ficar totalmente sem root, --userns-remap fornece mapeamento UID semelhante."
Fonte: https://thehackernews.com
#samirnews #samir #news #boletimtec #docker #cve202634040 #permite #que #invasores #ignorem #autorização #e #obtenham #acesso #ao #host
🚀 Mais conteúdos incríveis estão por vir, fique atento!
Postar um comentário