Les correctifs pour la faille BootHole Linux sont là

Les correctifs pour la faille BootHole Linux sont là

La faille de sécurité BootHole récemment révélé sur GRUB2 et Secure Boot peut, théoriquement, être utilisé pour attaquer les systèmes Linux. En pratique, les seuls systèmes Linux vulnérables sont ceux qui ont déjà été piratés avec succès par un attaquant. Ainsi, malgré toute la publicité faite autour de BootHole, ce n’est pas vraiment un gros problème. Néanmoins, presque toutes les distributions Linux pour entreprises ont publié des correctifs. Malheureusement, pour plusieurs d’entre elles, y compris Red Hat, le correctif s’est avéré pire que la faille . Les utilisateurs ont constaté que leurs systèmes nouvellement “réparés” ne démarraient plus. Maintenant, les correctifs de ces correctifs sont sortis.

Red Hat s’est immédiatement attaqué au problème. Peter Allor, directeur de l’équipe de réponse aux incidents de sécurité des produits de Red Hat, nous explique :

publicité

Red Hat a été informé d’un problème potentiel lié à la correction du CVE-2020-10713, également connu sous le nom de BootHole, selon lequel certains systèmes Red Hat Enterprise Linux 7 et Red Hat Enterprise Linux 8 pourraient ne pas redémarrer avec succès après l’application du correctif, ce qui nécessiterait une intervention manuelle. Nous étudions actuellement cette question et fournirons de plus amples informations dès qu’elles seront disponibles.

Malheureusement, il a fallu plusieurs jours pour mettre au point la solution. Mais le correctif est maintenant prêt à être déployé sur Red Hat Enterprise Linux (RHEL) 7.8 et 8.2] (https://access.redhat.com/solutions/5272311). Bien que la solution n’ait pas encore été confirmée pour RHEL 7.9 et 8.1 Extended Update Support (EUS), elle devrait également fonctionner sur ces versions.

Le correctif consiste à mettre à jour les “shim packages”. Dans ce contexte, “shim” designe un certificat UEFI (Unified Extensible Firmware Interface) Secure Boot. Il est signé par le distributeur Linux, qui est intrinsequement consideré comme fiable car il est intégré dans le shim loader signé par Microsoft. L’UEFI Secure Boot de Microsoft est utilisé parce que presque tous les ordinateurs sont préchargés avec des clés Microsoft Secure Boot.

Ces shim packages mis à jour sont disponibles dès maintenant. Vous pouvez les utiliser avec les paquets grub2, fwupd et fwupdate précédemment publiés. Pour effectuer la correction, vous devrez redémarrer en utilisant le DVD RHEL en mode de dépannage. Une fois demarré, vous entrez dans le conteneur chroot, et remplacez le shim package défectueux par la version corrigée.

Avec le système d’exploitation CentOS, les correctifs s’appliquent avec une méthode similaire. Assurez-vous de lire le CentOS BootHole repair bug report jusqu’à la fin. Au lieu de revenir à une version ancienne du shim de demarrage comme décrit au début du rapport, vous passerez à la shim-x64-15-15.el8_2.x86_64.rpm (EL8) ou respectivement à la shim-x64-15-8.el7_8.x86_64.rpm (EL7) (ou plus récente) comme décrit dans la note finale du rapport.

L’équipe de Red Hat m’a dit que le problème n’avait jamais touché Fedora, la distribution Linux communautaire de Red Hat. Les programmeurs de Fedora travaillent actuellement à la mise en place d’une solution globale pour BootHole dans un futur proche. “Cela dit, étant donné la surface d’attaque très étroite de BootHole (nécessitant déjà un accès, etc.), il est considéré comme un problème sérieux mais pas trop critique”.

Canonical rapporte qu’elle a vu très peu de cas de systèmes ne démarrant pas avec leur patch BootHole. Dans le cas où vous rencontrez ce problème, Canonical suggère de déclasser grub2/grub2-signed depuis une autre session Ubuntu. Avec une machine locale, cela peut se faire avec un DVD live Ubuntu ou une clé USB amorçable. Sur le cloud, vous pouvez le faire à partir d’une instance séparée sur la même zone de disponibilité du cloud. Dans les deux cas, vous utilisez les mêmes étapes finales. C’est-à-dire que vous montez le volume/périphérique racine du système concerné dans l’instance cloud, vous y accedez grace à chroot et vous utilisez apt pour déclasser grub2/grub2-signed/.

Comme pour Debian Linux, le correctif de BootHole est disponible dans la dernière version de Debian 10 “Buster” : Debian 10.5.

Si la distribution Linux de votre choix n’a pas encore de correctif, j’ai une suggestion. Attendez. Ne corrigez pas votre système avant que le correctif final ne soit disponible. Habituellement, je m’efforce de corriger les bugs de sécurité le plus rapidement possible. Celui ci est une exception. BootHole n’est pas vraiment un problème sérieux, mais ne pas pouvoir faire fonctionner votre système à cause d’un patch bâclé est le pire qui puisse arriver. Attendez. Les vrais correctifs sont disponibles et seront disponibles dans votre distribution en temps voulu.

Source : “ZDNet.com”

Leave a Reply

Your email address will not be published. Required fields are marked *