Foram reveladas informações sobre duas vulnerabilidades no carregador GRUB2, que podem permitir a execução de código ao utilizar fontes especialmente formatadas e ao processar determinadas sequências Unicode. As vulnerabilidades podem ser utilizadas para contornar o mecanismo de verificação de inicialização UEFI Secure Boot.
Vulnerabilidades identificadas:
- CVE-2022-2601 — estouro de buffer na função grub_font_construct_glyph() ao processar fontes especialmente formatadas no formato pf2, causado por um cálculo incorreto do parâmetro max_glyph_size e pela alocação de uma área de memória deliberadamente menor do que o necessário para armazenar os glifos.
- CVE-2022-3775 — gravação além da área de memória alocada ao renderizar algumas sequências Unicode com uma fonte especialmente formatada. O problema está presente no código de processamento de fontes e é causado pela falta de verificações adequadas de correspondência da largura e altura do glifo em relação ao tamanho do bitmap existente. Um atacante pode escolher uma entrada de forma a provocar a escrita de dados além do limite do buffer alocado. Embora a exploração da vulnerabilidade seja complexa, a possibilidade de execução de código não pode ser descartada.
Uma correção foi publicada na forma de um patch. O status da correção das vulnerabilidades nas distribuições pode ser avaliado nas seguintes páginas: Ubuntu, SUSE, RHEL, Fedora, Debian. Para corrigir problemas no GRUB2, não é suficiente apenas atualizar o pacote, também será necessário gerar novas assinaturas digitais internas e atualizar instaladores, carregadores, pacotes com o kernel, firmwares fwupd e a camada shim.
Na maioria das distribuições Linux, para a inicialização verificada em modo UEFI Secure Boot, é utilizado um pequeno módulo shim, assinado digitalmente pela Microsoft. Este módulo verifica o GRUB2 com seu próprio certificado, permitindo que os desenvolvedores de distribuições não precisem assinar cada atualização do kernel e do GRUB com a Microsoft. As vulnerabilidades no GRUB2 permitem a execução de código próprio após a verificação bem-sucedida do shim, mas antes do carregamento do sistema operacional, inserindo-se na cadeia de confiança com o modo Secure Boot ativo e assumindo controle total sobre o processo de inicialização subsequente, incluindo a inicialização de outro sistema operacional, modificação de componentes do sistema operacional e contorno da 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
