Foram divulgadas informações sobre duas vulnerabilidades no carregador de inicialização GRUB2 que podem levar à execução de código ao usar fontes especialmente criadas e processar determinadas sequências Unicode. Essas vulnerabilidades podem ser exploradas para burlar o mecanismo de inicialização segura UEFI.
Vulnerabilidades identificadas:
- CVE-2022-2601 — Ocorre um estouro de buffer na função grub_font_construct_glyph() ao processar fontes pf2 especialmente projetadas, devido a um cálculo incorreto do parâmetro max_glyph_size e à alocação de uma área de memória obviamente menor do que a necessária para acomodar os glifos.
- CVE-2022-3775 — Vulnerabilidade de escrita fora dos limites ao renderizar certas sequências Unicode com uma fonte especialmente criada. O problema reside 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 atacante pode manipular a entrada para que a cauda do buffer alocado seja escrita além do final do buffer alocado. Embora a exploração dessa vulnerabilidade seja difícil, é possível que o problema leve à execução de código.
A correção foi publicada como um patch. O status das correções de vulnerabilidades nas distribuições pode ser avaliado nestas páginas: Ubuntu, SUSE, RHEL, Fedora, DebianCorrigir 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.
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, incluindo a inicialização de outro sistema operacional, a modificação de componentes do sistema operacional e a burla 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 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
