CVE-2025-47827

Falha no módulo igel-flash-driver do IGEL OS anterior à versão 11 permite montar um root filesystem SquashFS malicioso sem verificação de assinatura, quebrando a cadeia de confiança do Secure Boot. O CVSS foi rebaixado de 8.4 para 4.6 em outubro de 2025 porque a MSRC reclassificou o vetor de ataque como acesso físico (AV:P) e removeu impacto em confidencialidade/integridade, mantendo só disponibilidade — mas isso não reduz a gravidade real do bypass de Secure Boot para quem tem acesso físico ao equipamento IGEL.

O IGEL OS usa uma cadeia de boot: um shim assinado pela Microsoft 3rd Party UEFI CA carrega o GRUB e o kernel, ambos assinados pela IGEL Secure Boot Signing CA. O problema está depois disso — no kernel já carregado e íntegro, o módulo igel-flash-driver é responsável por verificar a assinatura da imagem SquashFS que contém o root filesystem antes de montá-la. Na versão vulnerável (IGEL OS 10), essa verificação é falha: uma imagem SquashFS forjada, sem assinatura válida, pode ser montada como root. A MSRC classificou o problema como CWE-324 (Use of a Key Past its Expiration Date), divergindo da classificação inicial do pesquisador como CWE-347 (Improper Verification of Cryptographic Signature).

O impacto é agravado por outro fator: o kernel vulnerável expõe a syscall kexec_load, permitindo substituir completamente o kernel em execução por um kernel arbitrário e não confiável — na prática, inicializar qualquer sistema operacional após o Secure Boot ter validado apenas o shim e o GRUB iniciais. Isso rompe a cadeia de confiança em qualquer ponto após o carregamento do kernel legítimo.

Um detalhe que agrava a exploração pós-correção: mesmo em versões do IGEL OS onde o módulo passou a verificar corretamente a assinatura da SquashFS, o kernel corrigido e o kernel vulnerável são assinados pelo mesmo certificado IGEL. Isso significa que o mesmo shim válido consegue inicializar tanto a versão corrigida quanto a vulnerável — atualizar o sistema operacional, por si só, não impede que um atacante com acesso físico faça downgrade para o kernel antigo e explore a falha novamente.

A exploração exige acesso físico ao dispositivo IGEL (AV:P no vetor CVSS revisado) — não é um bypass remoto de rede. O atacante precisa conseguir inicializar o equipamento a partir de uma configuração controlada por ele (por exemplo, mídia própria, disco alterado ou manipulação do processo de boot local) para que o shim assinado pela Microsoft carregue o GRUB e o kernel IGEL legítimos e, a partir daí, apresente uma imagem SquashFS forjada como root filesystem. Não há necessidade de autenticação prévia no sistema operacional (PR:N) nem interação do usuário (UI:N), mas o pré-requisito de posse física do hardware já restringe bastante o universo de atacantes viáveis a cenários de roubo/furto de equipamento, acesso a salas de máquinas ou manipulação em cadeia de suprimentos/manutenção.

Uma vez com o root filesystem malicioso montado, o atacante pode: usar kexec para substituir o kernel em execução por um totalmente controlado por ele, sem que isso seja detectado pelo processo de Secure Boot (que já validou apenas shim e GRUB); alterar a linha de comando do kernel legítimo para desabilitar módulos de segurança ou trocar o parâmetro init, executando um payload após o root real ser montado; e esconder essas alterações fazendo bind mount sobre /proc/cmdline. O resultado prático é a criação de um bootkit/rootkit persistente em nível de kernel, com acesso irrestrito a memória, CPU e dispositivos — suficiente para extrair chaves de criptografia da memória e evadir ferramentas de detecção baseadas no SO.

A vulnerabilidade está no catálogo KEV da CISA (adicionada em 14/10/2025, prazo de correção 04/11/2025), indicando exploração confirmada em ambiente real, embora a CISA classifique como 'desconhecido' o uso em campanhas de ransomware. Existe PoC pública (repositório do pesquisador que descobriu a falha), o que reduz a barreira técnica para quem já tem o pré-requisito de acesso físico.

O fornecedor corrigiu a verificação de assinatura da imagem SquashFS a partir do IGEL OS 11. Porém, a correção completa depende de um segundo passo fora do controle do usuário final: a revogação dos shims antigos (assinados sem suporte a SBAT) via DBX (UEFI Revocation List), processo que ficou pendente por meses devido a atrito de coordenação entre IGEL, Microsoft e os mantenedores do shim — só avançou depois de repetidas cobranças do pesquisador que reportou a falha. Sem essa revogação, um shim antigo válido continua podendo inicializar tanto o kernel corrigido quanto o vulnerável, então atualizar o IGEL OS por si só não elimina o risco se o atacante tiver acesso físico e conseguir fazer downgrade do kernel.

A CISA KEV recomenda aplicar as mitigações do fornecedor, seguir a orientação BOD 22-01 para serviços em nuvem (quando aplicável) ou descontinuar o uso do produto se não houver mitigação disponível — linguagem padrão que, neste caso, reflete a real dependência da revogação de shim ainda em curso. Como controle compensatório prático, restringir rigorosamente o acesso físico aos terminais/thin clients IGEL (evitar boot por mídia externa, proteger BIOS/UEFI com senha, controlar acesso a salas e transporte de equipamento) mitiga o vetor real da falha, já que ela exige presença física.

O que não funciona como mitigação: assumir que manter o Secure Boot habilitado no firmware resolve o problema — o Secure Boot continua validando shim e GRUB normalmente; a falha está no estágio pós-boot, dentro do próprio SO IGEL, então a cadeia de confiança do firmware permanece intacta enquanto a do sistema operacional é rompida silenciosamente.

Não há sinal de log ou tráfego de rede confiável documentado para esta falha — a exploração ocorre no processo de boot local, antes de qualquer telemetria de SO ou de rede estar ativa, e exige acesso físico prévio. Indicadores indiretos possíveis incluem discrepâncias entre o hash/versão esperado do kernel e initramfs em disco versus o que está efetivamente instalado, alterações inesperadas em /proc/cmdline (considerando que a técnica de ataque documentada usa bind mount para ocultar essas mudanças, o que reduz a confiabilidade desse sinal), e presença de binários EFI ou imagens SquashFS não assinadas/corrigidas em dispositivos que deveriam estar na versão 11.