Script de Validação Defensiva para CVE-2026-23111

Visão Geral

CVE-2026-23111 é uma vulnerabilidade do kernel Linux em nf_tables que pode ser explorada para escalonamento de privilégios local por um usuário não privilegiado em sistemas onde namespaces de usuário e nftables estão disponíveis.[1][2] Avisos públicos de fornecedores e governos descrevem-na como um problema local que afeta distribuições Linux e enfatizam a correção como principal solução.[3][4]

Este repositório contém um script de validação defensiva projetado para ajudar a avaliar se um host expõe as condições técnicas associadas a esta CVE sem fornecer um exploit de escalonamento de privilégios. Ele verifica condições relevantes de kernel e tempo de execução, opcionalmente carrega o módulo nf_tables para testes funcionais completos, tenta um caminho de validação não privilegiado controlado usando unshare e nft, coleta rastreios de diagnóstico locais e classifica o host em vereditos operacionais como provavelmente seguro, bloqueado por política local ou caminho exposto disponível.[1][5]

O que é a CVE

De acordo com o NVD, CVE-2026-23111 é uma vulnerabilidade do kernel Linux em nf_tables resolvida como uma correção de bug lógico no netfilter e é explorável para escalonamento de privilégios local a partir de um usuário não privilegiado através de namespaces de usuário e nftables em configurações afetadas.[1] O aviso de segurança da Ubuntu descreve o mesmo caminho de exploração de alto nível e acompanha os estados de pacotes afetados e corrigidos por versão.[2]

A Red Hat afirma que um usuário local com baixos privilégios pode explorar o problema para causar negação de serviço ou potencialmente alcançar escalonamento de privilégios, e documenta um caminho de mitigação baseado em impedir que o módulo nf_tables seja carregado quando isso for operacionalmente aceitável.[3] A orientação nacional do Centro Canadense de Segurança Cibernética também aponta organizações afetadas para atualizações do fornecedor e menciona a regeneração do initramfs quando mitigações de bloqueio de módulo são usadas.[4]

O que o script faz

O script destina-se à avaliação defensiva de exposição, não à exploração. Ele foi projetado para:

• Identificar o kernel em execução, a família de distribuição e as configurações relevantes de hardening em tempo de execução.
• Verificar se CONFIG_USER_NS e CONFIG_NF_TABLES parecem estar presentes.[1]
• Inspecionar kernel.unprivileged_userns_clone e user.max_user_namespaces para estimar se namespaces de usuário não privilegiados estão disponíveis.
• Detectar se uma negação hard do modprobe (install nf_tables /bin/false) ou uma blacklist fraca está em vigor para o módulo nf_tables.
• Verificar o changelog do RPM do kernel do fornecedor quanto a uma entrada de backport da CVE-2026-23111 (somente família RHEL).
• Identificar /proc/kallsyms para o símbolo vulnerável (nft_map_catchall_activate) versus o símbolo pós-correção (nft_catchall_set_activate) antes de qualquer interação com o módulo.
• Opcionalmente carregar nf_tables via modprobe quando for especificado (veja abaixo) e descarregá-lo automaticamente na saída.

O script armazena logs em um subdiretório do diretório do script e os remove por padrão, a menos que --keep-logs seja usado.

Política de carregamento de módulo

Por padrão, o script nunca carrega nf_tables. Se o módulo não estiver carregado quando o script iniciar, todos os testes funcionais de nft são ignorados e o veredito é derivado apenas da versão do kernel, impressão digital do kallsyms, configuração do modprobe, changelog do RPM e evidências de política LSM/sysctl.

Este padrão conservador evita expandir involuntariamente a superfície de ataque em hosts de produção. Para habilitar testes funcionais completos em um sistema controlado ou instrumentado, use --allow-load-module como root (veja abaixo).

Uso

# Padrão — sem carregamento de módulo, veredito apenas baseado em evidências de política
./check_cve_2026_23111.sh
./check_cve_2026_23111.sh --color
./check_cve_2026_23111.sh --keep-logs
./check_cve_2026_23111.sh --color --keep-logs

# Teste funcional completo — carrega (e descarrega) nf_tables, requer root
sudo ./check_cve_2026_23111.sh --allow-load-module
sudo ./check_cve_2026_23111.sh --allow-load-module --color --keep-logs

Opções

Quando usar --allow-load-module

Use --allow-load-module quando precisar do veredito de maior confiança em uma VM de teste isolada, não produtiva ou construída para este fim. Cenários típicos:

• Um kernel na faixa vulnerável está sendo validado antes de implantar a correção do fornecedor.
• O sistema de teste tem KASAN ou outra instrumentação habilitada e você deseja observar rastreios do kernel.
• O módulo não está em uso no host alvo e uma verificação completa de ponta a ponta é necessária para evidências de auditoria.

Não use --allow-load-module em hosts de produção onde nf_tables é intencionalmente bloqueado ou onde carregá-lo violaria uma política de hardening.

Gatilhos de segurança para --allow-load-module

Antes de tentar carregar o módulo, o script aplica as seguintes verificações e sai com erro se alguma falhar:

1. Uma negação hard do modprobe (install nf_tables /bin/false) não deve estar presente em /etc/modprobe.d/.
2. modprobe deve estar disponível no sistema.
3. O script deve estar sendo executado como root (uid 0).

Se o módulo for carregado com sucesso pelo script, modprobe -r nf_tables é chamado na saída via armadilha cleanup(), independentemente de como o script termina (sucesso, erro ou CTRL+C).

Modelo de veredito

O script usa vereditos operacionais em vez de resultados de exploração:

