CVE-2021-3493

Falha de escalonamento de privilégios local no subsistema overlayfs de kernels Ubuntu, causada pela combinação de dois fatores: um patch que a Ubuntu carrega para permitir montagens overlayfs por usuários sem privilégios, e uma lacuna na validação de capabilities de arquivo (file capabilities) frente a user namespaces. Um usuário local sem privilégios pode explorar isso para obter privilégios de root. Não afeta o kernel Linux upstream — é uma vulnerabilidade específica de como a Ubuntu combinou esses dois recursos antes de portar a correção correta.

O kernel Linux valida e converte capabilities de arquivo (xattr security.capability) em relação ao user namespace através da função cap_convert_nscap(). Até a correção upstream, essa validação só era chamada no caminho da syscall setxattr() (em fs/xattr.c), e não dentro de vfs_setxattr(), que é a função genérica usada por sistemas de arquivos em camadas como overlayfs durante operações de copy-up. Isso significa que quando o overlayfs copiava um arquivo com capabilities do layer inferior para o layer superior via vfs_setxattr(), a checagem de user namespace era pulada.

A correção upstream (commit 7c03e2cda4a5, 'vfs: move cap_convert_nscap() call into vfs_setxattr()') moveu a chamada para dentro de vfs_setxattr(), cobrindo todos os caminhos, incluindo overlayfs. Essa correção entrou no kernel 5.10, antes do commit que liberou montagens overlayfs não privilegiadas no upstream (459c7c565ac3, kernel 5.11) — por isso o Linux upstream nunca ficou exposto: quando overlayfs sem privilégios chegou oficialmente, a validação já estava corrigida.

A Ubuntu, porém, carregava seu próprio patch permitindo montagens overlayfs não privilegiadas em kernels anteriores ao 5.11, sem ter portado a correção de cap_convert_nscap() para vfs_setxattr(). Combinado com user namespaces não privilegiados habilitados por padrão, isso deixou uma janela onde um processo dentro de um user namespace podia definir capabilities de arquivo (como cap_setuid) em um arquivo, montar via overlayfs, e o copy-up aplicava a capability sem revalidar contra o namespace real, tornando-a efetiva fora do namespace.

CWE associado pela CISA é CWE-862 (Missing Authorization) — a checagem de autorização que deveria vincular a capability ao user namespace de origem simplesmente não era executada nesse caminho de código.

Pré-requisito central: acesso local autenticado (mesmo sem privilégios) e dois recursos habilitados no kernel Ubuntu afetado — user namespaces não privilegiados (padrão na maioria das instalações Ubuntu) e o patch de montagem overlayfs não privilegiada que a Ubuntu carregava. Sem acesso local, a falha não é explorável; é estritamente escalonamento de privilégios, não execução remota.

Na prática, o atacante cria um user namespace não privilegiado, monta um overlayfs sem privilégios elevados, e manipula a xattr security.capability de um arquivo dentro desse contexto para atribuir uma capability sensível (por exemplo, a que permite trocar UID/GID ou manipular capabilities de processo). Como a conversão/validação relativa ao namespace não ocorre no caminho do copy-up do overlayfs, a capability definida dentro do namespace isolado acaba valendo fora dele, permitindo que o processo do atacante, ao executar o arquivo resultante, adquira privilégios de root no host.

A vulnerabilidade está no catálogo KEV da CISA (adicionada em 2022-10-20, prazo de correção 2022-11-10), confirmando exploração ativa. Existem módulo Metasploit e PoCs públicos, o que reduz bastante a barreira técnica — a exploração é considerada de baixa complexidade para quem já tem uma conta local, típica de cenários de pós-exploração (elevar de usuário shell/serviço comprometido para root) em servidores multiusuário, containers mal configurados ou ambientes compartilhados.

A correção definitiva é atualizar o kernel Ubuntu para as versões corrigidas listadas na USN-4917-1 (por release: 18.04 LTS, 20.04 LTS, 20.10, incluindo variantes aws, azure, gcp, oracle, raspi, kvm, gkeop, oem, hwe). Após a atualização é necessário reiniciar o sistema, e como houve mudança de ABI, módulos de kernel de terceiros precisam ser recompilados e reinstalados — isso normalmente é feito automaticamente ao atualizar os metapacotes padrão (linux-generic, linux-virtual etc.), mas ambientes com módulos customizados fora do gerenciador de pacotes exigem atenção manual.

Se a atualização não for possível de imediato, o controle compensatório real é desabilitar user namespaces não privilegiados (via sysctl, algo como kernel.unprivileged_userns_clone=0 em kernels Ubuntu que expõem esse parâmetro). O custo é relevante: isso quebra funcionalidades que dependem de user namespaces sem privilégios, incluindo sandboxes de navegador, containers rootless e algumas ferramentas de isolamento de aplicação — não é um paliativo gratuito, é uma troca de superfície de ataque por funcionalidade.

Não existe mitigação via WAF ou controle de rede, porque a falha é puramente local, no kernel. Restringir acesso de shell/login a usuários não confiáveis reduz a exposição, mas não elimina o risco em ambientes multiusuário ou onde processos de baixo privilégio podem ser comprometidos remotamente e usados como trampolim.

Exploração é local e não deixa assinatura de rede. Sinais a procurar em auditoria de host: chamadas de syscall mount com sistema de arquivo overlay originadas por UIDs não privilegiados fora de containers esperados; criação de user namespaces por processos não administrativos (via unshare/clone com CLONE_NEWUSER) seguida de operações setxattr envolvendo o atributo security.capability; e escalonamento anômalo de capabilities em processos filhos de sessões de usuário comum. Regras de auditd voltadas a mount(), unshare() e setxattr() com o nome de atributo security.capability, correlacionadas com UID de origem não privilegiado, são o caminho mais viável — mas não há um indicador de rede ou log padrão do fornecedor específico para essa CVE, então a ausência de alerta não implica ausência de tentativa.