{"id":99320,"date":"2021-03-03T16:22:39","date_gmt":"2021-03-03T14:22:39","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/trudnoustranimye-uyazvimosti-v-grub2-pozvolyayushhie-obojti-uefi-secure-boot"},"modified":"2021-03-03T16:22:39","modified_gmt":"2021-03-03T14:22:39","slug":"trudnoustranimye-uyazvimosti-v-grub2-pozvolyayushhie-obojti-uefi-secure-boot","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/news\/trudnoustranimye-uyazvimosti-v-grub2-pozvolyayushhie-obojti-uefi-secure-boot","title":{"rendered":"Vulnerabilidades dif\u00edceis de corrigir no GRUB2 que permitem contornar o UEFI Secure Boot","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Foi revelada a informa\u00e7\u00e3o sobre 8 vulnerabilidades no carregador GRUB2, que permitem contornar o mecanismo UEFI Secure Boot e executar c\u00f3digo n\u00e3o verificado, como a introdu\u00e7\u00e3o de malware que opera a n\u00edvel de carregador ou do n\u00facleo. <\/p>\n
Lembramos que, na maioria das distribui\u00e7\u00f5es 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\u00f3prio certificado, permitindo que os desenvolvedores de distribui\u00e7\u00f5es n\u00e3o precisem autenticar cada atualiza\u00e7\u00e3o do n\u00facleo e do GRUB na Microsoft. As vulnerabilidades no GRUB2 permitem que um c\u00f3digo malicioso seja executado ap\u00f3s a verifica\u00e7\u00e3o bem-sucedida do shim, mas antes do carregamento do sistema operacional, interferindo na cadeia de confian\u00e7a enquanto o Secure Boot est\u00e1 ativo e obtendo controle total sobre o processo de inicializa\u00e7\u00e3o a seguir, incluindo o carregamento de outro sistema operacional, modifica\u00e7\u00e3o de componentes do sistema operacional e contorno da prote\u00e7\u00e3o Lockdown. <\/p>\n
Assim como no caso da vulnerabilidade BootHole do ano passado, apenas atualizar o carregador n\u00e3o \u00e9 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\u00e3o antiga vulner\u00e1vel do GRUB2, autenticada digitalmente. A solu\u00e7\u00e3o para o problema \u00e9 apenas a atualiza\u00e7\u00e3o da lista de certificados revogados (dbx, UEFI Revocation List), mas nesse caso, perder-se-\u00e1 a possibilidade de utilizar meios de instala\u00e7\u00e3o antigos com Linux. <\/p>\n
Em sistemas com firmwares em que a lista de certificados revogados foi atualizada, no modo UEFI Secure Boot, ser\u00e1 poss\u00edvel carregar apenas vers\u00f5es atualizadas das distribui\u00e7\u00f5es Linux. As distribui\u00e7\u00f5es tamb\u00e9m precisar\u00e3o atualizar seus instaladores, carregadores, pacotes do n\u00facleo, firmwares fwupd e a camada shim, gerando novas assinaturas digitais para eles. Os usu\u00e1rios dever\u00e3o atualizar as imagens de instala\u00e7\u00e3o e outros meios de carregamento, al\u00e9m de carregar a lista de certificados revogados (dbx) na firmware UEFI. At\u00e9 que o dbx seja atualizado no UEFI, o sistema permanece vulner\u00e1vel, independentemente das atualiza\u00e7\u00f5es instaladas no sistema operacional. O status da corre\u00e7\u00e3o das vulnerabilidades pode ser avaliado nas seguintes p\u00e1ginas: Ubuntu, SUSE, RHEL, Debian. <\/p>\n
Para resolver problemas relacionados ao uso de certificados revogados, um mecanismo SBAT (UEFI Secure Boot Advanced Targeting) ser\u00e1 implementado no futuro, cuja suporte j\u00e1 est\u00e1 dispon\u00edvel para GRUB2, shim e fwupd. A partir das pr\u00f3ximas atualiza\u00e7\u00f5es, ele ser\u00e1 utilizado em vez da funcionalidade oferecida pelo pacote dbxtool. O SBAT foi desenvolvido em colabora\u00e7\u00e3o com a Microsoft e implica na adi\u00e7\u00e3o de novos metadados aos arquivos execut\u00e1veis dos componentes UEFI, os quais incluem informa\u00e7\u00f5es sobre o fabricante, produto, componente e vers\u00e3o. Esses metadados s\u00e3o assinados digitalmente e podem ser inclu\u00eddos em listas de componentes permitidos ou bloqueados para o UEFI Secure Boot. Assim, o SBAT permitir\u00e1 manipular n\u00fameros de vers\u00e3o dos componentes durante o processo de revoga\u00e7\u00e3o, sem a necessidade de regenerar chaves para o Secure Boot e sem criar novas assinaturas para o n\u00facleo, shim, grub2 e fwupd. <\/p>\n
Vulnerabilidades identificadas: <\/p>\n
\n
CVE-2020-14372 — atrav\u00e9s do comando acpi no GRUB2, um usu\u00e1rio privilegiado do sistema local pode carregar tabelas ACPI modificadas, colocando o SSDT (Secondary System Description Table) no diret\u00f3rio \/boot\/efi e alterando as configura\u00e7\u00f5es no grub.cfg. Apesar de o modo Secure Boot estar ativado, o SSDT oferecido ser\u00e1 executado pelo kernel e pode ser usado para desativar a prote\u00e7\u00e3o LockDown, que bloqueia caminhos de bypass do UEFI Secure Boot. Como resultado, o invasor pode conseguir carregar seu m\u00f3dulo de kernel ou executar c\u00f3digo atrav\u00e9s do mecanismo kexec, sem verificar a assinatura digital.\n
CVE-2020-25632 — o uso de uma \u00e1rea de mem\u00f3ria j\u00e1 liberada (use-after-free) na implementa\u00e7\u00e3o do comando rmmod, que se manifesta ao tentar descarregar qualquer m\u00f3dulo sem considerar suas depend\u00eancias. A vulnerabilidade n\u00e3o impede a cria\u00e7\u00e3o de um exploit que pode levar \u00e0 execu\u00e7\u00e3o de c\u00f3digo contornando a verifica\u00e7\u00e3o do Secure Boot.\n
CVE-2020-25647 — escrita fora dos limites do buffer na fun\u00e7\u00e3o grub_usb_device_initialize(), chamada durante a inicializa\u00e7\u00e3o de dispositivos USB. O problema pode ser explorado conectando um dispositivo USB especificamente preparado que fornece par\u00e2metros cujo tamanho n\u00e3o corresponde ao tamanho do buffer alocado para estruturas USB. O invasor pode conseguir a execu\u00e7\u00e3o de c\u00f3digo n\u00e3o verificado no Secure Boot atrav\u00e9s de manipula\u00e7\u00f5es com dispositivos USB.\n
CVE-2020-27749 — estouro de buffer na fun\u00e7\u00e3o grub_parser_split_cmdline(), que pode ser acionado ao especificar na linha de comando do GRUB2 vari\u00e1veis com mais de 1 KB de tamanho. A vulnerabilidade permite que um c\u00f3digo seja executado contornando o Secure Boot.\n
CVE-2020-27779 — o comando cutmem permite que um invasor remova um intervalo de endere\u00e7os da mem\u00f3ria para contornar o Secure Boot.\n
CVE-2021-3418 — mudan\u00e7as 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 carregar qualquer kernel diretamente sem verificar a assinatura.\n
CVE-2021-20225 — possibilidade de escrever dados fora do buffer ao executar comandos com um n\u00famero muito grande de op\u00e7\u00f5es.\n
CVE-2021-20233 — possibilidade de escrever dados al\u00e9m dos limites do buffer devido a um c\u00e1lculo incorreto do tamanho do buffer ao usar aspas. No c\u00e1lculo do tamanho, sup\u00f4s-se que para escapar uma aspa simples seriam necess\u00e1rios tr\u00eas caracteres, embora na realidade sejam necess\u00e1rios quatro. <\/ul>\n