Estes vereditos destinam-se a apoiar a priorização de patches e a triagem defensiva, não a substituir a validação do status do pacote do fornecedor.

Cobertura de versão do kernel

O script mapeia o kernel em execução em relação aos pontos de correção upstream documentados:

Mitigação recomendada

A ação primária recomendada é instalar a atualização do kernel corrigida pelo fornecedor e reiniciar com o kernel corrigido.[2][3][4] Como a exploração depende da superfície de ataque local do kernel, hardening adicional pode reduzir a exposição enquanto a correção está sendo agendada ou validada.[5][6]

Ações prioritárias

1. Corrija o kernel usando o aviso oficial da distribuição e reinicie na versão corrigida.[2][3][4]
2. Restrinja namespaces de usuário não privilegiados onde os requisitos de negócio permitirem, porque o caminho de ataque documentado depende deles estarem disponíveis para usuários não privilegiados.[1][5][6]
3. Desabilite ou bloqueie o carregamento de nf_tables se o sistema não requerer funcionalidade nftables e a alteração tiver sido validada quanto ao impacto operacional.[3][4]
4. Limite capacidades de rede privilegiadas como caminhos de acesso envolvendo CAP_NET_ADMIN e reduza o número de contas que podem manipular o estado do firewall.[5]

Exemplos de etapas de hardening

Restrinja namespaces de usuário não privilegiados:

echo 'kernel.unprivileged_userns_clone=0' > /etc/sysctl.d/99-cve-2026-23111.conf
echo 'user.max_user_namespaces=0' >> /etc/sysctl.d/99-cve-2026-23111.conf
sysctl --load /etc/sysctl.d/99-cve-2026-23111.conf

Bloqueie o carregamento do módulo nf_tables quando operacionalmente seguro:

echo 'install nf_tables /bin/false' > /etc/modprobe.d/disable-nf_tables.conf
rmmod nf_tables 2>/dev/null || true

Se uma mitigação de carregamento de módulo for usada, algumas orientações recomendam regenerar o initramfs para que o módulo bloqueado não seja carregado durante a inicialização inicial.[4]

Nota específica para Ubuntu

A Ubuntu documenta restrições baseadas em AppArmor para namespaces de usuário não privilegiados como uma forma de reduzir a superfície de ataque, em vez de um substituto completo para correções do kernel.[6] Um host pode parecer menos exposto em testes de tempo de execução porque o caminho de ataque está bloqueado localmente, enquanto a remediação de longo prazo ainda requer a instalação do pacote do kernel corrigido pelo fornecedor.[2][6] O script valida a eficácia das restrições do AppArmor tentando uma invocação real de unshare --user e verificando se CAP_NET_ADMIN dentro de um namespace de usuário+rede é funcional.

Nota específica para Red Hat

A Red Hat lista explicitamente impedir que o módulo nf_tables seja carregado como uma mitigação para CVE-2026-23111 quando essa alteração for apropriada para o ambiente.[3] O script detecta esta configuração via check_modprobe_deny() e distingue entre uma negação hard (install nf_tables /bin/false, que bloqueia o carregamento sob demanda) e uma blacklist fraca (que não bloqueia). Em sistemas da família RHEL, o script também inspeciona o changelog do RPM do kernel em execução quanto a uma entrada de backport da CVE-2026-23111, permitindo um veredito confirmado pelo fornecedor independente do número da versão upstream.

Referências oficiais

• NVD: Detalhes CVE-2026-23111 [1]
• Segurança Ubuntu: CVE-2026-23111 [2]
• Segurança Red Hat: CVE-2026-23111 [3]
• Aviso do Centro Canadense de Segurança Cibernética: AL26-011 [4]
• Visão geral da restrição de namespace de usuário AppArmor Ubuntu: Understanding AppArmor User Namespace Restriction [6]

Escopo e segurança

Este README e o script complementar destinam-se à validação defensiva, inventário e planejamento de mitigação. Eles não substituem as orientações do fornecedor, a verificação em nível de pacote ou os processos padrão de gerenciamento de patches, e não devem ser usados como substituto para a aplicação das correções oficiais descritas nos avisos vinculados.[2][3][4]

📚 Repositório de Pesquisa Educacional em Segurança

Um repositório para aprender, testar e pesquisar conceitos de segurança cibernética em ambientes controlados.

⚠️ Isenção de Responsabilidade de Segurança e Legal

Finalidade

Este repositório é para fins educacionais e pesquisa de segurança autorizada apenas.

Ele foi projetado para ajudar os usuários a aprender sobre:

• Vulnerabilidades de segurança
• Conceitos de sandbox e isolamento
• Práticas de codificação segura e defensiva

Uso Autorizado Apenas

Use este repositório apenas em ambientes onde você tenha permissão, como:

• Laboratórios pessoais ou máquinas virtuais
• Docker ou ambientes isolados
• Testes de penetração autorizados
• Treinamento em segurança cibernética ou pesquisa acadêmica

O uso não autorizado ou ilegal é estritamente proibido.

Sem Responsabilidade

O autor e contribuidores não são responsáveis por qualquer dano, uso indevido, questões legais ou perdas causadas por este projeto.

Ao usar este repositório, você concorda que:

• Você é responsável por suas próprias ações
• Você o usará legal e eticamente
• O projeto é fornecido sem garantia

Uso Ético

Este projeto destina-se a:

• Pesquisa defensiva de segurança
• Educação em segurança cibernética
• Conscientização sobre vulnerabilidades
• Pesquisa em sistemas e software seguros

Por favor, siga práticas de divulgação responsável e cumpra todas as leis aplicáveis.

Contato

Para divulgação responsável ou colaboração, entre em contato com o mantenedor do repositório através do GitHub.