Um conjunto de patches foi publicado para corrigir seis vulnerabilidades no bootloader GRUB2, a maioria das quais resulta em problemas de uso após liberação (UAF). Esses problemas em potencial podem ser explorados para burlar o mecanismo de inicialização segura UEFI. O status desses patches nas distribuições pode ser verificado nas páginas a seguir: Debian, Ubuntu, SUSE, RHEL, Arch e Fedora. Corrigir problemas do GRUB2 exige mais do que apenas atualizar o pacote; também requer gerar novas assinaturas digitais internas e atualizar instaladores, carregadores de inicialização, pacotes do kernel, firmware do fwupd e a camada shim.
Vulnerabilidades identificadas:
- CVE-2025-61661 — Uma vulnerabilidade de escrita fora dos limites na função grub_usb_get_string() pode ser explorada durante o processamento de strings codificadas em UTF-8 e UTF-16 transmitidas ao conectar dispositivos USB. O problema ocorre porque o buffer é alocado com base no tamanho da string especificado na primeira mensagem do dispositivo USB, e o tamanho durante a conversão de codificação é calculado com base em operações de leitura subsequentes do dispositivo USB. Consequentemente, um dispositivo USB modificado que inicialmente retorna um tamanho subestimado pode ser usado para esse ataque.
- CVE-2025-61663, CVE-2025-61664, CVE-2025-54770, CVE-2025-61662 — falha na limpeza dos manipuladores de comandos "normal", "normal_exit", "net_set_vlan" e "gettext" ao descarregar os módulos "normal", "net" e "gettext". Isso cria condições para uma vulnerabilidade de uso após liberação (UFS) ao executar os comandos mencionados após os módulos correspondentes terem sido descarregados. Vulnerabilidades semelhantes também foram encontradas para os comandos "functional_test" e "all_functional_test", mas não receberam identificadores CVE porque esses comandos fazem parte da biblioteca de testes e não devem ser incluídos em versões de produção.
- CVE-2025-54771 - Um erro na contagem de referências das estruturas "fs" na função grub_file_close() leva a um uso após liberação (use-after-free).
Na maioria LinuxAs distribuições para inicialização verificada no modo UEFI Secure Boot utilizam uma pequena camada intermediária, assinada digitalmente pela Microsoft. Essa camada verifica o GRUB2 com seu próprio certificado, eliminando a necessidade de os desenvolvedores de distribuições notificarem a Microsoft sobre cada atualização do kernel e do GRUB. Vulnerabilidades no GRUB2 permitem a execução de código arbitrário após a verificação bem-sucedida da camada intermediária, mas antes da inicialização do sistema operacional. Isso permite que invasores quebrem a cadeia de confiança quando o Secure Boot está habilitado e obtenham controle total sobre o processo de inicialização subsequente, por exemplo, para inicializar outro sistema operacional, modificar componentes do sistema operacional ou burlar 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 está implementado para GRUB2, shim e fwupd na maioria das distribuições populares. LinuxO SBAT foi desenvolvido em colaboração com a Microsoft e consiste na adição de metadados adicionais aos arquivos executáveis dos componentes UEFI, incluindo informações sobre o fabricante, o produto, o componente e a versão. Esses metadados são assinados digitalmente e podem ser incluídos separadamente nas listas de componentes permitidos ou bloqueados para a Inicialização Segura UEFI.
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
