Vulnérabilité de l'ACPI Secure Boot - GRUB 2 - (CVE-2020-14372)

^{​​​​​​​}Résumé

Red Hat est conscient d'une vulnérabilité dans le chargeur de démarrage GRUB 2 ayant un impact sur les produits Red Hat, y compris Red Hat Enterprise Linux (RHEL). Cette faille permet à un attaquant, déjà présent sur le système, de contourner les protections du Secure Boot pour charger des modules de noyau non signés. Cette vulnérabilité n'affecte que les systèmes utilisant UEFI Secure Boot, qui est destiné à protéger les systèmes en vérifiant le logiciel utilisé pour amorcer un système. La seconde vulnérabilité est nommée CVE-2020-14372 et comporte un niveau de sévérité Modéré. Il est recommandé aux clients de Red Hat qui utilisent les versions concernées d'appliquer les mises à jour. 

Les versions et les contenants des produits Red Hat suivants sont soit directement touchés, soit potentiellement touchés :

• Red Hat Enterprise Linux 7

• Red Hat Enterprise Linux 8

• Red Hat Enterprise Atomic Host

• Red Hat OpenShift Container Platform 4 ^[1]

^[1] Ces produits contiennent du contenu de Red Hat Enterprise Linux (RHEL) et publieront des alertes avec du contenu mis à jour peu après la publication des alertes pour RHEL.

• Les conteneurs de produits qui utilisent l'image de base de Red Hat Enterprise Linux. Les images de base seront mises à jour pour inclure les corrections de cette vulnérabilités, veuillez vous assurer que les conteneurs sont à jour. L'index de santé des conteneurs (Container Health Index), qui fait partie du Red Hat Container Catalog, peut toujours être utilisé pour vérifier le statut de sécurité des conteneurs Red Hat.

• Les produits qui extraient des packages du canal RHEL. Veuillez vous assurer que le package Red Hat Enterprise Linux sous-jacent est à jour dans ces environnements de produits.

Pour déterminer si votre système est actuellement concerné par ces failles de sécurité, voir la section Diagnostic ci-dessous. De plus, un playbook Ansible pour la remédiation automatique est fourni ci-dessous.

Résumé technique

Dans CVE-2020-14372, un attaquant peut utiliser la faille GRUB 2 pour contourner le mécanisme d’amorçage du système sécurisé une fois le noyau Linux chargé. L'attaquant peut exploiter la faille en demandant à grub (via son fichier de configuration), après un redémarrage, de charger une table ACPI (Advanced Configuration and Power Interface) personnalisée qui désactive le mécanisme de verrouillage du noyau, permettant ainsi au code non signé d'être chargé dans l'espace du noyau, ce qui peut compromettre l'intégrité, la confidentialité et la disponibilité des données du système.

Il convient de noter que cela ne concerne que les environnements utilisant Secure Boot, et nécessite des privilèges élevés. Un attaquant devra avoir déjà obtenu le contrôle physique ou des privilèges de niveau superutilisateur (root) pour utiliser cette vulnérabilité. 

