Dezenove anos. Um hook de validação faltando. Qualquer usuário local vira root. O CIFSwitch é a prova de que infraestrutura legítima — keyrings, namespaces, NSS — vira arma quando a trust boundary não é enforceada. Descoberta por Asim Manizada, security engineer na SpaceX, com assistência de IA via graph reasoning. Divulgada em 28 de maio após embargo coordenado. CVE pendente. PoC público. Servidores enterprise expostos. Na Tech86, auditamos infraestrutura Linux com foco em superfícies de ataque kernel — e essa vulnerabilidade confirma algo que sabemos por experiência: o maior risco não é o bug zero-day, é o bug que esteve lá por quase duas décadas sem que ninguém notasse.
O mecanismo: request_key confia sem validar
O kernel Linux usa keyrings para gerenciar credenciais Kerberos em mounts CIFS/SMB. Quando um mount precisa de autenticação, o kernel invoca request_key("cifs.spnego", descrição). Essa chamada dispara o helper cifs.upcall, que roda como root. O problema: o kernel nunca validou a origem da requisição. Qualquer usuário — sem privilégio algum — pode chamar request_key() com uma descrição forjada. O helper executa como root e confia nos campos como se eles viessem do kernel. Não há verificação de que o solicitante tem permissão para solicitar aquela key. Não há validação de que os campos na descrição são legítimos. O upcall acontece antes de qualquer checagem. Quando o kernel rejeita a key, já é tarde — o helper já executou como root dentro do namespace do atacante.
Esse bug existe desde 2007. O código vulnerável esteve no kernel por quase duas décadas. A cadeia completa de exploração, no entanto, só se tornou viável em 2013, quando user namespaces não privilegiados entraram no Linux 3.8. O bug ficou dormente por 6 anos, esperando a peça que faltava — a capacidade de criar um namespace sem privilégio para controlar o ambiente onde o helper executa.
A cadeia de exploração: 6 passos para root
O exploit segue uma cadeia precisa e determinística:
- O atacante cria um user namespace com um
nsswitch.conffalso e um módulo NSS malicioso - Chama
request_key("cifs.spnego", descrição_forjada)com pid, uid eupcall_targetcontrolados cifs.upcallroda como root e entra no namespace do atacante viaupcall_target=app- Antes do drop de privilégio, o lookup NSS carrega o módulo do atacante como root
- O módulo escreve em
/etc/sudoers.d/comNOPASSWD: ALL sudo. Root shell.
O ponto central é que o kernel não precisa retornar a key para que o helper seja invocado. O upcall acontece primeiro. Quando o kernel rejeita a requisição, o código malicioso já executou como root. A trust boundary entre o espaço do usuário e o helper privilegiado nunca foi enforceada — e 19 anos de kernel releases não corrigiram isso.
Quem está exposto: o mapa de vulnerabilidade
A superfície de exposição do CIFSwitch é ampla e desigual. Algumas distribuições são vulneráveis com a configuração padrão — o pacote cifs-utils vem instalado e a regra request-key está ativa sem necessidade de ação do administrador. É o caso de Linux Mint 21.3/22.3, CentOS Stream 9, Rocky Linux 9, Kali 2021.4-2026.1, AlmaLinux 9.7 (incluindo images no Azure) e SLES 15 SP7/SAP.
Outras distribuições são vulneráveis condicionalmente — se o administrador instalou cifs-utils, a cadeia se torna viável. Ubuntu 18.04 a 24.04, Debian 11/12/13, openSUSE Leap 15.6, Oracle Linux 8/9 e Amazon Linux 2023 estão nessa categoria. O pacote não vem por padrão, mas é uma instalação comum em servidores que montam shares SMB.
Há ainda as distribuições onde SELinux ou AppArmor na configuração padrão bloqueiam a exploração: Ubuntu 26.04, Fedora 40-44, CentOS Stream 10, Rocky Linux 10 e AlmaLinux 10. Mas essa proteção é condicional — políticas relaxadas, comuns em ambientes legados e configurações customizadas, removem a barreira. Na Tech86, vimos repetidamente que "o MAC protege" é uma premissa que dura até alguém precisar de uma exceção e relaxar a política sem documentar.
Descoberta assistida por IA e o fix de 4 linhas
Asim Manizada usou agentes de IA com graph reasoning para encontrar a vulnerabilidade. Não foi fuzzing bruto — foi raciocínio estruturado sobre o grafo de confiança entre componentes do kernel. A IA mapeou as relações de confiança entre request_key, cifs.upcall, namespaces e NSS, identificou onde a trust boundary não era enforceada e apontou o gap. Isso é significativo: a vulnerabilidade existia há 19 anos e resistiu a auditorias humanas, code reviews e fuzzers. A IA encontrou porque raciocinou sobre o modelo de confiança, não sobre o código isolado.
O fix upstream são 4 linhas. Commit 3da1fdf. A correção adiciona a validação que faltava: verificar se o solicitante de request_key() tem permissão para invocar o helper privilegiado. Dezenove anos de exposição, milhões de servidores vulneráveis, e a correção cabe em um tweet. Isso não é anomalia — é a natureza das vulnerabilidades de trust boundary. O bug não é complexidade, é ausência de uma checagem que ninguém pensou em adicionar.
A lição: infraestrutura legítima vira arma
Keyrings são legítimos. Namespaces são legítimos. NSS é legítimo. Cada componente individualmente funciona como projetado. O problema emerge na composição: quando o kernel invoca um helper privilegiado dentro de um namespace controlado pelo atacante, e esse helper confia em dados que não foram validados, a infraestrutura legítima se torna o vetor de comprometimento.
Na Tech86, essa é a lente que usamos em auditorias de segurança ofensiva. Não basta verificar componentes isolados — é preciso mapear as trust boundaries entre eles. O CIFSwitch não é um bug de memória, não é um overflow, não é uma race condition. É um gap de validação em uma cadeia de confiança que ninguém auditou como conjunto. Se seus servidores rodam CIFS, se usam containers rootless, se têm cifs-utils instalado, você precisa saber se está exposto. Dezenove anos é tempo demais para um bug que dá root com um syscall.
Conheça nossa Segurança Ofensiva e entenda como auditamos superfícies de ataque kernel com a profundidade que essa realidade exige.