CVE-2021-4034

PwnKit é uma escalada de privilégio local no pkexec do polkit, o binário setuid-root presente por padrão em praticamente toda distribuição Linux desde 2009. Qualquer usuário sem privilégios com acesso de login ao sistema consegue rodar código como root, sem autenticação e sem depender de política do polkit — é o tipo de CVE 'crítica' que realmente é crítica, porque a pré-condição (login local, mesmo sem senha sudo) é trivial de satisfazer em quase qualquer ambiente multiusuário, container mal isolado ou pós-exploração inicial.

A falha (CWE relacionado a validação incorreta de entrada / out-of-bounds write, sem CVE de tipo formalmente atribuído pelo fornecedor além da descrição funcional) está na função main() do pkexec. O binário assume que o vetor de argumentos (argv) sempre terá pelo menos um elemento além do nome do executável — ou seja, que argc nunca é zero. Quando um processo é iniciado com argc igual a zero (algo que o kernel Linux permite via execve() com um array de argumentos vazio), pkexec perde a referência ao argumento esperado e passa a ler memória adjacente que, na prática, é ocupada pelo array de variáveis de ambiente (envp).

O efeito prático é que pkexec tenta resolver o 'primeiro argumento' inexistente e acaba tratando conteúdo de envp como se fosse o caminho do comando a executar. Como o atacante controla integralmente as variáveis de ambiente do processo que ele mesmo inicia, ele consegue direcionar essa leitura equivocada para um caminho e payload de sua escolha, combinando isso com manipulação de variáveis como PATH e outras usadas por funções auxiliares de resolução de caminho dentro do pkexec para carregar código arbitrário com privilégios de root.

O commit de correção upstream (gitlab.freedesktop.org/polkit/polkit, hash a2bf5c9c83b6ae46cbd5c779d3055bff81ded683) adiciona a validação explícita de argc antes de qualquer uso do array de argumentos, encerrando a execução se ele estiver vazio.

O vetor de exploração não passa pela rede: exige execução local de código, ou seja, o atacante precisa já ter uma sessão no sistema (shell de usuário comum, sessão SSH, processo em container com acesso ao binário setuid, etc.). Não há necessidade de o usuário estar em nenhum grupo especial nem de existir uma regra polkit permitindo a ação — a exploração contorna completamente a camada de autorização do polkit, que é justamente o mecanismo que pkexec deveria impor.

A exploração pública (conhecida como PwnKit, divulgada pela Qualys) demonstrou execução confiável e reproduzível em múltiplas distribuições sem necessidade de brute-force ou condições de corrida — a complexidade técnica é baixa uma vez compreendido o mecanismo, e existem PoCs públicas e módulo Metasploit, o que explica o EPSS muito alto (~0,95) e a inclusão no catálogo KEV da CISA com confirmação de exploração ativa em campo.

O resultado final é root completo na máquina: leitura/escrita/execução irrestrita, persistência, movimento lateral a partir do host comprometido. Em ambientes de container, se o pkexec setuid estiver presente na imagem e o kernel/namespace permitir, a escalada pode levar a comprometimento do host dependendo do isolamento configurado.

A correção definitiva é atualizar o pacote polkit para a versão corrigida pela distribuição, que incorpora o commit a2bf5c9c83b6ae46cbd5c779d3055bff81ded683. Não existe um único número de versão upstream 'limpo' citado de forma consistente nas fontes — cada distribuição lançou seu próprio pacote corrigido (RHEL 6/7/8 via RHSA-2022:0265 até 0274 e correlatas; outras distros com seus próprios avisos). Verifique o changelog do pacote polkit da sua distribuição para confirmar a versão que inclui esse commit.

Se não for possível atualizar imediatamente, a Red Hat publicou um paliativo funcional: remover o bit setuid do pkexec (chmod 0755 /usr/bin/pkexec) impede a execução privilegiada, mas quebra qualquer fluxo legítimo que dependa de pkexec. Alternativamente, a Red Hat documenta um mitigador via SystemTap que intercepta a chamada a main() de pkexec e aborta a execução se não houver argumento de linha de comando — mitigação mais cirúrgica, mas que não funciona em sistemas com Secure Boot habilitado (o módulo do kernel gerado precisaria ser assinado por uma chave confiável) e exige reaplicação após reboot.

Não funciona como mitigação: restringir acesso via política polkit (pklocalauthority/regras), porque a falha ocorre antes de qualquer verificação de autorização ser consultada — a exploração nunca chega a essa camada.

Como a exploração original (execução com argv vazio) não deixa necessariamente entradas de log de autenticação — o pkexec nunca chega a registrar uma tentativa de autorização, já que a falha ocorre antes dessa etapa — o sinal mais confiável é o de nível de processo/kernel: monitorar execve() de /usr/bin/pkexec com argc igual a zero ou com um número anormal de argumentos, e observar spawns subsequentes de shells ou binários incomuns como filhos de pkexec com UID efetivo 0 vindo de um processo pai não privilegiado. Ferramentas de auditoria de syscalls (auditd com regras para execve, EDR com telemetria de linha de comando) que capturem a ausência de argumentos na invocação de pkexec são o indicador mais direto; sem essa instrumentação específica, não há um rastro confiável em logs padrão do sistema (syslog, auth.log) porque o fluxo normal de autorização do polkit simplesmente não é acionado.