Alguns dias atrás a notícia foi divulgada detalhes foram revelados uma vulnerabilidade que foi encontrado na implementação do mecanismo limitação de recursos cgroup v1 no kernel Linux que já está catalogado sob CVE-2022-0492.
Esta vulnerabilidade encontrou se pode ser usado para sair de contêineres isolados e é detalhado que o problema está presente desde o kernel Linux 2.6.24.
Na postagem do blog é mencionado que a vulnerabilidade é devido a um erro lógico no manipulador de arquivos release_agent, portanto, as verificações apropriadas não foram executadas quando o driver foi executado com permissões totais.
O arquivo release_agent é usado para definir o programa que o kernel executa quando um processo termina em um cgroup. Este programa é executado como root com todas as "capacidades" no namespace root. Apenas o administrador deveria ter acesso à configuração release_agent, mas na realidade, as verificações se limitavam a conceder acesso ao usuário root, o que não impedia a alteração da configuração do container ou pelo usuário root não administrativo (CAP_SYS_ADMIN ) .
anteriormente, esse recurso não seria percebido como uma vulnerabilidade, mas a situação mudou com o advento de namespaces de identificador de usuário (namespaces de usuário), que permitem criar usuários root separados em contêineres que não se sobrepõem ao usuário root do ambiente principal.
Em consequência, para um ataque, basta um container que tenha seu próprio usuário root em um espaço de ID de usuário separado para conectar seu manipulador release_agent, que, quando o processo for concluído, será executado com todos os privilégios do ambiente pai.
Por padrão, o cgroupfs é montado em um contêiner somente leitura, mas não há problema em remontar este pseudofs no modo de gravação com direitos CAP_SYS_ADMIN ou criando um contêiner aninhado com um namespace de usuário separado usando a chamada do sistema para parar o compartilhamento, no qual os direitos CAP_SYS_ADMIN estão disponíveis para o contêiner criado.
Ataque pode ser feito tendo privilégios de root em um container isolado ou executando o contêiner sem o sinalizador no_new_privs, que proíbe a obtenção de privilégios adicionais.
O sistema deve ter suporte para namespaces habilitados user (habilitado por padrão no Ubuntu e Fedora, mas não habilitado no Debian e RHEL) e ter acesso ao cgroup v1 raiz (por exemplo, o Docker executa contêineres no cgroup raiz RDMA). O ataque também é possível com privilégios CAP_SYS_ADMIN, caso em que o suporte para namespaces de usuário e acesso à hierarquia raiz do cgroup v1 não é necessário.
Além de sair do contêiner isolado, a vulnerabilidade também permite processos iniciados pelo usuário root sem "capacidade" ou qualquer usuário com direitos CAP_DAC_OVERRIDE (o ataque requer acesso ao arquivo /sys/fs/cgroup/*/release_agent de propriedade do root) para obter acesso a todas as "capacidades" do sistema.
Além dos contêineres, a vulnerabilidade também pode permitir que processos de host raiz sem recursos, ou processos de host não raiz com o recurso CAP_DAC_OVERRIDE, escalem privilégios para recursos completos. Isso pode permitir que os invasores ignorem uma medida de proteção usada por determinados serviços, que removem recursos na tentativa de limitar o impacto se ocorrer um comprometimento.
A Unidade 42 recomenda que os usuários atualizem para uma versão fixa do kernel. Para os contêineres em execução, habilite o Seccomp e certifique-se de que AppArmor ou SELinux esteja habilitado. Os usuários do Prisma Cloud podem consultar a seção “Proteções do Prisma Cloud” para ver as mitigações fornecidas pelo Prisma Cloud.
Observe que a vulnerabilidade não pode ser explorada ao usar os mecanismos de proteção Seccomp, AppArmor ou SELinux para isolamento de contêiner adicional, pois o Seccomp bloqueia a chamada de sistema unshare() e o AppArmor e o SELinux não permitem que o cgroupfs seja montado no modo de gravação.
Por fim, vale ressaltar que foi corrigido nas versões do kernel 5.16.12, 5.15.26, 5.10.97, 5.4.177, 4.19.229, 4.14.266 e 4.9.301. Você pode acompanhar o lançamento de atualizações de pacotes em distribuições nestas páginas: Debian, SUSE, Ubuntu, RHEL, Fedora, Gentoo, Arch Linux.
Finalmente se você estiver interessado em saber mais sobre isso, você pode verificar os detalhes no link a seguir