Detalhes de 21 vulnerabilidades no bootloader GRUB2 foram publicados, a maioria das quais leva a estouros de buffer e pode ser usada para ignorar o mecanismo de inicialização verificada do UEFI Secure Boot. Até agora, os problemas só foram corrigidos na forma de um patch. O status das correções de vulnerabilidades nas distribuições pode ser avaliado nestas páginas: Debian, Ubuntu, SUSE, RHEL, Fedora. Corrigir problemas no GRUB2 requer mais do que apenas atualizar o pacote; também requer gerar novas assinaturas digitais internas e atualizar instaladores, bootloaders, pacotes do kernel, firmware fwupd e a camada shim.
Vulnerabilidades identificadas:
- CVE-2024-45774: Gravação fora dos limites ao analisar imagens JPEG criadas.
- CVE-2024-45776, CVE-2024-45777: estouros de inteiros ao ler arquivos mo especialmente criados, resultando em gravações fora dos limites.
- CVE-2024-45778, CVE-2024-45779: estouros de inteiros ao trabalhar com um sistema de arquivos BFS corrompido, levando a um estouro de buffer.
- CVE-2024-45780: Um estouro de inteiro ao manipular arquivos tar especialmente criados leva a uma gravação fora dos limites.
- CVE-2024-45781, CVE-2025-0677: estouros de buffer ao trabalhar com um sistema de arquivos UFS corrompido.
- CVE-2024-45782, CVE-2025-1125: estouros de buffer ao montar uma partição HFS especialmente criada.
- CVE-2025-0622: Um erro de uso após liberação durante a manipulação do módulo pode levar à execução de código do invasor.
- CVE-2025-0624: Estouro de buffer na inicialização da rede.
- CVE-2025-0678: estouro de buffer ao manipular um sistema de arquivos Squash4 corrompido.
- CVE-2025-0684: Estouro de buffer ao manipular links simbólicos no Reiserfs.
- CVE-2025-0685: Estouros de buffer ao manipular links simbólicos no JFS.
- CVE-2025-0685: Estouros de buffer ao manipular links simbólicos em ROMFS.
- CVE-2025-0689: Estouro de buffer ao manipular uma seção UDF especialmente modificada.
- CVE-2025-0690: Estouro de buffer ao receber dados especialmente criados do teclado.
- CVE-2025-1118: Ignorar modo de isolamento de bloqueio e extração de memória arbitrária via comando de despejo.
- CVE-2024-45775: A falta de verificação de código de erro ao alocar memória durante a análise de argumentos passados pode levar à corrupção de dados IVT (Tabela de Vetores de Interrupção).
- CVE-2024-45783: acesso de ponteiro NULL ao montar um sistema de arquivos HFS+ inválido.
A maioria das distribuições Linux usa uma pequena camada de shim assinada digitalmente pela Microsoft para inicialização verificada no modo UEFI Secure Boot. Essa camada verifica o GRUB2 com seu próprio certificado, o que permite que os desenvolvedores de distribuição não tenham todos os kernels e atualizações do GRUB certificados pela Microsoft. Vulnerabilidades no GRUB2 permitem que você execute seu código no estágio após a verificação de correção bem-sucedida, mas antes de carregar o sistema operacional, entrando na cadeia de confiança quando o modo de inicialização segura está ativo e obtendo controle total sobre o processo de inicialização adicional, por por exemplo, para carregar outro sistema operacional, modificar componentes do sistema operacional e ignorar a proteção de bloqueio.
Para bloquear a vulnerabilidade sem revogar a assinatura digital, as distribuições podem usar o mecanismo SBAT (UEFI Secure Boot Advanced Targeting), que é compatível com GRUB2, shim e fwupd nas distribuições Linux mais populares. O SBAT foi desenvolvido em conjunto com a Microsoft e envolve a adição de metadados adicionais aos arquivos executáveis dos componentes UEFI, que incluem informações sobre fabricante, produto, componente e versão. Os metadados especificados são certificados com assinatura digital e podem ser incluídos separadamente nas listas de componentes permitidos ou proibidos para UEFI Secure Boot.
O SBAT permite bloquear o uso de assinaturas digitais para números de versão de componentes individuais sem precisar revogar chaves para inicialização segura. O bloqueio de vulnerabilidades via SBAT não requer o uso de uma lista de revogação de certificados UEFI (dbx), mas é realizado no nível de substituição da chave interna para gerar assinaturas e atualizar GRUB2, shim e outros artefatos de inicialização fornecidos pelas distribuições. Antes da introdução do SBAT, a atualização da lista de certificados revogados (dbx, UEFI Revocation List) era um pré-requisito para bloquear completamente a vulnerabilidade, uma vez que um invasor, independentemente do sistema operacional usado, poderia usar mídia inicializável com uma versão antiga e vulnerável do GRUB2, certificado por uma assinatura digital, para comprometer o UEFI Secure Boot.
Fonte: opennet.ru
