Uma vulnerabilidade foi identificada no driver que opera com o sistema de arquivos NTFS no carregador GRUB2 (CVE-2023-4692), permitindo a execução de código malicioso no nível do carregador ao acessar uma imagem de sistema de arquivos especialmente formatada. Essa vulnerabilidade pode ser utilizada para contornar o mecanismo de verificação de inicialização UEFI Secure Boot.
A vulnerabilidade é causada por um erro no código que analisa o atributo NTFS "$ATTRIBUTE_LIST" (grub-core/fs/ntfs.c), que pode ser explorado para escrever informações controladas pelo usuário em uma área de memória fora do buffer alocado. Ao processar uma imagem NTFS especialmente formatada, o estouro causa a sobrescrição de parte da memória do GRUB e, sob certas condições, pode danificar a memória do firmware UEFI, potencialmente permitindo a execução de código no nível do carregador ou do firmware.
Além disso, outra vulnerabilidade também foi identificada no driver NTFS do GRUB2 (CVE-2023-4693), que permite a leitura do conteúdo de uma área de memória arbitrária ao analisar o atributo "$DATA" em uma imagem NTFS especialmente formatada. Entre outras coisas, a vulnerabilidade possibilita a extração de dados confidenciais armazenados na memória ou a determinação dos valores das variáveis EFI.
Os problemas foram corrigidos apenas na forma de patches. O status da correção das vulnerabilidades nas distribuições pode ser avaliado nas seguintes páginas: Debian, Ubuntu, SUSE, RHEL, Fedora. Para resolver 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 do kernel, firmware fwupd e a camada shim.
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 assinatura digital para versões específicas de componentes sem a necessidade de revogar chaves para o Secure Boot. O bloqueio de vulnerabilidades através do SBAT não requer o uso da lista de certificados revogados UEFI (dbx), mas é realizado no nível de substituição da chave interna para a formação de assinaturas e atualização do GRUB2, shim e outros artefatos de inicialização fornecidos pelos distribuidores. Antes da implementação do SBAT, atualizar a lista de certificados revogados (dbx, Lista de Revogação UEFI) era uma condição obrigatória para um bloqueio completo da vulnerabilidade, uma vez que um atacante, independentemente do sistema operacional utilizado, poderia comprometer o UEFI Secure Boot utilizando um carregador de inicialização.
Fonte: opennet.ru