NOTE : Une mise à jour de shim sera publiée lorsqu'elle sera prête, ce qui inclut l'introduction de la technologie SBAT (voir la section contexte pour plus d'informations sur la SBAT) . Cela permettra de s'assurer que les mises à jour de shim sont correctement testées avant leur publication et d'éviter l'introduction de bogues dans le système d'amorçage.

Mesures de mitigation

Il n'y a pas de mesures d'atténuation disponibles pour cette vulnérabilité.

Détails techniques

Le chargeur de démarrage GRUB 2 supporte plusieurs modules et commandes, qui peuvent être utilisés pour modifier le comportement du chargeur de démarrage ou étendre ses fonctionnalités. Lorsque le système est démarré à l'aide de la technologie Secure Boot, tous les modules de chargement doivent être conformes et refuser de permettre à l'utilisateur de charger du code non signé. Cette vulnérabilité permet à l'option de commande GRUB 2 ACPI de ne pas respecter les restrictions du Secure Boot. Ce problème permet à un agent malveillant de charger des tables ACPI élaborées, qui peuvent modifier l'environnement, ce qui conduit à un contournement de Secure Boot.

Un attaquant disposant de privilèges root locaux peut placer une table de description du système secondaire (SSDT) sur le système et modifier le fichier de configuration de grub pour lui faire charger la SSDT malveillante. La table ACPI élaborée est ensuite exécutée par le noyau, écrasant la variable de verrouillage du noyau, ce qui permet à l'attaquant de charger des modules du noyau non signés et du code kexec non signé. 

Cet événement nécessitera la révocation des hachages de shim. Une nouvelle technologie, appelée Secure Boot Advanced Targeting (SBAT), est en cours de préparation et devrait être publiée dans les semaines à venir, dans le package shim suite à cette divulgation. Cela remplacera la fonctionnalité qui était auparavant gérée par le package dbxtool pour ce processus. Voir la section ci-dessous pour plus de détails. 

Pour plus d'informations sur l'ACPI et le SSDT, veuillez consulter la section Références au bas de cet article. 

CVE-2020-14372

Une faille a été trouvée dans GRUB 2, qui active incorrectement l'utilisation de la commande ACPI lorsque le démarrage sécurisé est activé. Cette faille permet à un attaquant ayant un accès privilégié de créer une table de description du système secondaire (SSDT) contenant du code pour écraser le contenu de la variable de verrouillage du noyau Linux directement en mémoire. La table est ensuite chargée et exécutée par le noyau, ce qui permet de compromettre le verrouillage du système d'amorçage sécurisé et permet à l'attaquant de charger du code non signé. Le danger principal lié à cette vulnérabilité est une violation potentielle de la confidentialité et de l'intégrité des données ainsi que de la disponibilité du système. 

Le 2 mars 2021, six autres vulnérabilités de GRUB 2, tous de gravité modérée, ont également été rendus publics. Consultez les pages du CVE correspondantes pour plus de détails.

• CVE-2020-25632 grub2 : use-after-free dans la commande rmmod

• CVE-2020-25647 grub2 : out-of-bound write dans grub_usb_device_initialize()

• CVE-2020-27749 grub2 : dépassement de la mémoire tampon dans grub_parser_split_cmdline

• CVE-2020-27779 grub 2 : la commande cutmem permet à l'utilisateur privilégié de supprimer des zones de mémoire lorsque le démarrage sécurisé est activé

• CVE-2021-20225 grub2 : segment de mémoire d’écriture hors limite niveau analyseur syntaxique abbrégé.

• CVE-2021-20233 grub2 : segment de mémoire d’écriture hors limite en raison d'un mauvais calcul de l'espace requis pour les citations

Contexte

Pour plus d'informations sur Secure Boot et son fonctionnement, consultez l'article What is UEFI Secure Boot and how it works? ?

L'événement BootHole de la mi-2020 a nécessité une révocation massive des binaires signés et de la rotation des certificats existants, entraînant une perturbation des mises à jour de shim et de grub, ainsi qu'une forte augmentation de la consommation d'espace DBX. 

En conséquence, des améliorations au mécanisme de révocation de l'UEFI ont été nécessaires car les composants impliqués dans le chemin de démarrage peuvent évoluer plus rapidement et plus facilement que le micrologiciel de l'UEFI. L'introduction d'un nouveau mécanisme de révocation basé sur la génération, connu sous le nom de modèle UEFI Secure Boot Advanced Targeting (SBAT), sera publié dans les prochaines semaines dans le cadre de cette divulgation dans le package shim. Ce mécanisme permet de cibler une révocation plus facile des composants compromis de la chaîne de démarrage. 

Le développement du SBAT est le fruit d'une collaboration entre la communauté Linux et Microsoft, et consiste à adopter de nouvelles métadonnées dans tous les binaires de l'UEFI, afin d'envoyer des informations sur le fournisseur, la famille de produits, le produit, le composant, la version et la génération. Ces métadonnées sont signées numériquement et peuvent être incorporées dans la liste d'autorisation ou de refus du mécanisme UEFI Secure Boot. 

Cela permet de tirer parti des futurs événements de révocation, car les outils de chaîne d'amorçage contiendront des numéros de génération globaux, ce qui permettra de remplacer plusieurs entrées de hachage ou de signature en ne spécifiant qu'une seule entrée de métadonnées dans la liste de révocation. 

Pour plus d'informations techniques sur le SBAT, consultez le document “UEFI shim bootloader secure boot life-cycle improvements”

Avec le changement du mécanisme SBAT, Red Hat n'aura pas besoin de faire tourner en rotation les clés de démarrage sécurisé et de retirer tous les composants de confiance (paquets : noyau, shim, grub2 et fwupd) car la clé actuelle sera maintenue active et autorisée à démarrer.

Impact sur les produits

Red Hat Enterprise Linux (RHEL) 7 et 8, Red Hat Enterprise Atomic Host, et RHEL CoreOS (qui fait partie de la plate-forme de conteneurs Openshift 4) fournissent la version vulnérable de GRUB 2. 

Mises à jour des produits concernés

Nous conseillons à tous les clients de Red Hat exécutant des versions de produits Red Hat affectés de procéder aux mises à jour dès que les correctifs sont disponibles.

[1] Le lien "Avis/Mise à jour" sera ajouté une fois que les mises à jour seront mises en ligne.

[2] Qu'est-ce que l'abonnement à Red Hat Enterprise Linux Extended Update Support (EUS) ?

[3] Qu'est-ce que l'Advanced mission critical Update Support (AUS) ?

[4] Qu'est-ce que l'abonnement à Red Hat Enterprise Linux SAP Solutions ?

[5] L'accès à ce patch nécessite un abonnement actif à Extended Life-cycle Support (ELS). Veuillez contacter le service commercial de Red Hat ou votre représentant commercial spécifique pour plus d'informations si votre compte n'a pas d'abonnement ELS actif.

[6] Les conteneurs de produits qui utilisent l'image de base de Red Hat Enterprise Linux. Les images de base seront mises à jour pour inclure les corrections de cette vulnérabilités, veuillez vous assurer que les conteneurs sont à jour. L'index de santé des conteneurs (Container Health Index), qui fait partie du Red Hat Container Catalog, peut toujours être utilisé pour vérifier le statut de sécurité des conteneurs Red Hat.

[7] Les composants Red Hat CoreOS affectés consomment du contenu RHEL, et seront reconstruits et publiés en tant qu'avis pour la plateforme de conteneurs Red Hat OpenShift.

Diagnostic

Un script de détection a été développé afin de déterminer si votre système est actuellement concerné par cette faille de sécurité. Pour vérifier la légitimité du script, vous pouvez télécharger la signature GPG détachée également. Les instructions sur la manière d'utiliser la signature GPG pour la vérification sont disponibles sur le portail client.

Playbook Ansible

De plus, un playbook Ansible, est fourni ci-dessous. Ce playbook met à jour tous les paquets pertinents. Pour utiliser le playbook, spécifiez les hôtes que vous souhaitez mettre à jour avec la var. extra HOSTS :

ansible-playbook -e HOSTS=<myhosts> CVE-2020-14372-update_fixit.yml

Pour vérifier la légitimité du playbook, vous pouvez télécharger la signature OpenPGP détachée également. Les instructions sur la manière d'utiliser la signature GPG pour la vérification sont disponibles sur le portail client.

Remerciements

Red Hat remercie Máté Kukri, qui a découvert et signalé cette vulnérabilité. Red Hat remercie également les partenaires dans l’industrie, ainsi que ceux de la communauté GNU GRUB pour leur collaboration sur cette question.

Références

Comment utiliser GPG pour vérifier le contenu signé de la Sécurité produits

Vulnérabilité Boot Hole - GRUB 2 boot loader - CVE-2020-10713 

Utilisation de la ligne de commande ACPI de GRUB

​​​​​​​Utilisation des couches SSDT dans ACPI