Foram divulgadas informações sobre duas vulnerabilidades no bootloader GRUB2, que podem levar à execução de código ao usar fontes especialmente projetadas e processar certas sequências Unicode. Vulnerabilidades podem ser usadas para ignorar o mecanismo de inicialização verificado do UEFI Secure Boot.
Vulnerabilidades identificadas:
- CVE-2022-2601 - Um buffer overflow na função grub_font_construct_glyph() ao processar fontes especialmente projetadas no formato pf2, que ocorre devido a um cálculo incorreto do parâmetro max_glyph_size e à alocação de uma área de memória que é obviamente menor do que o necessário para acomodar os glifos.
- CVE-2022-3775 Ocorre uma gravação fora dos limites ao renderizar algumas sequências Unicode em uma fonte com estilo especial. O problema está no código de processamento da fonte e é causado pela falta de verificações adequadas para garantir que a largura e a altura do glifo correspondam ao tamanho do bitmap disponível. Um invasor pode criar a entrada de forma a fazer com que a parte final dos dados seja gravada fora do buffer alocado. Observa-se que apesar da complexidade de exploração da vulnerabilidade, não está excluído levar o problema à execução do código.
A correção foi publicada como um patch. O status de eliminação de vulnerabilidades em distribuições pode ser avaliado nestas páginas: Ubuntu, SUSE, RHEL, Fedora, Debian. Para corrigir problemas no GRUB2, não basta apenas atualizar o pacote; você também precisará gerar novas assinaturas digitais internas e atualizar instaladores, bootloaders, pacotes de kernel, firmware fwupd e camada de shim.
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, incluindo carregar outro sistema operacional, modificar os 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