{"id":90288,"date":"2020-07-30T13:42:19","date_gmt":"2020-07-30T11:42:19","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/kriticheskaya-uyazvimost-v-zagruzchike-grub2-pozvolyayushhaya-obojti-uefi-secure-boot"},"modified":"2020-07-30T13:42:19","modified_gmt":"2020-07-30T11:42:19","slug":"kriticheskaya-uyazvimost-v-zagruzchike-grub2-pozvolyayushhaya-obojti-uefi-secure-boot","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/news\/kriticheskaya-uyazvimost-v-zagruzchike-grub2-pozvolyayushhaya-obojti-uefi-secure-boot","title":{"rendered":"Uma vulnerabilidade cr\u00edtica no carregador GRUB2, que permite contornar o UEFI Secure Boot","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

No carregador GRUB2 identificado<\/a><\/noindex> 8 vulnerabilidades. A mais perigosa problema<\/a><\/noindex> (CVE-2020-10713<\/a><\/noindex>), nomeada de BootHole, permite<\/a><\/noindex> contornar o mecanismo UEFI Secure Boot e instalar malware n\u00e3o verificado. A particularidade desta vulnerabilidade \u00e9 que apenas atualizar o GRUB2 n\u00e3o \u00e9 suficiente, uma vez que um atacador pode usar um meio de inicializa\u00e7\u00e3o com uma vers\u00e3o vulner\u00e1vel antiga, assinada digitalmente. O atacador pode comprometer o processo de verifica\u00e7\u00e3o n\u00e3o s\u00f3 do Linux, mas tamb\u00e9m de outros sistemas operacionais, incluindo Windows<\/a><\/noindex>. <\/p>\n

O problema \u00e9 resolvido apenas atualizando o sistema da lista de certificados revogados<\/a><\/noindex> (dbx, UEFI Revocation List), mas nesse caso, a capacidade de usar antigos meios de instala\u00e7\u00e3o com Linux ser\u00e1 perdida. Alguns fabricantes de hardware j\u00e1 inclu\u00edram em seus firmwares uma lista atualizada de certificados revogados, e nesses sistemas, no modo UEFI Secure Boot, ser\u00e1 poss\u00edvel inicializar apenas compila\u00e7\u00f5es atualizadas das distribui\u00e7\u00f5es Linux. <\/p>\n

Para eliminar a vulnerabilidade nas distribui\u00e7\u00f5es, tamb\u00e9m ser\u00e1 necess\u00e1rio atualizar instaladores, carregadores, pacotes do kernel, firmwares fwupd e a camada shim, gerando novas assinaturas digitais para eles. Os usu\u00e1rios precisar\u00e3o atualizar as imagens de instala\u00e7\u00e3o e outros meios de inicializa\u00e7\u00e3o, bem como carregar a lista de certificados revogados (dbx) no firmware UEFI. At\u00e9 a atualiza\u00e7\u00e3o do dbx no UEFI, o sistema permanece vulner\u00e1vel, independentemente da instala\u00e7\u00e3o de atualiza\u00e7\u00f5es no SO. <\/p>\n

Vulnerabilidade \u00e9 causado<\/a><\/noindex> por meio de um estouro de buffer, que pode ser explorado para executar c\u00f3digo arbitr\u00e1rio durante o processo de inicializa\u00e7\u00e3o.
\nA vulnerabilidade se manifesta ao analisar o conte\u00fado do arquivo de configura\u00e7\u00e3o grub.cfg, que geralmente est\u00e1 localizado na parti\u00e7\u00e3o ESP (EFI System Partition) e pode ser editado por um invasor com privil\u00e9gios de administrador, sem comprometer a integridade dos arquivos execut\u00e1veis assinados shim e GRUB2. Devido a um erro<\/a><\/noindex> No c\u00f3digo do parser de configura\u00e7\u00e3o, o manipulador de erros fatais YY_FATAL_ERROR apenas exibia um aviso, mas n\u00e3o encerrava o programa. O risco da vulnerabilidade \u00e9 reduzido pela necessidade de acesso privilegiado ao sistema; no entanto, o problema pode ser explorado para a implementa\u00e7\u00e3o de rootkits ocultos com acesso f\u00edsico ao hardware (caso seja poss\u00edvel inicializar a partir de um meio pr\u00f3prio).<\/p>\n

Na maioria das distribui\u00e7\u00f5es Linux, \u00e9 usada uma pequena camada shim<\/a><\/noindex>, assinada digitalmente pela Microsoft. Esta camada verifica o GRUB2 com seu pr\u00f3prio certificado, permitindo que os desenvolvedores de distribui\u00e7\u00f5es n\u00e3o assinem cada atualiza\u00e7\u00e3o do kernel e do GRUB na Microsoft. A vulnerabilidade permite, atrav\u00e9s da altera\u00e7\u00e3o do conte\u00fado de grub.cfg, executar seu pr\u00f3prio c\u00f3digo ap\u00f3s a verifica\u00e7\u00e3o bem-sucedida do shim, mas antes da inicializa\u00e7\u00e3o do sistema operacional, inserindo-se na cadeia de confian\u00e7a durante o modo Secure Boot ativo e obtendo controle total sobre o processo de inicializa\u00e7\u00e3o, incluindo o carregamento de outro sistema operacional, a modifica\u00e7\u00e3o de componentes do sistema operacional e a evas\u00e3o de prote\u00e7\u00f5es. Lockdown<\/a><\/noindex>. <\/p>\n

\"Uma<\/a><\/noindex><\/center><\/p>\n

Outras vulnerabilidades no GRUB2:<\/p>\n