Vulnérabilité Amorçage système - GRUB 2 boot loader - (CVE-2020-10713)

Récapitulatif

Red Hat répond actuellement à une faille du chargeur de démarrage GRUB 2 ayant un impact sur nos produits, y compris Red Hat Enterprise Linux. Cette faille permet à un attaquant, déjà présent sur le système, de détourner le processus d'amorçage et d'exécuter un code malveillant lors du démarrage du système. Les systèmes utilisant UEFI Secure Boot, qui protège les systèmes en vérifiant le logiciel utilisé pour démarrer un ordinateur, peuvent également être contournés par cette vulnérabilité. Cette question est classée CVE-2020-10713 et a un impact de gravité Modéré. Il est recommandé aux clients de Red Hat qui utilisent les versions concernées d'appliquer les mises à jour. Red Hat recommande également la mise à jour des images les plus récentes et de la dernière version des systèmes hôtes de conteneurs.

Les versions de produits Red Hat suivants sont affectées :

• Red Hat Enterprise Linux 7

• Red Hat Enterprise Linux 8

• Red Hat Atomic Host 

• * OpenShift Container Platform 4 (RHEL CoreOS)

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 le CVE-2020-10713, un attaquant peut utiliser la faille GRUB 2 pour détourner et altérer le processus de vérification GRUB. Cette faille permet également de contourner les protections Secure Boot. Pour charger un noyau non fiable ou modifié, un attaquant doit d'abord établir un accès au système comme en obtenant un accès physique, ayant ainsi la possibilité de modifier un réseau pxe-boot, ou en ayant un accès à distance vers un système en réseau avec accès privilégié (root). Avec cet accès, un attaquant peut alors créer une chaîne de caractères provocant un débordement de mémoire tampon en injectant une charge utile malveillante qui conduirait à l'exécution de code arbitraire dans GRUB. 

Pour assurer la protection de Secure Boot et empêcher le chargement de code non fiable au démarrage du système, des clés et des certificats nouvellement validés sont délivrés pour les paquets grub2, kernel, fwupdate, fwupd, shim et dbxtool.

Mesure de mitigation

Il n'y a pas de mesure de mitigation pour cette faille. 

Remédiation

Red Hat recommande à tous ses clients de mettre à jour leurs paquets grub2. Les clients de Red Hat qui utilisent Secure Boot doivent mettre à jour les paquets de noyau, fwupdate, fwupd, shim et dbxtool contenant les clés et certificats nouvellement validés.

Les utilisateurs qui utilisent Secure Boot avec Red Hat Enterprise Linux 8 doivent prendre des mesures supplémentaires pour démarrer dans les noyaux RHEL 8 précédemment publiés après avoir appliqué les mises à jour du paquet grub2. Voir la section RHEL 8 ci-dessous pour plus de détails.

Détails techniques

Le chargeur de démarrage GRUB 2 est configurable via le fichier grub.cfg, qui est composé de plusieurs jetons de chaîne. Le fichier de configuration est chargé et analysé à l'initialisation de GRUB juste après que le chargeur de démarrage initial, nommé shim, l'ait chargé. Lors de l'étape d'analyse, les valeurs de configuration sont copiées dans les tampons internes stockés en mémoire. Les jetons de configuration dont la longueur est supérieure à la taille du tampon interne finissent par déclencher un problème de dépassement de capacité de la mémoire tampon. Un attaquant peut exploiter cette faille en exécutant un code arbitraire, compromettant ainsi encore plus le processus de démarrage de la machine, et contournant la protection Secure Boot. Par conséquent, il est possible que du code binaire non signé soit chargé, compromettant ainsi davantage l'intégrité du système.

Contexte

Qu'est-ce que l'UEFI Secure Boot et comment fonctionne-t-il ?

Secure Boot est une fonction de sécurité du micrologiciel UEFI développée par le consortium UEFI qui garantit que seuls les logiciels immuables et signés sont chargés pendant la période d’amorçage du système. Secure Boot exploite la cryptographie et la signature numérique pour valider l'authenticité, la source et l'intégrité du code chargé. Ces mesures de validation sont prises pour empêcher le chargement de code malveillant et pour empêcher les attaques, comme, par exemple, par l'installation de certains types de rootkits. Pour plus d'informations sur l'UEFI et le Secure Boot, voir UEFI Secure Boot in Modern Computer Security Solutions. 

