CIFSwitch a vulnerabilidade que converte uma autenticação Kerberos em um acesso root no Linux

Uma falha de escalada de privilégios locais apodada CIFSwitch Foi documentado no subsistema CIFS do kernel Linux e evidencia como uma mistura de desenho do kernel e comportamento de utilitários em espaço de usuário pode converter uma chamada legítima de autenticação em um caminho para root. CIFS (Common Internet File System) é usado para montar e acessar recursos em rede, e quando essas montagems requerem Kerberos/SPNEGO o kernel delega parte do trabalho a um helper em espaço de usuário (cifs.upcall) gerido pela colecção cifs-utils. O erro aproveita que o kernel não valida corretamente a origem de certos pedidos de chave (cifs.spnego), o que permite a um usuário sem privilégios forjar uma petição e ativar o fluxo de autenticação como se viesse do cliente CIFS do kernel.

Em termos práticos, a vulnerabilidade reside em que cifs.upcall corre com privilégios de root e confia em campos que, por design, deveriam ter sido gerados pelo kernel. Um atacante local pode manipular esses campos para forçar uma mudança de espaço de nomes e provocar uma resolução de nome (NSS) antes que o helper reduza seus privilégios, o que abre a porta para carregar um módulo NSS malicioso e executar código com privilégios de sistema. A descoberta e a descrição técnica detalhada estão disponíveis no relatório do pesquisador Asim Viladi Oglu Manizada, que também publicou um PoC público para validar mitigações: relatório técnico do CIFSwitch e Repositório PoC.

Este erro não é universal: foi introduzido na árvore do kernel em 2007 e sua exploração depende de múltiplos fatores combinados: versão do kernel com a rota vulnerável, presença de uma versão de cifs-utils que implemente a mudança de namespace, a disponibilidade de usar namespaces na configuração do sistema e políticas de segurança (SELinux/AppArmor) que não blocom o ataque. Manizada assinala várias distribuições que, com a sua configuração por defeito em seu momento de teste, foram vulneráveis; outras distros incluem protecções por defeito que atenuam a exploração mesmo que o código em causa exista.

O adesivo que corrige a raiz do problema adiciona validações para garantir que os pedidos cifs.spnego provêm realmente do cliente CIFS do kernel; o commit upstream pode ser consultado no kernel: commit 3da1fdf. No entanto, a implantação desse adesivo depende de cada fornecedor: a única forma confiável de fechar a janela é atualizar os pacotes de kernel e cifs-utils publicados pela sua distribuição e reiniciar os sistemas afetados.

Para administradores e responsáveis pela segurança, convém aplicar uma priorização pragmática: Actualizar kernel e cifs-utils às versões alteradas e verificar as notas de segurança da distribuição; se a atualização imediata não for possível, considerar mitigações temporárias como desactivar ou bloquear o módulo CIFS(blacklist), desinstalar cifs-utils Se não for necessário, e desactivar o utilizador namespaces não- privilegiados. Essas ações reduzem a superfície de ataque, embora possam afetar funcionalidades de montagem em rede; avalie o impacto em serviços antes de aplicá-las em produção.

Detectar as tentativas de exploração exige rever os logs de sistema e auditoria em busca de execuções anormais de cifs.upcall, chamadas invulgares ao keyring do kernel e atividade de carga de módulos NSS a partir de locais não esperados. Se tiver EDR ou ferramentas de detecção de integridade, procure alterações no /lib/libnss_* e nos binários associados a cifs. Também é boa prática comparar sistemas com um inventário conhecido para identificar hosts com versões de kernel ou cifs-utils sem adesivo.

No plano organizacional, o CIFSwitch é um lembrete de que as cadeias entre o kernel e o espaço de usuário (helpers com privilégios) são vetores críticos: as revisões de segurança devem incluir não apenas adesivos do kernel, mas a coordenação com utilitários em espaço de usuário e a configuração de políticas de confinamento (SELinux/AppArmor). Para equipamentos que ainda dependem de montagem CIFS/Kerberos, recomenda testar os adesivos em ambientes de pré-produção e usar o PoC publicado pelo pesquisador apenas em condições controladas para validar as contramedidas: PoC CIFSwitch.

Resumo prático: priorize atualizações de kernel e pacotes de cifs-utils do seu fornecedor de distribuição, remova ou bloquee componentes CIFS se não forem necessários, restrinja user namespaces e reforce políticas de confinamento. A combinação de adesivos, redução de superfície e monitoramento é a única forma de minimizar o risco enquanto as versões adesivos se propagam por sua infraestrutura.