CVE-2022-2586

Use-after-free no subsistema nf_tables (netfilter) do kernel Linux: uma regra, objeto ou expressão pode referenciar, pelo ID, um set (ou chain) pertencente a outra tabela nf_tables dentro do mesmo batch netlink. Quando a tabela original é removida, a referência cruzada sobrevive e aponta para memória já liberada. Está no catálogo KEV da CISA com exploração confirmada e foi demonstrada como escalonamento de privilégio local no Pwn2Own, mas exige uma capability específica que nem todo ambiente concede a usuários comuns.

A falha é um use-after-free (CWE-416) na API de configuração do nf_tables, em net/netfilter/nf_tables_api.c. Ao processar um batch de comandos netlink que cria set, chain ou rule referenciando um objeto existente por ID (NFTA_*_ID), as funções de lookup — nft_set_lookup_byid, nft_chain_lookup_byid e a resolução de RULE_ID — não verificavam se o objeto encontrado pertencia à mesma tabela que havia sido resolvida por nome no início da transação. Isso permite que uma expressão de um table A acabe vinculada, internamente, a um set ou chain que pertence a um table B.

O bug foi introduzido pelo commit 958bee14d071 ("netfilter: nf_tables: use new transaction infrastructure to handle sets"), presente desde v3.16-rc1 — ou seja, o código vulnerável existe há quase uma década de histórico do kernel. Quando o atacante remove a tabela B (ou a tabela cujo objeto foi referenciado erroneamente), a estrutura nft_set ou nft_chain é liberada, mas o ponteiro guardado na regra/expressão do table A continua acessível e será dereferenciado em uso, remoção ou processamento posterior — clássico UAF explorável para corrupção de memória controlada.

O mesmo padrão de erro afeta três caminhos distintos, corrigidos em três patches separados: lookup de set por ID (SET_ID), lookup de chain por ID (CHAIN_ID, usado tanto em novas rules quanto em verdicts) e lookup de rule por ID dentro de um chain (RULE_ID). Nos três casos a correção é a mesma: comparar o campo table (ou chain) do objeto retornado contra a tabela/chain já resolvida pelo nome antes de aceitar a referência.

A exploração parte do namespace de rede/usuário: o atacante precisa enviar mensagens netlink NFT_MSG em um batch para criar tabelas, sets, chains e rules, manipulando os IDs internos (SET_ID/CHAIN_ID/RULE_ID) para forçar uma referência cruzada entre tabelas, e depois disparar a remoção da tabela cuja referência foi capturada indevidamente. Isso dispara o UAF, que pesquisadores do Team Orca of Sea Security (trabalhando com a ZDI) demonstraram ser explorável para escalonamento de privilégio local, submetido no Pwn2Own e catalogado como ZDI-CAN-17470.

O pré-requisito real, segundo o próprio relato de descoberta no oss-security, é possuir CAP_NET_ADMIN em qualquer user namespace ou network namespace — não necessariamente root global. Em distribuições que permitem criação de user namespaces não privilegiados por usuários comuns (comportamento padrão em várias distros Linux), um processo sem privilégio nenhum pode criar seu próprio namespace, obter CAP_NET_ADMIN dentro dele e manipular nf_tables livremente, tornando a barreira de entrada baixa mesmo sem acesso root prévio.

A divergência entre a nota CVSS 5.3 (AV:L/AC:H/PR:L/S:U/C:N/I:L/A:H) publicada oficialmente e a nota 8.8 atribuída pela ZDI (AV:L/AC:L/PR:L/S:C/C:H/I:H/A:H) reflete avaliações diferentes de impacto: a ZDI trata o resultado como comprometimento total do sistema (execução de código como root), enquanto o vetor oficial assume impacto mais restrito. Como está listada no KEV da CISA, há confirmação de exploração ativa — mas a lista KEV não substitui a leitura do pré-requisito de CAP_NET_ADMIN ao dimensionar o risco em um ambiente específico.

A correção definitiva está nos três patches enviados por Thadeu Cascardo (Canonical) à lista netfilter-devel em agosto de 2022, que passam a validar que o set, o chain ou a rule referenciados por ID pertencem à mesma tabela resolvida por nome antes de aceitar a operação. Esses patches foram incorporados ao kernel mainline e retroportados por distribuições — a Ubuntu, por exemplo, publicou USN-5557-1 e notices relacionadas (USN-5560-1/2, USN-5562-1, USN-5564-1, USN-5565-1) cobrindo múltiplos sabores de kernel; para Ubuntu 16.04 e 14.04 as versões corrigidas específicas são linux-image 4.4.0-231.265 (16.04) e 4.4.0-231.265~14.04.1 (14.04), entre outras variantes (aws, kvm, lowlatency) listadas na mesma notice. Para outras distribuições e para o kernel mainline, aplique o patch correspondente da sua árvore ou atualize para a versão de kernel que seu fornecedor apontar como corrigida — as fontes disponíveis não trazem um número de versão mainline única e confirmada.

Como mitigação paliativa quando a atualização de kernel não é imediata, restringir a criação de user namespaces não privilegiados (via sysctl kernel.unprivileged_userns_clone=0 em distros que o suportam, ou mecanismos equivalentes de hardening de namespace) reduz a superfície de ataque, já que o pré-requisito prático é obter CAP_NET_ADMIN via namespace. Isso não elimina o risco para usuários que já possuem CAP_NET_ADMIN por outro motivo (containers com privilégios de rede, por exemplo), apenas reduz o vetor mais acessível.

Não existe mitigação via configuração de firewall ou WAF, porque a falha está na camada de gerenciamento do próprio nf_tables via netlink, não em tráfego de rede filtrado pelas regras. Atualizar o kernel (ou aplicar os três patches) é a única correção que trata a causa raiz nos três caminhos de lookup por ID.

Não há assinatura de rede confiável: a exploração ocorre inteiramente via netlink local (mensagens NFT_MSG em batch), sem tráfego de rede observável por um IDS/IPS de perímetro. Em auditoria local, sinais possíveis incluem: criação incomum de user namespaces não privilegiados seguida de manipulação intensa de tabelas/sets/chains nf_tables por um processo sem privilégio de root herdado; crashes de kernel com relatos de KASAN mencionando use-after-free em nf_tables_api.c; e, via auditd/eBPF, sequências de operações NFT_MSG_NEWSET/NEWCHAIN/NEWRULE com IDs referenciando entidades de tabelas distintas seguidas de remoção de tabela. Nenhuma dessas heurísticas é um indicador definitivo publicado por fornecedor ou pesquisador — a detecção depende de instrumentação de auditoria de syscalls/netlink específica do ambiente.