Les applications de confiance sont signées par une Autorité de certification centrale. Le certificat public est stocké dans le matériel, ce qui permet aux applications EFI tierces signées par ce certificat de charger avec succès.

Sur les versions de Red Hat Enterprise Linux qui prennent en charge le démarrage sécurisé, l'application signée et fiable est le paquet de shim, qui est la première application chargée par le microprogramme de la machine. Le paquet de shim lui-même contient le certificat de Red Hat et ses propres bases de données de clés de confiance et de hachages de code qui peuvent être chargées. Ces données sont utilisées pour vérifier la signature du chargeur de démarrage, qui est GRUB 2, en s'assurant qu'elle n'a pas été compromise ou altérée par un acteur malveillant. Une fois la vérification réussie, GRUB est chargé et vérifie la signature du noyau et confirme qu'elle correspond au certificat de Red Hat ou à tout hachage enregistré par l'utilisateur lui-même dans la base de données d'autorisation Allow DB. S'il y a une correspondance, GRUB chargera le noyau, ce qui termine le processus d’amorçage du système.

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. 

Red Hat Enterprise Linux 8

En raison du durcissement du noyau, qui est publié dans le cadre de ces mises à jour, les versions précédentes du noyau Red Hat Enterprise Linux 8 n'ont pas été ajoutées à la liste d'autorisation de shim. Si vous exécutez votre système avec Secure Boot activé et que l'utilisateur doit démarrer avec une ancienne version du noyau, son hachage doit être enregistré manuellement dans la liste de confiance. Pour ce faire, il faut exécuter les commandes suivantes :

# pesign -P -h -i /boot/vmlinuz-<version>

# mokutil --import-hash <hash value returned from pesign>

# reboot

Red Hat Enterprise Linux 7

Red Hat a ajouté les hachages précédents du noyau Red Hat Enterprise Linux 7 dans la base de données d'autorisation des shims, permettant ainsi aux utilisateurs de Secure Boot de démarrer avec d’anciennes versions du noyau. 

* Red Hat Atomic Host

Pour l'instant, la mise à jour des binaires de shim sur RHEL Atomic Host n'est pas possible. Les clients doivent évaluer la question et décider si le provisionnement des nœuds à l'aide de supports d'amorçage mis à jour est justifié.

* OpenShift Container Platform 4 (RHEL CoreOS)

Pour l'instant, Red Hat n'envoie pas de mises à jour pour la partition du système EFI (y compris shim, grub) pour RHEL CoreOS. Une bonne pratique acceptée consiste à réapprovisionner les nœuds périodiquement ; les clients peuvent le faire en utilisant les "images de démarrage" mises à jour Les clients doivent évaluer leur impact et décider s'il est justifié de mettre à jour les images de démarrage à ce moment-là.

Étant donné que la vulnérabilité affecte principalement l'intégrité des systèmes à nu avec Secure Boot activé, la mise à jour et l'utilisation des nouvelles images de démarrage est la seule action recommandée. Les étapes de mise à jour des images de démarrage varient et dépendent de la manière dont les clients ont approvisionné leur infrastructure à nu. Ce processus peut nécessiter la mise à jour de la configuration PXE de votre infrastructure d’amorçage pour fournir de nouvelles images de démarrage, ou il peut impliquer la réinstallation de vos systèmes à nu en utilisant une mise à jour de l'ISO d'installation et des images de disque de système à nu. Les clients doivent tenir compte de leur environnement et se référer à la documentation OpenShift pour savoir comment mettre à jour les images de démarrage convenablement. Pour plus d'informations, voir : Installing a cluster on bare metal. 

S'il est nécessaire de réapprovisionner les nœuds avec des images de démarrage mises à jour, les clients doivent prendre les mesures nécessaires pour encercler d’un cordon et vider les nœuds qu'ils souhaitent réapprovisionner. Les clients doivent réapprovisionner leurs nœuds un à un pour éviter de perturber la santé globale du groupe.

Pour entourer un noeud d’un cordon :

$ oc adm cordon <node name>

Pour drainer un nœud :

$ oc adm drain <node name>

Une fois qu'un nœud a été entouré d’un cordon et draîné avec succès, les clients doivent initier un redémarrage et une réinstallation du nœud, puis confirmer qu'il a été correctement réapprovisionné avec les images de démarrage mises à jour.

