Foi identificada uma vulnerabilidade (CVE-2023-4692) no driver que suporta o sistema de arquivos NTFS no carregador de inicialização GRUB2. Essa vulnerabilidade permite a execução de código personalizado no nível do carregador de inicialização ao acessar uma imagem de sistema de arquivos especialmente criada. Essa vulnerabilidade pode ser explorada para burlar o mecanismo de inicialização segura UEFI.
A vulnerabilidade é causada por um erro no código de análise do atributo NTFS "$ATTRIBUTE_LIST" (grub-core/fs/ntfs.c), que pode ser explorado para gravar informações controladas pelo usuário em um local de memória fora do buffer alocado. Ao processar uma imagem NTFS especialmente criada, o estouro de buffer leva à sobrescrita de parte da memória do GRUB e, sob certas condições, à corrupção da memória do firmware UEFI, potencialmente permitindo a execução de código no nível do bootloader ou do firmware.
Além disso, outra vulnerabilidade (CVE-2023-4693) foi descoberta no driver NTFS do GRUB2. Essa vulnerabilidade permite a leitura de conteúdo arbitrário da memória ao analisar o atributo "$DATA" em uma imagem NTFS especialmente criada. Entre outras coisas, essa vulnerabilidade permite a extração de dados sensíveis armazenados em cache na memória ou a determinação de valores de variáveis EFI.
Até o momento, os problemas foram resolvidos apenas por meio de atualizações. O status das correções de vulnerabilidades nas distribuições pode ser verificado nestas páginas: Debian, Ubuntu, SUSE, RHEL, 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.
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 a necessidade de revogar as chaves do Secure Boot. O bloqueio de vulnerabilidades via SBAT não exige o uso da Lista de Revogação de Certificados UEFI (dbx), mas é realizado no nível da substituição da chave interna para geração de assinaturas e atualização do GRUB2, shim e outros artefatos de inicialização fornecidos pelas distribuições. Antes da introdução do SBAT, a atualização da Lista de Revogação de Certificados UEFI (dbx) era uma condição obrigatória para o bloqueio completo da vulnerabilidade, visto que um atacante, independentemente do sistema operacional utilizado, poderia usar a chave de inicialização para comprometer o Secure Boot UEFI.
Fonte: opennet.ru
