Foi revelada a informação sobre 8 vulnerabilidades no carregador GRUB2, que permitem contornar o mecanismo UEFI Secure Boot e executar código não verificado, como a introdução de malware que opera a nível de carregador ou do núcleo.
Lembramos que, na maioria das distribuições Linux, para o carregamento verificado em modo UEFI Secure Boot, utiliza-se uma pequena camada shim, autenticada digitalmente pela Microsoft. Essa camada verifica o GRUB2 com seu próprio certificado, permitindo que os desenvolvedores de distribuições não precisem autenticar cada atualização do núcleo e do GRUB na Microsoft. As vulnerabilidades no GRUB2 permitem que um código malicioso seja executado após a verificação bem-sucedida do shim, mas antes do carregamento do sistema operacional, interferindo na cadeia de confiança enquanto o Secure Boot está ativo e obtendo controle total sobre o processo de inicialização a seguir, incluindo o carregamento de outro sistema operacional, modificação de componentes do sistema operacional e contorno da proteção Lockdown.
Assim como no caso da vulnerabilidade BootHole do ano passado, apenas atualizar o carregador não é suficiente para bloquear o problema, pois um atacante, independentemente do sistema operacional utilizado, pode comprometer o UEFI Secure Boot utilizando um meio de carregamento com uma versão antiga vulnerável do GRUB2, autenticada digitalmente. A solução para o problema é apenas a atualização da lista de certificados revogados (dbx, UEFI Revocation List), mas nesse caso, perder-se-á a possibilidade de utilizar meios de instalação antigos com Linux.
Em sistemas com firmwares em que a lista de certificados revogados foi atualizada, no modo UEFI Secure Boot, será possível carregar apenas versões atualizadas das distribuições Linux. As distribuições também precisarão atualizar seus instaladores, carregadores, pacotes do núcleo, firmwares fwupd e a camada shim, gerando novas assinaturas digitais para eles. Os usuários deverão atualizar as imagens de instalação e outros meios de carregamento, além de carregar a lista de certificados revogados (dbx) na firmware UEFI. Até que o dbx seja atualizado no UEFI, o sistema permanece vulnerável, independentemente das atualizações instaladas no sistema operacional. O status da correção das vulnerabilidades pode ser avaliado nas seguintes páginas: Ubuntu, SUSE, RHEL, Debian.
Para resolver problemas relacionados ao uso de certificados revogados, um mecanismo SBAT (UEFI Secure Boot Advanced Targeting) será implementado no futuro, cuja suporte já está disponível para GRUB2, shim e fwupd. A partir das próximas atualizações, ele será utilizado em vez da funcionalidade oferecida pelo pacote dbxtool. O SBAT foi desenvolvido em colaboração com a Microsoft e implica na adição de novos metadados aos arquivos executáveis dos componentes UEFI, os quais incluem informações sobre o fabricante, produto, componente e versão. Esses metadados são assinados digitalmente e podem ser incluídos em listas de componentes permitidos ou bloqueados para o UEFI Secure Boot. Assim, o SBAT permitirá manipular números de versão dos componentes durante o processo de revogação, sem a necessidade de regenerar chaves para o Secure Boot e sem criar novas assinaturas para o núcleo, shim, grub2 e fwupd.
Vulnerabilidades identificadas:
- CVE-2020-14372 — por meio do comando acpi no GRUB2, um usuário privilegiado da máquina local pode carregar tabelas ACPI modificadas, colocando o SSDT (Secondary System Description Table) no diretório /boot/efi e alterando as configurações no grub.cfg. Apesar de o modo Secure Boot estar ativo, o SSDT proposto será executado pelo núcleo e pode ser usado para desabilitar a proteção LockDown, que bloqueia caminhos de bypass do UEFI Secure Boot. Como resultado, um invasor pode conseguir carregar seu módulo de núcleo ou executar código por meio do mecanismo kexec, sem a verificação da assinatura digital.
- CVE-2020-25632 — uma referência a uma área de memória já liberada (use-after-free) na implementação do comando rmmod, que se manifesta ao tentar descarregar qualquer módulo sem levar em conta suas dependências relacionadas. A vulnerabilidade não exclui a criação de um exploit que pode levar à execução de código evitando a verificação do Secure Boot.
- CVE-2020-25647 — uma gravação fora dos limites do buffer na função grub_usb_device_initialize(), chamada durante a inicialização de dispositivos USB. O problema pode ser explorado conectando um dispositivo USB especialmente preparado que forneça parâmetros cujo tamanho não corresponda ao tamanho do buffer alocado para as estruturas USB. Um invasor pode conseguir executar código que não foi verificado no Secure Boot, manipulando os dispositivos USB.
- CVE-2020-27749 — um estouro de buffer na função grub_parser_split_cmdline(), que pode ser acionado ao especificar variáveis na linha de comando do GRUB2 com tamanho superior a 1 KB. A vulnerabilidade permite a execução de código contornando o Secure Boot.
- CVE-2020-27779 — o comando cutmem permite que um atacante remova um intervalo de endereços da memória para contornar o Secure Boot.
- CVE-2021-3418 — mudanças no shim_lock criaram um vetor adicional para explorar a vulnerabilidade do ano passado CVE-2020-15705. Ao instalar no dbx o certificado usado para assinar o GRUB2, o GRUB2 permitiu o carregamento de qualquer núcleo diretamente sem verificar a assinatura.
- CVE-2021-20225 — possibilidade de gravar dados além do buffer ao executar comandos com um número muito grande de opções.
- CVE-2021-20233 — possibilidade de gravar dados para fora do buffer devido ao cálculo incorreto do tamanho do buffer ao usar aspas. Ao calcular o tamanho, assumiu-se que a escapada de uma aspa simples requer três caracteres, embora na verdade sejam necessários quatro.
Fonte: opennet.ru