Mises à jour des produits concernés

Le paquet shim initialement publié a été remplacé par une nouvelle version. Les paquets shim mis à jour sont disponibles et peuvent être utilisés en conjonction avec les paquets grub2, fwupd et fwupdate précédemment publiés. Pour plus d'informations sur les paquets shim initiaux, voir https://access.redhat.com/solutions/5272311. Red Hat recommande vivement aux clients qui utilisent les versions concernées d'appliquer les mises à jour disponibles.

¹ Qu'est-ce que l'abonnement Red Hat Enterprise Linux Extended Update Support (EUS) ?

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

³ Qu'est-ce que l'abonnement Red Hat Enterprise Linux SAP Solutions ?

⁴ Atomic Host

⁵Le lien "Avis/Mise à jour" sera ajouté une fois les mises à jour en ligne.

⁶Le paquet shim initialement publié a été remplacé par une nouvelle version. Les paquets shim mis à jour sont disponibles et peuvent être utilisés en conjonction avec les paquets grub2, fwupd et fwupdate précédemment publiés. Pour plus d'informations sur les paquets shim initiaux, voir https://access.redhat.com/solutions/5272311.

⁷ Des paquets dbxtool mis à jour ont été publiés pour RHEL 8 afin de corriger des bogues connus dans les fonctionnalités. Les instructions pour appliquer la mise à jour de DBX se trouvent dans l'article suivant - Comment mettre à jour la base de données de signatures interdites (DBX) de Secure Boot avec le dernier fichier de la liste de révocation de l'UEFI

Diagnostic

Le script de détection des vulnérabilités est destiné aux versions de Red Hat Enterprise Linux actuellement prises en charge. Le script de détection peut également être utilisé sur les produits en couches apposés au dessus de Red Hat Enterprise Linux auxquelles les clients ont accès pour exécuter le script.

Playbook Ansible

De plus, un playbook Ansible, "CVE-2020-10713-update_fixit.yml", est fourni ci-dessous. Ce guide met à jour tous les paquets pertinents. Pour utiliser le playbook, indiquez les hôtes que vous souhaitez mettre à jour dans var. extra HOSTS :

ansible-playbook -e HOSTS=<myhosts> CVE-2020-10713-update_fixit--2020-07-29-1613.yml

Pour vérifier la légitimité du playbook, vous pouvez télécharger la signature OpenPGP détachée.

FAQ

Q : Comment puis-je vérifier si mon système a Secure Boot activé ?

R : Il est possible de vérifier si la fonction Secure Boot est activée en exécutant la commande suivante :

    $ mokutil --sb-state

SecureBoot enabled

  REMARQUE : sur les systèmes dont l'amorçage sécurisé est désactivé, l'utilisation de la commande mokutil avec n'importe quelle variable affichera le résultat suivant :  

# mokutil -l

Les variables EFI ne sont pas prises en charge par ce système

Q: Dois-je réamorcer (reboot) ou redémarrer quelque chose après avoir installé des paquets mis à jour ?

R : Oui, un redémarrage est nécessaire pour garantir l'utilisation des composants mis à jour.

Q : Quel est l'impact sur les conteneurs ?

R: Bien que les conteneurs Linux de Red Hat ne soient pas directement affectés par les problèmes du noyau, leur sécurité dépend de l'intégrité de l'environnement du noyau hôte. Red Hat recommande également la mise à jour des images les plus récentes et de la dernière version des systèmes hôtes de conteneurs. Pour protéger la confidentialité des conteneurs utilisés, vous devrez appliquer et déployer les mises à jour sur l'hôte du conteneur (tel que Red Hat Enterprise Linux ou Atomic Host). 

Q : J'utilise Red Hat Enterprise Linux 7 et je ne suis pas en mesure de mettre à jour la version de mon noyau. Dois-je enregistrer la valeur de hachage de la version de mon noyau dans une base de données fiable ?

R : Ce n'est pas nécessaire. Les anciennes versions de noyau pour Red Hat Enterprise Linux 7 seront automatiquement ajoutées à la liste des autorisations de shim.

Dois-je enregistrer la valeur de hachage de la version de mon noyau dans la base de données fiable (trusted DB) ?

