Comment corriger l'erreur de démarrage sécurisé "Impossible de vérifier l'image avec * ACCESS DENIED *" au démarrage?
Lorsque j'ai démarré ma machine ce matin (le démarrage sécurisé et l'UEFI sont activés uniquement), le message d'erreur suivant s'affiche (désolé pour une image de mauvaise qualité):
Qu'est-ce que cela signifie par Image failed to verify with *ACCESS DENIED*? Après avoir appuyé sur OKname__, j’ai réussi à accéder à mon BIOS et à désactiver le démarrage sécurisé ainsi que la configuration de l’option UEFI pour accepter à la fois UEFI et Legacy. que le démarrage sécurisé est à nouveau activé et que cela constitue une menace pour la sécurité, je me demande donc quel est le problème ici? Et pourquoi j'ai eu l'erreur? Je veux dire, y a-t-il une erreur à régler? Et pourquoi at-il *ACCESS DENIED* moi?
La seule chose que je puisse penser que j'aurais pu faire hier soir avant que ce problème ne se produise ce matin est de recevoir des mises à jour de sécurité pour Grub et quelques autres éléments:
Donc, fondamentalement, j'ai besoin de savoir ce que l'erreur signifie, pourquoi je l'ai eu et comment remédier à cette situation. Je veux dire, cette erreur pourrait-elle signifier que j'ai été compromis d'une manière ou d'une autre et que je devrais effectuer une nouvelle installation ou quelque chose d'autre? Ou est-ce juste un dysfonctionnement? Et si oui, comment puis-je résoudre le problème pour pouvoir utiliser à nouveau Secure Boot?
J'utilise Ubuntu GNOME 15.10 avec GNOME 3.18 sur un Lenovo B590.
Mise à jour des informations:
Le résultat de la commande efibootmgrest:
BootCurrent: 000E
Timeout: 0 seconds
BootOrder: 000E,0000,0001,0002,0003,000C,0006,0007,0008,0009,000A,000B,000D
Boot0000 Setup
Boot0001 Boot Menu
Boot0002 Diagnostic Splash Screen
Boot0003 Lenovo Diagnostics
Boot0004 Startup Interrupt Menu
Boot0005 Rescue and Recovery
Boot0006* USB CD
Boot0007* USB FDD
Boot0008* ATAPI CD1
Boot0009* ATA HDD0
Boot000A* ATA HDD1
Boot000B* ATA HDD2
Boot000C* USB HDD
Boot000D* PCI LAN
Boot000E* ubuntu
Les packages GRUB ont été mis à jour hier (15 décembre 2015): 2.02~beta2-29ubuntu0.2.
Peut-être que quelque chose s'est mal passé lors de la mise à niveau, mais il ne devrait pas y avoir de problème de sécurité.
Remettez les paramètres du BIOS à l'état dans lequel vous avez installé Ubuntu.
Ensuite, réinstallez le chargeur de démarrage GRUB sur votre installation Ubuntu en mode EFI.
Démarrez à partir du support d'installation Ubuntu - ouvrez un terminal et exécutez:
Sudo mount /dev/sd*** /mnt
Sudo mount /dev/sd** /mnt/boot/efi
for i in /dev /dev/pts /proc /sys /run; do Sudo mount -B $i /mnt$i; done
Sudo chroot /mnt
grub-install /dev/sd*
update-grub
Remarque:
sd* = disk | sd** = partition efi | sd*** = partition système
Pour identifier les numéros de disque et de partition, vous pouvez utiliser GParted.
Démarrez dans le BIOS et sélectionnez Ubuntu comme système d'exploitation par défaut.
Référence USN: avis de sécurité d'Ubuntu 2836-1: vulnérabilité GRUB
Si cela ne fonctionne pas, vous pouvez également utiliser l'outil de réparation de démarrage.
Démarrez à partir du support d'installation Ubuntu, ouvrez un terminal et exécutez:
Sudo add-apt-repository ppa:yannubuntu/boot-repair
Sudo apt-get update
Sudo apt-get install -y boot-repair && boot-repair
Selon https://bugs.launchpad.net/bugs/1528345 ceci est causé par les mises à jour de sécurité envoyées par Ubuntu pour grub de manière incorrecte et peut être corrigé en installant le paquet grub-efi-AMD64. -signed, puis en réactivant le démarrage sécurisé dans le BIOS. Cela a fonctionné pour moi. (J'ai également vérifié que la réinstallation du paquet entraînait shimx64.efi dans la sortie de efibootmgr -v au lieu de grubx64.efi, qui était là alors que le problème était présent.)
Tout d’abord, revenez dans votre firmware et désactivez le support CSM ("legacy boot"). Si vous démarrez dans un environnement purement EFI, comme cela semble être le cas, cette option ne vous servirait à rien et pourrait revenir vous piquer plus tard. (Voir ma page sur le sujet pour plus d'informations sur les problèmes de CSM.)
Deuxièmement, le message d'erreur indique que votre ordinateur a tenté de démarrer un chargeur de démarrage qui n'a pas été signé avec une clé de démarrage sécurisée autorisée. (Certains des messages signalant de telles violations sont assez obtus - ils varient d’une EFI à une autre et, dans certains cas, d’un programme de suivi à un autre, en fonction du lieu de la violation.) Un tel message apparaît après la L’ordinateur a démarré avec succès, et sans modification de vos programmes de démarrage ni des paramètres du micrologiciel, c’est un gros drapeau rouge.
Je n'ai vu aucune mention de mises à jour de GRUB ou de Shim. Votre processus de démarrage ne devrait donc pas avoir été affecté par ces mises à jour. OTOH, il se peut que quelque chose d’autre ait modifié le chemin d’amorçage. Cela pourrait être un changement innocent qui a mal tourné et a causé un petit problème - par exemple, si vous effectuez un triple amorçage avec une autre distribution Linux, cela peut avoir changé le chemin de démarrage en un GRUB non signé. Si tel est le cas, vous pouvez rétablir la séquence de démarrage sur GRUB d'Ubuntu (via Shim) avec efibootmgr - tapez Sudo efibootmgr -v pour afficher la commande de démarrage actuelle (sur la ligne BootOrder) et les options (le gros de la sortie). Recherchez la ligne pour Ubuntu lancée via Shim et utilisez l’option -o pour modifier l’ordre en commençant par celui-ci, comme dans Sudo efibootmgr -o 0009,0000,001B si l’entrée souhaitée est Boot0009 et que deux alternatives sont Boot0000 et Boot001B. Une autre possibilité est qu’une mise à jour Windows non liée ait interféré avec GRUB. (Microsoft a la possibilité de mettre à jour les clés de démarrage sécurisé de la plupart des ordinateurs. Si, pour une raison quelconque, ils l'ont gâché ou délibérément mis en liste noire Shim d'Ubuntu, vous pourriez voir l'erreur que vous avez décrite.)
Il y a une petite chance que quelque chose de malveillant se produise - un programme malveillant peut s'être installé dans votre chemin d'initialisation. Dans ce cas, en désactivant Secure Boot, vous avez déjà activé l'exécution du programme malveillant. On ne sait pas quelles en seraient les conséquences si tel était le cas. Je ne veux pas vous alarmer; les chances que cela se produise sont faibles. Si cela est déjà arrivé , il faudra un expert en récupération pour restaurer votre ordinateur, car il est notoirement difficile d'extraire les logiciels malveillants avant amorçage.
Il est peu probable que la mise à jour de votre configuration GRUB soit utile, bien que les chances pour que cela passe si vous permutez à GRUB de ne pas démarrer une version non signée du noyau par une version signée. (La dernière fois que j'ai vérifié, le GRUB d'Ubuntu démarrerait des noyaux non signés, mais cela pourrait changer dans le futur. Certains autres GRUB, comme celui utilisé par Fedora, sont plus stricts et ne démarreront que des noyaux signés.)
Vous pouvez vérifier votre chemin de démarrage avec efibootmgr et vérifier qu'il démarre par Shim par défaut - autrement dit, le chargeur de démarrage pour le premier élément de la commande de démarrage doit être EFI\ubuntu\shimx64.efi. Si c'est pas le cas, vous pourrez alors modifier l'ordre de démarrage. Si est le cas, votre binaire shimx64.efi est peut-être endommagé (ou pire, remplacé par un logiciel malveillant). Réinstaller complètement GRUB pourrait résoudre le problème. (Boot Repair peut le faire assez facilement.)