Un bug dans la mise à jour vers Windows bloquait le démarrage de Linux lors de l'utilisation du démarrage sécurisé UEFI.

Dans la mise à jour publiée mardi par Microsoft pour le système d'exploitation Windows, un problème a été identifié, rendant impossible le démarrage des systèmes Linux installés sur le même ordinateur en parallèle avec Windows. La cause de ce problème est un correctif visant à résoudre une ancienne vulnérabilité (CVE-2022-2601) dans le chargeur GRUB, corrigé en 2022. Microsoft n’a pas encore publié de déclaration concernant ce problème et ne l’a pas commenté.

Dans la note de mise à jour, il a été indiqué que le correctif, qui met en place la nouvelle politique SBAT (UEFI Secure Boot Advanced Targeting), serait appliqué aux systèmes n'utilisant que Windows et ne toucherait pas aux configurations à double démarrage (le correctif bloquait l'utilisation des images de démarrage avec l'ancien GRUB pour contourner le Secure Boot sur les systèmes ayant uniquement Windows installé). Il a également été précisé que ce changement pourrait causer des problèmes de démarrage avec des images ISO de systèmes anciens, livrés avec une version vulnérable de GRUB. En pratique, des problèmes sont également apparus chez les utilisateurs de systèmes à double démarrage utilisant de nouvelles distributions Linux, comme Ubuntu 24.04 et Debian 12.6, dans lesquelles la vulnérabilité dans GRUB a été longtemps corrigée.

Le problème se manifeste par l'arrêt du processus de démarrage avec le message « Verifying shim SBAT data failed: Security Policy Violation. Something has gone seriously wrong: SBAT self-check failed: Security Policy Violation ». Pour restaurer le bon fonctionnement, il est recommandé de supprimer les données SBAT installées dans l'UEFI, pour ce faire, vous pouvez désactiver le Secure Boot dans le firmware, démarrer une nouvelle distribution Linux prenant en charge le Secure Boot UEFI, par exemple, Ubuntu, exécuter la commande « mokutil —set-sbat-policy delete » dans le terminal, puis redémarrer la distribution Linux pour appliquer la configuration correcte de la politique SBAT. Après cela, vous pouvez réactiver le mode Secure Boot dans le firmware.

Le mécanisme SBAT a été développé par Red Hat en collaboration avec Microsoft pour bloquer les vulnérabilités dans le chargeur GRUB et l'interface shim sans révoquer la signature numérique. SBAT implique l'ajout de métadonnées supplémentaires aux fichiers exécutables des composants UEFI, qui incluent des informations sur le fabricant, le produit, le composant et la version. Ces métadonnées sont signées numériquement et peuvent être incluses séparément dans les listes de composants autorisés ou bloqués pour le démarrage sécurisé UEFI. SBAT permet de bloquer l'utilisation d'une signature numérique pour des numéros de version spécifiques des composants sans avoir à révoquer les clés pour le démarrage sécurisé.

Le blocage des vulnérabilités via SBAT ne nécessite pas l'utilisation de la liste des certificats révoqués UEFI (dbx), mais se fait au niveau du remplacement de la clé interne pour générer des signatures et mettre à jour GRUB2, shim et d'autres artefacts de démarrage fournis par les distributions. Avant l'implémentation de SBAT, la mise à jour de la liste des certificats révoqués (dbx, UEFI Revocation List) était une condition préalable à un blocage complet de la vulnérabilité, car un attaquant, quelle que soit l'OS utilisée, pouvait compromettre le démarrage sécurisé UEFI en utilisant un support de démarrage avec une ancienne version vulnérable de GRUB2, signée numériquement.

Source : opennet.ru

Acheter un hébergement fiable pour les sites avec protection DDoS, serveurs VPS VDS 🔥 Acheter un hébergement fiable pour les sites avec protection DDoS, serveurs VPS VDS | ProHoster