CVE-2022-0492

Falha no cgroup v1 (kernel/cgroup/cgroup-v1.c) que permite escalonamento de privilégio e escape de container através do mecanismo release_agent do cgroups v1. O código não exigia nenhuma capability para configurar o release_agent, permitindo que um processo confinado a um user namespace não privilegiado (por exemplo, dentro de um container) conseguisse fazer o kernel do host executar um binário arbitrário com todas as capabilities. É bug antigo (presente desde a introdução do recurso, kernel 2.6.24), não uma regressão recente — e está no catálogo KEV da CISA com exploração confirmada.

cgroup v1 tem um recurso chamado release_agent: quando um cgroup fica vazio (último processo saiu) e a flag notify_on_release está ativa, o kernel invoca via call_usermodehelper() o binário apontado pelo arquivo release_agent daquele hierarchy. O problema é que call_usermodehelper() executa esse binário com o conjunto completo de capabilities do kernel, independentemente de quem configurou o caminho. Antes do patch, a função cgroup_release_agent_write() não fazia nenhuma verificação de capability ao aceitar uma escrita no arquivo release_agent — a única barreira era a permissão de arquivo do próprio cgroupfs.

Isso quebra o isolamento de user namespace: um processo que tem CAP_SYS_ADMIN apenas dentro do seu próprio user namespace (não no init_user_ns, ou seja, sem ser 'root real' do host) ainda conseguia escrever no release_agent se tivesse acesso de escrita ao cgroupfs v1 montado. O atacante controla integralmente o conteúdo do arquivo release_agent (caminho para um script/binário arbitrário) e o momento do disparo (basta esvaziar o cgroup, matando os processos dentro dele).

O commit de correção (24f6008564183aa120d07c03d9289519c2fe02af, de Eric W. Biederman, reportado por Tabitha Sable) adiciona a checagem explícita: a escrita só é permitida se of->file->f_cred->user_ns == init_user_ns E o processo tem CAP_SYS_ADMIN nesse namespace real. A mesma checagem foi replicada em cgroup1_parse_param() para o caso de montagem com a opção release_agent= diretamente. Classificação equivalente a CWE-284 (Improper Access Control) / CWE-269 (Improper Privilege Management).

O vetor é estritamente local (AV:L) e exige privilégio prévio baixo (PR:L) — não é uma falha remota. O cenário mais citado é escape de container: um processo dentro de um container ou namespace isolado que tenha, dentro do seu próprio user namespace, CAP_SYS_ADMIN (comum em containers privilegiados, em setups que permitem user namespaces sem privilégio, ou quando o cgroupfs v1 é montado com escrita dentro do container) consegue escrever no arquivo release_agent do cgroup, apontando para um script controlado pelo atacante. Ao esvaziar o cgroup (removendo todos os processos dele), o kernel do host dispara esse script via call_usermodehelper() com capabilities plenas, rodando fora do isolamento original.

A pré-condição real que a manchete 'privilege escalation crítica' esconde: é necessário já ter algum nível de acesso privilegiado dentro de um namespace (tipicamente CAP_SYS_ADMIN local, seja de um usuário do sistema com acesso a cgroupfs v1, seja de um processo em container com essa capability) e acesso de escrita ao cgroupfs v1 montado. Ambientes que usam exclusivamente cgroup v2, que desabilitam user namespaces não privilegiados, ou que já bloqueiam a escrita em cgroupfs via SELinux/AppArmor, reduzem ou eliminam a superfície.

Há exploração ativa confirmada (presença no catálogo KEV da CISA), módulo Metasploit público e PoCs disponíveis, o que tornou a falha atrativa para ferramentas de escape de container em ambientes CI/CD e multi-tenant mal configurados.

A correção definitiva é atualizar o kernel para uma versão que inclua o commit 24f6008564183aa120d07c03d9289519c2fe02af. No upstream, isso entrou na série stable 5.16.6 e foi incluído no mainline a partir de 5.17-rc3. Distribuições fizeram backport: Debian LTS corrigiu no pacote linux 4.9.303-1 (DLA-2940-1) e linux-4.19 4.19.232-1~deb9u1 (DLA-2941-1); Red Hat corrigiu via múltiplas erratas RHSA para RHEL 8 e variantes EUS/SAP (ver RHSA-2022:0819 a 2022:5157 listadas no bug 2051505). Fedora corrigiu com o kernel 5.16.6. Verifique a errata específica da sua distribuição — não existe um número de versão único válido para todos os ramos.

Se não for possível atualizar imediatamente, mitigação real (não cosmética): evitar montar cgroupfs v1 com escrita dentro de containers, não usar containers com --privileged ou CAP_SYS_ADMIN concedido sem necessidade, e restringir ou desabilitar user namespaces não privilegiados via sysctl (onde a distribuição suportar essa opção). O comentário de um mantenedor da Red Hat no bug 2051505 confirma que, no OpenShift, a política SELinux enforcing por padrão já bloqueia esse escape específico mesmo sem o patch — SELinux/AppArmor em modo enforcing atuando sobre o binário do release_agent é um controle compensatório validado, não um mito. Migrar para cgroup v2 (que não expõe o mesmo mecanismo de release_agent da forma vulnerável) também reduz a superfície, mas exige testar compatibilidade com o runtime de containers em uso.

Monitorar escritas em arquivos release_agent e notify_on_release dentro de hierarquias cgroupfs v1 (ex.: /sys/fs/cgroup//release_agent) via auditd ou eBPF, especialmente originadas de processos dentro de containers ou user namespaces não confiáveis. Em kernels já corrigidos, tentativas de exploração aparecem como falhas de permissão (-EPERM) ao escrever nesse arquivo, o que pode ser logado por auditd se houver regra para chamadas write/openat nesses caminhos. Não há assinatura de rede confiável, pois o ataque é inteiramente local ao kernel — a detecção depende de instrumentação de syscalls/LSM (auditd, SELinux AVC denials, ferramentas de runtime security) e não de tráfego observável.