{"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\/fr\/blog\/news\/oshibka-v-obnovlenii-k-windows-blokirovala-zagruzku-linux-pri-ispolzovanii-uefi-secure-boot","title":{"rendered":"Un bug dans la mise \u00e0 jour vers Windows bloquait le d\u00e9marrage de Linux lors de l'utilisation du d\u00e9marrage s\u00e9curis\u00e9 UEFI.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Dans la mise \u00e0 jour publi\u00e9e mardi par Microsoft pour le syst\u00e8me d'exploitation Windows, un probl\u00e8me a \u00e9t\u00e9 identifi\u00e9, rendant impossible le d\u00e9marrage des syst\u00e8mes Linux install\u00e9s sur le m\u00eame ordinateur en parall\u00e8le avec Windows. La cause de ce probl\u00e8me est un correctif visant \u00e0 r\u00e9soudre une ancienne vuln\u00e9rabilit\u00e9 (CVE-2022-2601) dans le chargeur GRUB, corrig\u00e9 en 2022. Microsoft n\u2019a pas encore publi\u00e9 de d\u00e9claration concernant ce probl\u00e8me et ne l\u2019a pas comment\u00e9. <\/p>\n
Dans la note de mise \u00e0 jour, il a \u00e9t\u00e9 indiqu\u00e9 que le correctif, qui met en place la nouvelle politique SBAT (UEFI Secure Boot Advanced Targeting), serait appliqu\u00e9 aux syst\u00e8mes n'utilisant que Windows et ne toucherait pas aux configurations \u00e0 double d\u00e9marrage (le correctif bloquait l'utilisation des images de d\u00e9marrage avec l'ancien GRUB pour contourner le Secure Boot sur les syst\u00e8mes ayant uniquement Windows install\u00e9). Il a \u00e9galement \u00e9t\u00e9 pr\u00e9cis\u00e9 que ce changement pourrait causer des probl\u00e8mes de d\u00e9marrage avec des images ISO de syst\u00e8mes anciens, livr\u00e9s avec une version vuln\u00e9rable de GRUB. En pratique, des probl\u00e8mes sont \u00e9galement apparus chez les utilisateurs de syst\u00e8mes \u00e0 double d\u00e9marrage utilisant de nouvelles distributions Linux, comme Ubuntu 24.04 et Debian 12.6, dans lesquelles la vuln\u00e9rabilit\u00e9 dans GRUB a \u00e9t\u00e9 longtemps corrig\u00e9e. <\/p>\n
Le probl\u00e8me se manifeste par l'arr\u00eat du processus de d\u00e9marrage avec le message \u00ab V\u00e9rification des donn\u00e9es SBAT de shim \u00e9chou\u00e9e : violation de la politique de s\u00e9curit\u00e9. Quelque chose a mal tourn\u00e9 : l'auto-v\u00e9rification de SBAT a \u00e9chou\u00e9 : violation de la politique de s\u00e9curit\u00e9 \u00bb. Pour restaurer le fonctionnement, il est recommand\u00e9 de supprimer les donn\u00e9es SBAT install\u00e9es dans l'UEFI, ce qui peut \u00eatre fait en d\u00e9sactivant le Secure Boot dans le firmware, en d\u00e9marrant un nouveau distribution Linux prenant en charge UEFI Secure Boot, comme Ubuntu, en ex\u00e9cutant la commande dans le terminal \u00ab mokutil --set-sbat-policy delete \u00bb, puis en red\u00e9marrant la distribution Linux pour appliquer la politique SBAT correcte. Apr\u00e8s cela, vous pouvez r\u00e9activer le mode Secure Boot dans le firmware. <\/p>\n
Le m\u00e9canisme SBAT a \u00e9t\u00e9 d\u00e9velopp\u00e9 par Red Hat en collaboration avec Microsoft pour bloquer les vuln\u00e9rabilit\u00e9s dans le chargeur GRUB et l'interface shim sans r\u00e9voquer la signature num\u00e9rique. SBAT implique l'ajout de m\u00e9tadonn\u00e9es suppl\u00e9mentaires aux fichiers ex\u00e9cutables des composants UEFI, qui incluent des informations sur le fabricant, le produit, le composant et la version. Ces m\u00e9tadonn\u00e9es sont sign\u00e9es num\u00e9riquement et peuvent \u00eatre incluses s\u00e9par\u00e9ment dans les listes de composants autoris\u00e9s ou bloqu\u00e9s pour le d\u00e9marrage s\u00e9curis\u00e9 UEFI. SBAT permet de bloquer l'utilisation d'une signature num\u00e9rique pour des num\u00e9ros de version sp\u00e9cifiques des composants sans avoir \u00e0 r\u00e9voquer les cl\u00e9s pour le d\u00e9marrage s\u00e9curis\u00e9. <\/p>\n
Le blocage des vuln\u00e9rabilit\u00e9s via SBAT ne n\u00e9cessite pas l'utilisation de la liste des certificats r\u00e9voqu\u00e9s UEFI (dbx), mais se fait au niveau du remplacement de la cl\u00e9 interne pour g\u00e9n\u00e9rer des signatures et mettre \u00e0 jour GRUB2, shim et d'autres artefacts de d\u00e9marrage fournis par les distributions. Avant l'impl\u00e9mentation de SBAT, la mise \u00e0 jour de la liste des certificats r\u00e9voqu\u00e9s (dbx, UEFI Revocation List) \u00e9tait une condition pr\u00e9alable \u00e0 un blocage complet de la vuln\u00e9rabilit\u00e9, car un attaquant, quelle que soit l'OS utilis\u00e9e, pouvait compromettre le d\u00e9marrage s\u00e9curis\u00e9 UEFI en utilisant un support de d\u00e9marrage avec une ancienne version vuln\u00e9rable de GRUB2, sign\u00e9e num\u00e9riquement. \n Source : opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"