Foram divulgadas informações sobre 21 vulnerabilidade no carregador GRUB2, a maioria das quais leva a um estouro de buffer e pode ser usada para contornar o mecanismo de verificação de inicialização UEFI Secure Boot. Os problemas foram solucionados apenas na forma de patches. O status das correções das vulnerabilidades nos distribuições pode ser avaliado nas seguintes páginas: Debian, Ubuntu, SUSE, RHEL, Fedora. Para resolver os problemas no GRUB2, não é suficiente apenas atualizar o pacote, também é necessário gerar novas assinaturas digitais internas e atualizar instaladores, bootloaders, pacotes do kernel, firmwares fwupd e a camada shim.
Vulnerabilidades identificadas:
- CVE-2024-45774: escrita fora do limite de buffer ao analisar imagens JPEG especificamente formatadas.
- CVE-2024-45776, CVE-2024-45777: estouros inteiros ao ler arquivos mo especificamente formatados, levando a gravações fora do limite de buffer.
- CVE-2024-45778, CVE-2024-45779: estouros inteiros ao trabalhar com um sistema de arquivos BFS corrompido, levando a um estouro de buffer.
- CVE-2024-45780: estouro inteiro ao processar arquivos tar especificamente formatados, levando a gravações fora do limite de buffer.
- 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 especificamente formatada.
- CVE-2025-0622: acesso à memória após a liberação durante operações com módulos, o que pode levar à execução de código malicioso.
- CVE-2025-0624: estouro de buffer ao carregar pela rede.
- CVE-2025-0678: estouros de buffer ao trabalhar com um sistema de arquivos Squash4 corrompido.
- CVE-2025-0684: estouros de buffer durante operações com links simbólicos no sistema de arquivos Reiserfs.
- CVE-2025-0685: estouros de buffer durante operações com links simbólicos no sistema de arquivos JFS.
- CVE-2025-0685: estouros de buffer durante operações com links simbólicos no sistema de arquivos ROMFS.
- CVE-2025-0689: estouros de buffer ao trabalhar com uma partição UDF especificamente modificada.
- CVE-2025-0690: estouros de buffer ao receber dados especificamente formatados do teclado.
- CVE-2025-1118: contorno do modo de isolamento Lockdown e extração de conteúdo de memória arbitrário através da execução do comando dump.
- CVE-2024-45775: falta de verificação de código de erro ao alocar memória ao analisar os argumentos transmitidos pode levar à corrupção de dados da IVT (Tabela de Vetores de Interrupção).
- CVE-2024-45783: acesso por ponteiro nulo ao montar um sistema de arquivos HFS+ inválido.
Na maioria das distribuições Linux, para a inicialização verificada no modo UEFI Secure Boot, é usada uma pequena camada shim, assinada digitalmente pela Microsoft. Essa camada verifica o GRUB2 com seu próprio certificado, permitindo que os desenvolvedores das distribuições não precisem assinar cada atualização do kernel e do GRUB pela Microsoft. Vulnerabilidades no GRUB2 permitem a execução de código após a verificação bem-sucedida do shim, mas antes da inicialização do sistema operacional, infiltrando-se na cadeia de confiança com o modo Secure Boot ativo e obtendo controle total sobre o processo de inicialização, por exemplo, para inicializar outro SO, modificar componentes do sistema operacional e contornar a proteção Lockdown.
Para bloquear a vulnerabilidade sem revogar a assinatura digital, as distribuições podem usar o mecanismo SBAT (UEFI Secure Boot Advanced Targeting), cujo suporte é implementado para GRUB2, shim e fwupd na maioria das distribuições populares do Linux. O SBAT foi desenvolvido em conjunto com a Microsoft e implica a adição de metadados adicionais nos arquivos executáveis dos componentes UEFI, que incluem informações sobre o fabricante, produto, componente e versão. Esses metadados são assinados digitalmente e podem ser incluídos separadamente nas listas de componentes permitidos ou bloqueados para o UEFI Secure Boot.
O SBAT permite bloquear o uso de assinaturas digitais para versões específicas de componentes sem a necessidade de revogar chaves para o Secure Boot. O bloqueio de vulnerabilidades via SBAT não requer o uso da lista de certificados revogados UEFI (dbx), sendo realizado no nível de substituição de chaves internas para a formação de assinaturas e atualização do GRUB2, shim e outros artefatos de inicialização fornecidos pelas distribuições. Antes da implementação do SBAT, a atualização da lista de certificados revogados (dbx, UEFI Revocation List) era uma condição obrigatória para o bloqueio total da vulnerabilidade, pois um atacante, independentemente do sistema operacional utilizado, podia comprometer o UEFI Secure Boot usando um meio de inicialização com uma versão antiga vulnerável do GRUB2, assinada digitalmente.
Fonte: opennet.ru
