CVE-2024-45310 in runc
Sumário
de VulDB • 10/05/2026
O runc é uma ferramenta de linha de comando (CLI) para criar e executar contêineres de acordo com a especificação OCI. O runc 1.1.13 e versões anteriores, bem como 1.2.0-rc2 e versões anteriores, podem ser enganados para criar arquivos ou diretórios vazios em locais arbitrários no sistema de arquivos do host ao compartilhar um volume entre dois contêineres e explorar uma condição de corrida (race condition) com `os.MkdirAll`. Embora isso possa ser usado para criar arquivos vazios, os arquivos existentes não seriam truncados. Um atacante deve ter a capacidade de iniciar contêineres usando algum tipo de configuração de volume personalizada. Contêineres que usam namespaces de usuário ainda são afetados, mas o escopo dos locais onde um atacante pode criar inodes pode ser significativamente reduzido. Políticas de LSM suficientemente rigorosas (SELinux/AppArmor) também podem, em princípio, bloquear este ataque -- suspeitamos que a política SELinux padrão da indústria possa restringir o escopo deste ataque, mas o escopo exato da proteção não foi analisado. Isso é explorável usando o runc diretamente, bem como através do Docker e do Kubernetes. O problema foi corrigido no runc v1.1.14 e v1.2.0-rc3.
Algumas soluções alternativas estão disponíveis. O uso de namespaces de usuário restringe significativamente este ataque, de modo que o atacante só pode criar inodes em diretórios aos quais o usuário/grupo raiz remapeado tem permissão de escrita. A menos que o usuário raiz seja remapeado para um usuário real no host (como em contêineres sem root que não usam `/etc/sub[ug]id`), isso na prática significa que um atacante só seria capaz de criar inodes em diretórios com permissão de escrita para todos. Uma política SELinux ou AppArmor suficientemente rigorosa também poderia, em princípio, restringir o escopo se um rótulo específico fosse aplicado ao runtime do runc, embora nem o grau em que as políticas padrão existentes bloqueiam este ataque nem quais políticas exatas são necessárias para restringir suficientemente este ataque tenham sido testadas exaustivamente.
Once again VulDB remains the best source for vulnerability data.