Um conjunto de patches foi publicado para corrigir 6 vulnerabilidades no carregador GRUB2, a maioria das quais leva a acessos à memória após sua liberação (use-after-free). As questões potencialmente identificadas podem ser exploradas para contornar o mecanismo de inicialização verificada UEFI Secure Boot. O status da correção das vulnerabilidades nas distribuições pode ser avaliado nas seguintes páginas: Debian, Ubuntu, SUSE, RHEL, Arch e Fedora. Para corrigir os problemas no GRUB2, não é suficiente apenas atualizar o pacote; também é necessário gerar novas assinaturas digitais internas e atualizar instaladores, carregadores, pacotes de kernel, firmwares fwupd e a camada shim.
Vulnerabilidades identificadas:
- CVE-2025-61661 — escrita além do buffer alocado na função grub_usb_get_string(), que pode ser explorada ao processar strings em codificações UTF-8 e UTF-16, transmitidas ao conectar dispositivos USB. O problema decorre do fato de que o buffer foi alocado com base no tamanho da string indicado na primeira mensagem do dispositivo USB, enquanto o tamanho calculado durante a conversão de codificação foi baseado em operações subsequentes de leitura do dispositivo USB. Assim, um dispositivo USB modificado pode ser usado para ataque, inicialmente retornando um valor subestimado de tamanho.
- CVE-2025-61663, CVE-2025-61664, CVE-2025-54770, CVE-2025-61662 — falta de limpeza dos manipuladores de comandos "normal", "normal_exit", "net_set_vlan" e "gettext" ao descarregar os módulos "normal", "net" e "gettext", criando condições para acessos à memória após sua liberação (use-after-free) na execução dos comandos marcados após a descarga dos módulos correspondentes. Vulnerabilidades semelhantes também foram encontradas para os comandos "functional_test" e "all_functional_test", mas não receberam identificadores CVE, pois esses comandos fazem parte da biblioteca de testes e não devem ser incluídos em compilações de produção.
- CVE-2025-54771 — erro na contagem de referências a estruturas "fs" na função grub_file_close(), levando a acessos à memória após sua liberação (use-after-free).
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