R : Oui, les anciennes versions du noyau de Red Hat Enterprise Linux 8 ne seront pas fiables par défaut. Pour pouvoir démarrer une version antérieure du noyau, vous pouvez exécuter les commandes suivantes en tant qu'utilisateur root :

# pesign -P -h -i /boot/vmlinuz-<version>

# mokutil --import-hash <hash value returned from pesign>

# reboot

Q : Si je n'utilise pas Secure Boot, puis-je continuer à démarrer dans les versions précédentes des noyaux RHEL 7 et 8 sans aucune modification après avoir appliqué cette mise à jour à GRUB ? 

R : Oui, si l'option "Secure Boot" est désactivée, aucune vérification de signature n'est effectuée. Ainsi, les versions précédentes du noyau seront toujours amorçables sans aucune autre action requise.

Q : Quand les nouvelles mises à jour de DBX seront-elles appliquées dans le micrologiciel de l'UEFI ?

R : En conséquence de cette faille de sécurité de GRUB, la signature précédente de Red Hat Secure Boot sera révoquée et placée dans la base de données Disallow DB (DBX), et une nouvelle signature sera utilisée lorsque les clients appliqueront la mise à jour dbxtool. Un nouveau fichier DBX est inclus dans la mise à jour, qui contient également la révocation des anciennes clés Red Hat. Toutefois, la mise à jour dbxupdate ne sera pas effectuée par défaut et est destinée aux professionnels de l'informatique qui souhaitent exclure les anciennes clés. Une nouvelle mise à jour de dbxtool, obligatoire et automatique, sera publiée dans les mois à venir pour révoquer indéfiniment les clés de Red Hat pour tous les clients de Red Hat.  

Q : La vulnérabilité affecte le code du programme qui fonctionne indépendamment de l'utilisation de Secure Boot. En quoi l'impact de la vulnérabilité diffère-t-il alors entre les systèmes compatibles avec Secure Boot et les autres systèmes ?

R : Le mécanisme de démarrage sécurisé Secure Boot est conçu pour permettre au microprogramme de la machine et aux composants ultérieurs du chargeur de charger uniquement du code non modifié, fiable et signé. Cela signifie que l'amorçage sécurisé Secure Boot impose une limite de sécurité supplémentaire qui sert à atténuer toute tentative de chargement de logiciels non fiables pendant la phase d'amorçage (chargeur d'amorçage, noyau et modules du noyau). Comme la faille GRUB 2 permet l'exécution de code arbitraire, un attaquant peut s'en servir pour contourner toute vérification de signature ou exécuter du code non fiable en franchissant la limite de sécurité imposée par Secure Boot, mettant ainsi en péril l'intégrité du noyau chargé. 

Lorsque Secure Boot est désactivé, aucune vérification de signature n'est effectuée ; par conséquent, il n'y a pas de limite de sécurité supplémentaire à franchir. Étant donné que cette faille permet de charger n'importe quel code, cette faille de GRUB sans amorçage sécurisé peut être traitée comme n'importe quelle autre faille qui permet l'exécution de code arbitraire.

Q : Que dois-je faire lorsque le système s'arrête après POST et que le menu grub ne se charge pas après l'application de la norme RHSA-2020:3216 ou RHSA-2020:3217 ?

R : Voir la réponse dans l'article sur la solution  https://access.redhat.com/solutions/5272311. Le samedi 1er août 2020, Red Hat a publié des paquets shim actualisés qui traitent de cette question. Il est fortement recommandé aux clients de Red Hat de ne pas utiliser l'ancien paquet shim publié dans le cadre de RHSA-2020:3216 ou RHSA-2020:3217 et d'utiliser plutôt le paquet shim (ou un paquet plus récent) publié avec RHBA-2020:3262 et RHBA-2020:3265.  

Remerciements

Red Hat remercie Jesse Michael et Mickey Shkatov d'Eclypsium, pour avoir découvert et signalé cette vulnérabilité. Red Hat remercie également les partenaires industriels et la communauté GNU GRUB pour leur collaboration sur cette question. 

Références

• Eclypsium - Il y a une vulnérabilité au niveau amorçage du système 
• Comment appliquer le fichier DBX mis à jour dans les mises à jour de dbxtool
• Travailler dans GRUB 2
• UEFI Secure Boot pour Solutions Modernes de Sécurité informatique
• Comment utiliser le GPG pour vérifier le contenu signé de Sécurité produits