Matthew Garrett, un d\u00e9veloppeur du noyau Linux reconnu qui a re\u00e7u autrefois un prix du fonds de logiciels libres pour sa contribution au d\u00e9veloppement de logiciels libres, a expliqu\u00e9 la nature du m\u00e9canisme SBAT (Secure Boot Advanced Targeting), con\u00e7u pour bloquer les vuln\u00e9rabilit\u00e9s dans le chargeur de d\u00e9marrage sans r\u00e9voquer de signatures num\u00e9riques, ainsi que son r\u00f4le dans l'incident r\u00e9cent li\u00e9 \u00e0 une mise \u00e0 jour de Windows qui a conduit \u00e0 l'arr\u00eat du d\u00e9marrage de certaines distributions Linux install\u00e9es parall\u00e8lement \u00e0 Windows sur des syst\u00e8mes avec UEFI Secure Boot activ\u00e9. En r\u00e9sum\u00e9, la responsabilit\u00e9 incombe tant \u00e0 Microsoft, qui n'a pas test\u00e9 l'ensemble de la mise \u00e0 jour ni appliqu\u00e9 celle-ci aux syst\u00e8mes auxquels elle ne devait pas \u00eatre appliqu\u00e9e, qu'aux d\u00e9veloppeurs de certaines distributions Linux, qui n'ont pas mis \u00e0 jour le chargeur GRUB et la version de SBAT lorsque des vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans GRUB. <\/p>\n
Voici la traduction de l'article de Garrett : <\/p>\n
\nLors du d\u00e9veloppement de la sp\u00e9cification UEFI Secure Boot, tous les participants \u00e9taient, disons, un peu na\u00effs. Le mod\u00e8le de s\u00e9curit\u00e9 principal de Secure Boot repose sur le fait que tout code ex\u00e9cut\u00e9 dans un environnement privil\u00e9gi\u00e9 au niveau du noyau doit \u00eatre v\u00e9rifi\u00e9 avant son ex\u00e9cution \u2014 le firmware v\u00e9rifie le chargeur, le chargeur v\u00e9rifie le noyau, le noyau v\u00e9rifie tout code additionnel charg\u00e9 \u00e0 l'ex\u00e9cution, et maintenant nous avons un environnement de confiance pour imposer toute autre politique de s\u00e9curit\u00e9 que nous souhaitons. Il est \u00e9vident que des erreurs peuvent se produire, mais la sp\u00e9cification pr\u00e9voyait un moyen de r\u00e9voquer des composants sign\u00e9s qui se sont r\u00e9v\u00e9l\u00e9s non fiables : il suffit d'ajouter le hachage du code douteux \u00e0 une variable, puis de refuser de charger quoi que ce soit avec ce hachage, m\u00eame s'il est sign\u00e9 par une cl\u00e9 de confiance. <\/p>\n
Malheureusement, il s'av\u00e8re que le probl\u00e8me est \u00e0 l'\u00e9chelle. Chaque distribution Linux fonctionnant dans l'\u00e9cosyst\u00e8me Secure Boot g\u00e9n\u00e8re ses propres fichiers binaires de chargeur, et chacun d'eux a son propre hachage. Si une vuln\u00e9rabilit\u00e9 est trouv\u00e9e dans le code source d'un tel chargeur, il est n\u00e9cessaire de r\u00e9voquer un grand nombre de fichiers binaires diff\u00e9rents. Et l'espace m\u00e9moire pour stocker la variable contenant tous ces hachages est limit\u00e9. Il n'y a tout simplement pas assez de place pour ajouter un nouvel ensemble de hachages chaque fois qu'il s'av\u00e8re que GRUB (le chargeur, \u00e0 l'origine \u00e9crit \u00e0 une \u00e9poque o\u00f9 la protection du d\u00e9marrage n'\u00e9tait pas pratiqu\u00e9e, et ayant plusieurs analyseurs d'images img, ainsi qu'un analyseur de polices) a encore un autre m\u00e9canisme pour un attaquant pour le forcer \u00e0 ex\u00e9cuter du code arbitraire, donc une autre solution \u00e9tait n\u00e9cessaire. <\/p>\n
La solution a \u00e9t\u00e9 SBAT. La conception g\u00e9n\u00e9rale de SBAT est assez simple. Chaque composant important dans la cha\u00eene de d\u00e9marrage d\u00e9clare une g\u00e9n\u00e9ration de s\u00e9curit\u00e9, qui est int\u00e9gr\u00e9e dans le binaire sign\u00e9. Lorsqu'une vuln\u00e9rabilit\u00e9 est d\u00e9couverte et corrig\u00e9e, cette g\u00e9n\u00e9ration est augment\u00e9e. Il est ensuite possible de publier une mise \u00e0 jour qui d\u00e9finit la g\u00e9n\u00e9ration minimale \u2014 les composants de d\u00e9marrage examineront l'\u00e9l\u00e9ment suivant dans la cha\u00eene, compareront son nom et son num\u00e9ro de g\u00e9n\u00e9ration avec ceux stock\u00e9s dans la variable du firmware, et d\u00e9cideront de l'ex\u00e9cuter ou non en cons\u00e9quence. Au lieu de r\u00e9voquer un grand nombre de hachages individuels, il est possible de publier une seule mise \u00e0 jour qui dit simplement : \u00ab Toute version de GRUB avec une g\u00e9n\u00e9ration de s\u00e9curit\u00e9 inf\u00e9rieure \u00e0 ce num\u00e9ro est consid\u00e9r\u00e9e comme non fiable \u00bb. <\/p>\n
Pourquoi cela est-il devenu soudainement pertinent ? SBAT a \u00e9t\u00e9 d\u00e9velopp\u00e9 conjointement par la communaut\u00e9 Linux et Microsoft, et Microsoft a d\u00e9cid\u00e9 de publier une mise \u00e0 jour pour Windows qui a dit aux syst\u00e8mes de ne pas faire confiance aux versions de GRUB avec une g\u00e9n\u00e9ration de s\u00e9curit\u00e9 inf\u00e9rieure \u00e0 un certain niveau. Cela a \u00e9t\u00e9 fait car ces versions de GRUB avaient de r\u00e9elles vuln\u00e9rabilit\u00e9s de s\u00e9curit\u00e9 qui permettaient aux attaquants de compromettre la cha\u00eene de d\u00e9marrage s\u00e9curis\u00e9e de Windows, et nous avons vu des exemples r\u00e9els de logiciels malveillants cherchant \u00e0 le faire (Black Lotus a utilis\u00e9 une vuln\u00e9rabilit\u00e9 dans le chargeur Windows, mais la vuln\u00e9rabilit\u00e9 de GRUB \u00e9tait tout aussi efficace). Vu sous l'angle de la s\u00e9curit\u00e9, c'est un d\u00e9sir tout \u00e0 fait l\u00e9gitime. <\/p>\n
Quant au message \u00ab Quelque chose a mal tourn\u00e9 \u00bb et \u00e0 l'impossibilit\u00e9 de d\u00e9marrer \u00e0 cause de cette mise \u00e0 jour, il est g\u00e9n\u00e9r\u00e9 par shim, et non par un code de Microsoft. Shim prend en compte les mises \u00e0 jour SBAT, et, afin de ne pas compromettre les principes de s\u00e9curit\u00e9 adopt\u00e9s par d'autres chargeurs dans le syst\u00e8me, bien que Microsoft ait publi\u00e9 une mise \u00e0 jour SBAT, c'est le chargeur Linux qui refuse finalement de d\u00e9marrer les anciennes versions de GRUB. Tout fonctionne comme cela devrait. <\/p>\n
Le probl\u00e8me auquel les gens sont confront\u00e9s est que plusieurs distributions Linux n'ont pas publi\u00e9 de versions de GRUB avec une g\u00e9n\u00e9ration de s\u00e9curit\u00e9 plus r\u00e9cente, et donc ces versions de GRUB sont consid\u00e9r\u00e9es comme non s\u00e9curis\u00e9es (il convient de noter que GRUB est sign\u00e9 par les distributions elles-m\u00eames, et non par Microsoft, il n'y a donc pas de retard introduit de l'ext\u00e9rieur). Selon Microsoft, la mise \u00e0 jour Windows Update devait appliquer la mise \u00e0 jour SBAT uniquement aux syst\u00e8mes fonctionnant exclusivement avec Windows, tandis que toute installation en double d\u00e9marrage resterait vuln\u00e9rable aux attaques tant que la distribution install\u00e9e ne mettrait pas \u00e0 jour GRUB et ne mettrait pas \u00e0 jour la g\u00e9n\u00e9ration SBAT. Malheureusement, comme il est d\u00e9sormais \u00e9vident, cela n'a pas fonctionn\u00e9 comme pr\u00e9vu, et certaines syst\u00e8mes en double d\u00e9marrage ont appliqu\u00e9 la mise \u00e0 jour, alors que Shim de cette distribution a refus\u00e9 de charger GRUB de cette distribution. <\/p>\n
Quel est le r\u00e9sultat ? Microsoft (pour des raisons \u00e9videntes) ne souhaitait pas que Windows puisse \u00eatre attaqu\u00e9 \u00e0 l'aide d'une version vuln\u00e9rable de GRUB, qui pourrait \u00eatre tromp\u00e9e en ex\u00e9cutant du code arbitraire, puis en injectant un bootkit dans le noyau de Windows lors du d\u00e9marrage. Microsoft a r\u00e9alis\u00e9 cela en publiant une mise \u00e0 jour de Windows, qui a mis \u00e0 jour la variable SBAT, indiquant que les versions vuln\u00e9rables de GRUB ne devaient pas \u00eatre charg\u00e9es sur ces syst\u00e8mes. Le chargeur de premi\u00e8re \u00e9tape fourni par le distributeur lisait cette variable, v\u00e9rifiait la section SBAT de la version install\u00e9e de GRUB, comprenait qu'il y avait un conflit et refusait de charger grub avec le message \u00ab Quelque chose s'est mal pass\u00e9 \u00bb. Cette mise \u00e0 jour ne devait pas \u00eatre appliqu\u00e9e aux syst\u00e8mes \u00e0 double amor\u00e7age, mais elle a quand m\u00eame \u00e9t\u00e9 appliqu\u00e9e. <\/p>\n
En r\u00e9sum\u00e9 : <\/p>\n
1) Microsoft a appliqu\u00e9 la mise \u00e0 jour \u00e0 des syst\u00e8mes \u00e0 laquelle elle ne devait pas s'appliquer <\/p>\n
2) Certaines distributions Linux n'ont pas mis \u00e0 jour le chargeur GRUB et la g\u00e9n\u00e9ration de s\u00e9curit\u00e9 SBAT lorsque des vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans GRUB. <\/p>\n
En cons\u00e9quence, certaines personnes ne peuvent pas d\u00e9marrer leurs syst\u00e8mes. Je pense qu'il y a beaucoup de responsables ici. Microsoft aurait d\u00fb effectuer plus de tests pour s'assurer que les installations en double d\u00e9marrage peuvent \u00eatre d\u00e9tect\u00e9es avec pr\u00e9cision. Mais les distributions fournissant des chargeurs sign\u00e9s doivent \u00e9galement s'assurer qu'elles les mettent \u00e0 jour et actualisent les versions de s\u00e9curit\u00e9 pour s'y conformer, sinon elles fournissent un vecteur d'attaque pouvant \u00eatre utilis\u00e9 pour compromettre d'autres syst\u00e8mes d'exploitation, et c'est en quelque sorte une violation du contrat social qui entoure tout cela. <\/p>\n
Malheureusement, les victimes ici sont principalement les utilisateurs finaux, confront\u00e9s \u00e0 une situation o\u00f9 le syst\u00e8me refuse soudainement de d\u00e9marrer l'OS qu'ils souhaitent lancer. Cela ne devrait jamais se produire. Je ne pense pas qu'un sondage aupr\u00e8s des utilisateurs finaux sur leur d\u00e9sir d'avoir des mises \u00e0 jour du syst\u00e8me de d\u00e9marrage s\u00e9curis\u00e9 aura un bon r\u00e9sultat, et bien que je penche en quelque sorte vers le fait que le d\u00e9marrage s\u00e9curis\u00e9 UEFI n'apporte pas d'avantages \u00e0 la plupart des utilisateurs finaux, c'est aussi une chose que vous ne voulez pas d\u00e9couvrir apr\u00e8s de tels incidents. C'est pourquoi je sympathise avec le fait qu'il soit activ\u00e9 par d\u00e9faut, donc je soutiens son activation par d\u00e9faut, partageant le choix de Microsoft, \u00e0 l'exception de la tentative infructueuse d'\u00e9viter les mises \u00e0 jour sur les syst\u00e8mes en double d\u00e9marrage. <\/p>\n
Quoi qu'il en soit, j'ai \u00e9t\u00e9 fortement impliqu\u00e9 dans la mise en \u0153uvre de ce m\u00e9canisme pour Linux en 2012 et j'ai \u00e9crit le premier prototype de Shim (qui est maintenant un chargeur beaucoup mieux soutenu par un plus large \u00e9ventail de personnes, et auquel je n'ai pas touch\u00e9 depuis plusieurs ann\u00e9es). Donc, si vous voulez accuser quelqu'un, n'h\u00e9sitez pas \u00e0 m'accuser. C'est quelque chose qui ne devrait pas arriver, et si vous n'\u00eates pas Microsoft ou une distribution Linux, ce n'est pas de votre faute. Je m'excuse. <\/p><\/blockquote>\n