Reveladas as detalhes da vulnerabilidade (CVE-2022-0492) na implementação do mecanismo de limitação de recursos cgroups v1 no núcleo Linux, que pode ser explorada para sair de contêineres isolados. O problema se manifesta a partir do núcleo Linux 2.6.24 e foi corrigido nas versões do núcleo 5.16.12, 5.15.26, 5.10.97, 5.4.177, 4.19.229, 4.14.266 e 4.9.301. É possível acompanhar a publicação de atualizações de pacotes nas distribuições nas seguintes páginas: Debian, SUSE, Ubuntu, RHEL, Fedora, Gentoo, Arch Linux.
A vulnerabilidade é causada por um erro lógico no manipulador de arquivos release_agent, que não realizava as devidas verificações ao iniciar o manipulador com um conjunto completo de permissões. O arquivo release_agent é usado para determinar o programa executado pelo núcleo ao encerrar um processo em um cgroup. Este programa é executado com privilégios de root e com todas as "capabilities" no espaço de nomes raiz. Supunha-se que apenas o administrador teria acesso à configuração do release_agent, mas na prática, as verificações eram limitadas ao acesso concedido ao usuário root, o que não excluía a possibilidade de alterar a configuração a partir de um contêiner ou por um usuário root sem privilégios de administrador (CAP_SYS_ADMIN).
Anteriormente, tal característica não teria sido percebida como uma vulnerabilidade, mas a situação mudou com a introdução dos espaços de nomes de identificadores de usuários (user namespaces), que permitem criar contêineres com usuários root distintos, não sobrepondo-se ao usuário root do ambiente principal. Assim, para a ataque, é suficiente que, em um contêiner que possui seu próprio usuário root em um espaço de identificadores de usuários separado, o manipulador release_agent seja conectado, que será executado com total privilégio no ambiente principal após o término do processo.
Por padrão, o cgroupfs é montado no contêiner em modo somente leitura, mas não há problema em re-montar este pseudo-sistema de arquivos em modo de escrita com a permissão CAP_SYS_ADMIN ou através da criação, utilizando a chamada de sistema unshare, de um contêiner interno com um espaço de nomes de usuário separado, no qual os direitos CAP_SYS_ADMIN estão disponíveis para o contêiner criado.
Um ataque pode ser realizado com privilégios de root em um contêiner isolado ou ao iniciar o contêiner sem a flag no_new_privs, que proíbe a obtenção de privilégios adicionais. O suporte a namespaces de usuários deve estar ativado no sistema (ativado por padrão no Ubuntu e Fedora, mas não ativado no Debian e RHEL) e deve haver acesso ao cgroup raiz v1 (por exemplo, o Docker executa contêineres no cgroup RDMA raiz). O ataque também é possível com privilégios CAP_SYS_ADMIN, caso em que o suporte a namespaces de usuários e o acesso à hierarquia raiz do cgroup v1 não são necessários.
Além da saída do contêiner isolado, a vulnerabilidade também permite que processos executados pelo usuário root sem "capabilities" ou qualquer usuário com permissões CAP_DAC_OVERRIDE (para o ataque, é necessário acesso ao arquivo /sys/fs/cgroup/*/release_agent, que pertence ao root) acessem todas as "capabilities" do sistema.
Observa-se que a vulnerabilidade não pode ser explorada ao aplicar mecanismos de proteção como Seccomp, AppArmor ou SELinux para isolamento adicional de contêineres, pois o Seccomp bloqueia chamadas de sistema unshare(), e o AppArmor e o SELinux não permitem montar o cgroupfs em modo de gravação.
Fonte: opennet.ru
