BootHole : cette faille qui met en échec Secure Boot

Canonical, HPE, Microsoft, SUSE, VMware… Tous ont publié, ce 29 juillet 2020, une alerte relative à BootHole.

Des chercheurs travaillant pour Eclypsium ont donné ce nom à une faille de sécurité. Immatriculée CVE-2020-10713, elle touche potentiellement tous les systèmes qui utilisent Secure Boot couplé à l’autorité de certification UEFI Microsoft.

Devenu un standard sur les PC et les serveurs, Secure Boot intervient aux premiers stade du démarrage. Il vérifie l’intégrité de tout code avant son exécution. Ce contrôle s’effectue sur la base d’une liste blanche et d’une liste noire protégées par un chiffrement en enveloppe.

Pour éviter aux fabricants d’avoir à gérer la signature de chaque code, Secure Boot permet d’utiliser une autorité de certification centralisée. Celle de Microsoft s’est imposée.

Le chargeur d’amorçage GRUB2 fait partie des codes qu’elle peut valider. Problème : c’est lui qui abrite BootHole.

GRUB2 : attention, fragile

La faille consiste en un dépassement de tampon. Elle intervient au moment où GRUB2 parcourt son fichier de configuration (grub.cfg). De manière générale, ce fichier n’est pas signé. Localisé dans la partition système EFI, il peut être – à condition de disposer de privilèges de niveau administrateur – modifié sans altérer le chargeur (ni le shim*).

Pour traiter les commandes inscrites dans le fichier de configuration, GRUB2 se sert des outils de compilation flex et bison. Avec les risques de mauvaise utilisation que cela suppose.

Eclypsium en a repéré un occurrence, au niveau de la fonction YY_FATAL_ERROR(). Il arrive que le moteur d’analyse du fichier de configuration y fasse appel, en s’attendant à voir GRUB2 se fermer en conséquence. Sauf que le chargeur affiche simplement un message d’erreur… et poursuit l’exécution. Ce qui permet de déclencher, entre autres, le dépassement de tampon en question, avec des données appropriées.

À partir de là, c’est la porte ouverte à l’exécution de code arbitraire. L’absence de protections de type DEP ou ASLR au niveau de l’UEFI facilite la tâche. La faille n’est, en outre, pas spécifique à une architecture (confirmée sur ARM64).

BootHole : Microsoft en tête de gondole

Les éditeurs de distributions Linux sont en première ligne dans ce dossier. Leur mission : modifier leur code, puis le transmettre à Microsoft pour validation.

Il s’agira ensuite de mettre à jour la liste noire dans le firmware de chaque machine dotée de Secure Boot, afin d’exclure toutes les versions de GRUB2 vulnérables.

Le processus induit des subtilités parmi lesquelles :

• Le risque qu’un OS ne se charge pas si la liste noire est mise à jour avant le bootloader
• La difficulté à mettre à jour la liste noire sur certaines configurations comme les machines en dual-boot
• L’obsolescence des supports de restauration, mettant potentiellement en danger les plans de continuité d’activité et de reprise après sinistre

Du côté de Microsoft, on dit travailler sur une mise à jour qui sera diffusée à travers Windows. Les administrateurs informatiques ont, s’ils le souhaitent, accès à une version « non testée » à installer manuellement. Autre possibilité pour eux : désactiver l’autorité de certification Microsoft. Le groupe américain fournit des consignes pour ses Surface et invite à s’adresser aux autres fabricants.

Canonical a publié une alerte de même teneur, en soulignant avoir corrigé d’autres vulnérabilités dans GRUB2 : dépassements d’entiers, absence de validation de signatures, etc. SUSE tente quant à lui de relativiser, en rappelant que l’exploitation de BootHole requiert un accès root au bootloader.

Chez HPE, la liste de serveurs et de systèmes de stockage touchés est longue. On y trouve des systèmes Cloudline, MCS, NonStop, Apollo, ProLiant, SimpliVity, Primera, StoreEasy, Nimble, 3PAR et Synergy.
Chez VMware, le principal élément à surveiller hors machines virtuelles est Photos OS, s’il est configuré avec Secure Boot.

* Le terme shim désigne la forme sous laquelle les fournisseurs de code le communiquent à Microsoft pour vérification. Ils y intègrent leur propre certificat destiné à vérifier l’intégrité de GRUB2.

Photo d’illustration ©