{"id":119554,"date":"2024-08-21T09:43:00","date_gmt":"2024-08-21T07:43:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/oshibka-v-obnovlenii-k-windows-blokirovala-zagruzku-linux-pri-ispolzovanii-uefi-secure-boot"},"modified":"2024-08-21T09:43:00","modified_gmt":"2024-08-21T07:43:00","slug":"oshibka-v-obnovlenii-k-windows-blokirovala-zagruzku-linux-pri-ispolzovanii-uefi-secure-boot","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/news\/oshibka-v-obnovlenii-k-windows-blokirovala-zagruzku-linux-pri-ispolzovanii-uefi-secure-boot","title":{"rendered":"Um erro na atualiza\u00e7\u00e3o para Windows bloqueava a inicializa\u00e7\u00e3o do Linux ao usar UEFI Secure Boot","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
No atualiza\u00e7\u00e3o liberada na ter\u00e7a-feira pela Microsoft para o sistema operacional Windows, foi identificada um problema que impede a inicializa\u00e7\u00e3o de sistemas Linux instalados no mesmo computador em paralelo ao Windows. A causa dos problemas \u00e9 a corre\u00e7\u00e3o que visa eliminar uma antiga vulnerabilidade (CVE-2022-2601) no carregador GRUB, consertada em 2022. A Microsoft ainda n\u00e3o publicou declara\u00e7\u00f5es sobre a falha ocorrida e n\u00e3o comentou sobre o assunto. <\/p>\n
Na nota de altera\u00e7\u00e3o, foi mencionado que a corre\u00e7\u00e3o, que garante a instala\u00e7\u00e3o da nova pol\u00edtica SBAT (UEFI Secure Boot Advanced Targeting), ser\u00e1 aplicada apenas em sistemas que utilizam apenas Windows e n\u00e3o afetar\u00e1 configura\u00e7\u00f5es de dual boot (a altera\u00e7\u00e3o bloqueou a capacidade de usar imagens de inicializa\u00e7\u00e3o com o antigo GRUB para contornar o Secure Boot em sistemas onde apenas o Windows est\u00e1 instalado). Tamb\u00e9m foi indicado que a mudan\u00e7a pode causar problemas ao inicializar imagens ISO de sistemas antigos fornecidos com uma vers\u00e3o vulner\u00e1vel do GRUB. Na pr\u00e1tica, problemas surgiram tamb\u00e9m para usu\u00e1rios de sistemas de dual boot que utilizam novas distribui\u00e7\u00f5es Linux, como Ubuntu 24.04 e Debian 12.6, nas quais a vulnerabilidade no GRUB j\u00e1 foi corrigida h\u00e1 muito tempo. <\/p>\n
O problema se manifesta na interrup\u00e7\u00e3o do processo de inicializa\u00e7\u00e3o com a mensagem \"Verifying shim SBAT data failed: Security Policy Violation. Something has gone seriously wrong: SBAT self-check failed: Security Policy Violation\". Para restaurar a opera\u00e7\u00e3o, recomenda-se remover os dados SBAT instalados no UEFI, para o que pode-se desativar o Secure Boot no firmware, carregar uma nova distribui\u00e7\u00e3o Linux que suporte UEFI Secure Boot, como o Ubuntu, e executar no console o comando \"mokutil --set-sbat-policy delete\", ap\u00f3s o que reinicie a distribui\u00e7\u00e3o Linux para estabelecer a pol\u00edtica SBAT correta. Depois disso, \u00e9 poss\u00edvel reativar o modo Secure Boot no firmware. <\/p>\n
O mecanismo SBAT foi desenvolvido pela Red Hat em colabora\u00e7\u00e3o com a Microsoft para bloquear vulnerabilidades no carregador GRUB e na camada shim, sem revogar a assinatura digital. O SBAT implica a adi\u00e7\u00e3o de metadados execut\u00e1veis a componentes UEFI, que incluem informa\u00e7\u00f5es sobre o fabricante, produto, componente e vers\u00e3o. Os metadados especificados s\u00e3o assinados digitalmente e podem ser inclu\u00eddos em listas de componentes autorizados ou proibidos para o UEFI Secure Boot. O SBAT permite bloquear o uso de assinaturas digitais para vers\u00f5es espec\u00edficas de componentes sem a necessidade de revogar chaves para o Secure Boot. <\/p>\n
O bloqueio de vulnerabilidades atrav\u00e9s do SBAT n\u00e3o requer o uso da lista de certificados revogados UEFI (dbx) e \u00e9 realizado em n\u00edvel de substitui\u00e7\u00e3o da chave interna para a forma\u00e7\u00e3o de assinaturas e atualiza\u00e7\u00e3o do GRUB2, shim e outros artefatos de carregamento fornecidos por distribui\u00e7\u00f5es. Antes da implementa\u00e7\u00e3o do SBAT, a atualiza\u00e7\u00e3o da lista de certificados revogados (dbx, UEFI Revocation List) era uma condi\u00e7\u00e3o obrigat\u00f3ria para o bloqueio completo da vulnerabilidade, pois o atacante, independentemente do sistema operacional utilizado, poderia comprometer o UEFI Secure Boot utilizando uma m\u00eddia de inicializa\u00e7\u00e3o com uma vers\u00e3o antiga e vulner\u00e1vel do GRUB2, assinada digitalmente. \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"