Bon, ça marche pas à distance et il faut accès aux droits root. Ça reste, comme indiqué dans l'article, très gênant dans pas mal de situations.
Toutefois, ce passage n'est pas très clair, renseigne sur une possible solution au problème :
«L'attaque BootHole fonctionne même si Secure Boot est activé car, pour certains appareils ou certaines configurations de systèmes d'exploitation, le processus d'amorçage sécurisé ne vérifie pas le fichier grub.cfg de manière cryptographique, ce qui permet aux attaquants d'en altérer le contenu.»
Ça signifie qu'en fait, avec Grub, il est possible de vérifier de manière cryptographique le fichier de config de Grub et alors de se protéger contre cette attaque BootHole ?
Enfin, ce passage me semble être du FUD total (Fear, Uncertainty and Doubt):
«Les systèmes d'exploitation et leurs composants sont truffés de bugs d'élévation de privilèges qui pourraient être exploités dans le cadre d'une chaîne d'attaque BootHole pour permettre aux logiciels malveillants d'obtenir un accès administrateur et de modifier le fichier grub.cfg.»
Est-ce si facile de trouver une faille pour accéder aux droits root en local comme à distance ?
Ça signifie qu'en fait, avec Grub, il est possible de vérifier de manière cryptographique le fichier de config de Grub et alors de se protéger contre cette attaque BootHole ?
Soyons réalistes, oui il y a régulièrement des failles affectant des systèmes Linux standards et permettant d'exécuter du code avec des privilèges suffisant pour exploiter cette vulnérabilité, par exemple une liste de CVE affectant Debian (en effet, les logiciels couverts sont larges du fait de la taille de la distribution Debian, mais un attaquant se fera un plaisir d'utiliser n'importe quel vecteur d'attaque disponible).
Difficile de dire que ça n'est pas si grave. Oui la faille est difficile à exploiter, mais elle rend complètement caduque les protections secure boots pour de nombreux mois, voire années, et ce pour tout le monde.
En effet, les versions signées de Grub qui sont affectées vont devoir être bloquée au niveau d'UEFI, ce qui va nécessiter d'attendre que la majorité des utilisateurs aient mis à jour leur système. Même après ça, ça risque de rendre non bootable un très grand nombre de système (car la version compromise ne sera plus acceptée par l'UEFI).
Ça affecte tous les systèmes, en effet un attaquant peut attaquer un système Windows (ou autre) pour y installer un Grub compromis et signé, qui sera accepté pour l'UEFI.
Donc ça pose un sacré problème de confiance en grub pour être fiable dans le futur.
De plus, après la découverte de la faille, les équipes de securité de Canonical et autres ont passé grub à la moulinette d'analyse statique, et ont trouvé beaucoup d'autres vulnérabilités, pour s'en convaincre la liste se trouve dans l'alerte de sécurité de RedHat.
Si sur un composant aussi critique pour la sécurité que grub on trouve autant de code non sûr, quid des autres composants qui disposent d'encore moins de moyens pour faire ce type d'analyse ?
En effet, les versions signées de Grub qui sont affectées vont devoir être bloquée au niveau d'UEFI,
Il ne me semble pas que les version de Windows impactées par des failles de sécurités soient bloquée par les UEFI.
Si sur un composant aussi critique pour la sécurité que grub on trouve autant de code non sûr, quid des autres composants qui disposent d'encore moins de moyens pour faire ce type d'analyse ?
Je te conseille de ne pas regarder du côté d'openssl (ou gnutls).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Il ne me semble pas que les version de Windows impactées par des failles de sécurités soient bloquée par les UEFI.
C'est un problème différent, tout comme UEFI avec Grub permet de booter des kernels Linux qui ont été impactés par des failles de sécurité.
Le principe de secure boot est de ne pouvoir démarrer qu'un boot loader et noyau signés par un vendeur et donc considérés comme sûr. De fait un attaquant ne peux pas modifier le noyau pour y ajouter un rootkit qui serait actif au prochain redémarrage, le démarrage du noyau compromis échouerait.
Cette faille contourne cette protection, rendant le secure boot à peu près caduc.
Si tu peux booter un noyau avec une faille qui te permet te faire ce que tu veux, je ne vois pas ce que ça change.
e fait un attaquant ne peux pas modifier le noyau pour y ajouter un rootkit qui serait actif au prochain redémarrage, le démarrage du noyau compromis échouerait.
Non, mais il peut mettre un kernel troué qui va charger un rootkit, ça ne change pas grand chose.
Je ne dis pas que secure boot ne sert à rien. Mais que Grub troué, c'est juste un des composants signé comme un autre (uefi, bootload, kernel) et je ne vois pas pourquoi lui devrait être bloqué plutôt qu'un autre.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Bon. Grub2 à une faille, c'est chiant, faut update, ok (vais passer un coup d'analyse sur mon syslinux cet aprem, moi, tiens).
Maintenant, avec l'uefi, les firmwares embarquent un langage de script, il me semble, ainsi que des fonctionnalités réseau.
J'aimerai bien qu'on passe un peu ces usines à gaz à l'analyse statique, moi aussi, parce qu'il me semble que la surface d'attaque est un «chouïa» plus grande.
BootHole should now be addressed with Debian 10.5 as well as not having the boot issues that then plagued some RHEL/CentOS users following mitigations.
# Bon, ce n'est pas si grave.
Posté par lejocelyn (site web personnel) . Évalué à 5.
Bon, ça marche pas à distance et il faut accès aux droits root. Ça reste, comme indiqué dans l'article, très gênant dans pas mal de situations.
Toutefois, ce passage n'est pas très clair, renseigne sur une possible solution au problème :
«L'attaque BootHole fonctionne même si Secure Boot est activé car, pour certains appareils ou certaines configurations de systèmes d'exploitation, le processus d'amorçage sécurisé ne vérifie pas le fichier grub.cfg de manière cryptographique, ce qui permet aux attaquants d'en altérer le contenu.»
Ça signifie qu'en fait, avec Grub, il est possible de vérifier de manière cryptographique le fichier de config de Grub et alors de se protéger contre cette attaque BootHole ?
Enfin, ce passage me semble être du FUD total (Fear, Uncertainty and Doubt):
«Les systèmes d'exploitation et leurs composants sont truffés de bugs d'élévation de privilèges qui pourraient être exploités dans le cadre d'une chaîne d'attaque BootHole pour permettre aux logiciels malveillants d'obtenir un accès administrateur et de modifier le fichier grub.cfg.»
Est-ce si facile de trouver une faille pour accéder aux droits root en local comme à distance ?
[^] # Re: Bon, ce n'est pas si grave.
Posté par claudex . Évalué à 8.
Il me semble, grub.cfg est signé dans cet article https://ruderich.org/simon/notes/secure-boot-with-grub-and-signed-linux-and-initrd
En général il suffit de demande à l'utilisateur.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Bon, ce n'est pas si grave.
Posté par paulez (site web personnel) . Évalué à 4.
Soyons réalistes, oui il y a régulièrement des failles affectant des systèmes Linux standards et permettant d'exécuter du code avec des privilèges suffisant pour exploiter cette vulnérabilité, par exemple une liste de CVE affectant Debian (en effet, les logiciels couverts sont larges du fait de la taille de la distribution Debian, mais un attaquant se fera un plaisir d'utiliser n'importe quel vecteur d'attaque disponible).
Difficile de dire que ça n'est pas si grave. Oui la faille est difficile à exploiter, mais elle rend complètement caduque les protections secure boots pour de nombreux mois, voire années, et ce pour tout le monde.
En effet, les versions signées de Grub qui sont affectées vont devoir être bloquée au niveau d'UEFI, ce qui va nécessiter d'attendre que la majorité des utilisateurs aient mis à jour leur système. Même après ça, ça risque de rendre non bootable un très grand nombre de système (car la version compromise ne sera plus acceptée par l'UEFI).
Ça affecte tous les systèmes, en effet un attaquant peut attaquer un système Windows (ou autre) pour y installer un Grub compromis et signé, qui sera accepté pour l'UEFI.
Donc ça pose un sacré problème de confiance en grub pour être fiable dans le futur.
De plus, après la découverte de la faille, les équipes de securité de Canonical et autres ont passé grub à la moulinette d'analyse statique, et ont trouvé beaucoup d'autres vulnérabilités, pour s'en convaincre la liste se trouve dans l'alerte de sécurité de RedHat.
Si sur un composant aussi critique pour la sécurité que grub on trouve autant de code non sûr, quid des autres composants qui disposent d'encore moins de moyens pour faire ce type d'analyse ?
[^] # Re: Bon, ce n'est pas si grave.
Posté par claudex . Évalué à 5.
Il ne me semble pas que les version de Windows impactées par des failles de sécurités soient bloquée par les UEFI.
Je te conseille de ne pas regarder du côté d'openssl (ou gnutls).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Bon, ce n'est pas si grave.
Posté par paulez (site web personnel) . Évalué à 1.
C'est un problème différent, tout comme UEFI avec Grub permet de booter des kernels Linux qui ont été impactés par des failles de sécurité.
Le principe de secure boot est de ne pouvoir démarrer qu'un boot loader et noyau signés par un vendeur et donc considérés comme sûr. De fait un attaquant ne peux pas modifier le noyau pour y ajouter un rootkit qui serait actif au prochain redémarrage, le démarrage du noyau compromis échouerait.
Cette faille contourne cette protection, rendant le secure boot à peu près caduc.
[^] # Re: Bon, ce n'est pas si grave.
Posté par claudex . Évalué à 5.
Si tu peux booter un noyau avec une faille qui te permet te faire ce que tu veux, je ne vois pas ce que ça change.
Non, mais il peut mettre un kernel troué qui va charger un rootkit, ça ne change pas grand chose.
Je ne dis pas que secure boot ne sert à rien. Mais que Grub troué, c'est juste un des composants signé comme un autre (uefi, bootload, kernel) et je ne vois pas pourquoi lui devrait être bloqué plutôt qu'un autre.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Et les firmwares?
Posté par freem . Évalué à 8.
Bon. Grub2 à une faille, c'est chiant, faut update, ok (vais passer un coup d'analyse sur mon syslinux cet aprem, moi, tiens).
Maintenant, avec l'uefi, les firmwares embarquent un langage de script, il me semble, ainsi que des fonctionnalités réseau.
J'aimerai bien qu'on passe un peu ces usines à gaz à l'analyse statique, moi aussi, parce qu'il me semble que la surface d'attaque est un «chouïa» plus grande.
# Correction pas évidente
Posté par NicolasP . Évalué à 2. Dernière modification le 31 juillet 2020 à 20:37.
La correction ne semble pas évidente avec comme effet de bord d'empêcher des systèmes de booter, au moins chez Red Hat.
[^] # Re: Correction pas évidente
Posté par antistress (site web personnel) . Évalué à 5. Dernière modification le 01 août 2020 à 17:02.
Debian 10.5 Released To Address The GRUB2 BootHole Vulnerability, Other Security Fixes
https://www.phoronix.com/scan.php?page=news_item&px=Debian-10.5-Released
[^] # Re: Correction pas évidente
Posté par Anonyme . Évalué à 4.
Et aussi : [DSA 4735-2] grub2 regression update.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.