Mauvaise semaine pour Microsoft, qui fait face à un sérieux problème : la fuite de clés permettant d’ouvrir Secure Boot sur n’importe quelle machine. Bien que la méthode ne puisse pas être exploitée pour infiltrer un malware, le cas – d’école – rappelle à quel point les portes dérobées sont une mauvaise idée.
Secure Boot est un mécanisme prévu essentiellement pour bloquer toute tentative d’insertion d’un élément nocif dans la chaine du démarrage. Il s’agit d’une fonctionnalité de la norme UEFI, impliquant des éléments signés. L’une des conséquences est qu’une machine l’exploitant complètement ne peut démarrer qu’un système signé avec une clé validée par Microsoft. En clair, outre Windows, il est complexe d’installer autre chose, même s'il peut être mal implémenté, au risque donc d'être inutile.
Secure Boot fonctionne avec des clés ainsi qu’un lot de règles. Ces dernières définissent la manière dont les mécanismes se déroulent, les éléments à ajouter, ceux à ne pas prendre en compte et ainsi de suite. Or, pour que les OEM notamment puissent tester Secure Boot sur leur machine, Microsoft a mis en place des « golden keys », en fait une règle bien spécifique qui bloque le contrôle des signatures par le gestionnaire de démarrage de Windows.
Oups
Normalement, cette règle ne devrait être fournie qu’à ceux qui en ont besoin, après avoir dument montré patte blanche. Mais Microsoft a fait pour ainsi dire une petite boulette : cette règle « mode debug » est présente dans toutes les machines. Elle ne devrait évidemment pas, mais la conséquence est bien là.
En théorie, n’importe qui peut donc activer cette règle, et les scripts ont déjà fleuri en plusieurs endroits. La découverte a été faite par deux chercheurs, utilisant les pseudos MY123 and Slipstream, qui relatent l’intégralité de leurs trouvailles sur un site spécialement créé pour l’occasion (il faut attendre un peu devant l’animation avant que le texte n’apparaisse).
Il ne semble pas possible pour l’instant d’insérer le moindre malware dans la chaine du démarrage sans que l’utilisateur ne s’en aperçoive. Par contre, la désactivation du contrôle de boot permet à un appareil de démarrer sur n’importe quel système d’exploitation. Il peut s’agir de PC, de tablettes ou de smartphones, les architectures x86 et ARM étant supportées. Certains voient déjà de quoi redonner une nouvelle jeunesse à des Surface RT laissées à l’abandon. Ou pourquoi pas installer Android sur des Lumia.
Un problème qui ne pourra peut-être pas être complètement résolu
Pour Microsoft, c’est par contre un sérieux problème, une faute d’inattention si grave qu’on se demande comment elle a pu passer au travers des mailles du filet. Les chercheurs ont averti l’éditeur de la situation en mars dernier. Dans un premier temps, Microsoft n’a pas considéré sérieusement la faille. Mais en avril, changement de ton, les chercheurs récupérant même au passage une prime dans le cadre du programme maison de chasse aux bugs.
Un premier correctif a été diffusé en juillet. Estampillé MS16-094, il met en place une liste de révocation vérifiée par le gestionnaire de démarrage de Windows. Mais cette solution comporte là aussi une faille « bête » : la liste est consultée après le chargement des règles. Si la règle incriminée a déjà été activée, le correctif n’y changera rien. Dans le cas contraire, il est effectif, d’autant que l’outil d’activation des règles a lui aussi été mis à jour.
Les chercheurs ont indiqué que de nouveaux scripts seraient proposés pour contourner le patch MS16-094. Microsoft prévoit de toute façon déjà un troisième correctif le mois prochain, alors qu’un deuxième a été distribué mardi soir pour le Patch Tuesday. MY123 and Slipstream estiment cependant qu’il ne sera pas possible de refermer complètement la brèche. L’entreprise vient d’apporter, malgré elle, un argument de poids dans le débat très vif au sujet de la sécurité et des portes dérobées.
Les portes dérobées sécurisées n'existent pas
Difficile en effet de ne pas penser aux questions posées par le chiffrement, et plus particulièrement son expansion à travers un nombre croissant de services. Un phénomène dû en partie aux révélations de Snowden, qui ont montré l’étendue des services de renseignements, particulièrement aux États-Unis. Or, devant cette croissance, les forces de l’ordre, le FBI et autres émanations gouvernementales (quand ce ne sont pas les gouvernements eux-mêmes) cherchent des solutions, dont la plus souvent entendue est la mise en place de portées dérobées sécurisées.
Comme indiqué à de nombreuses reprises, il n’existe rien de tel. Une porte ne peut être à la fois dérobée et sécurisée, car il existera toujours le risque que la clé échappe aux propriétaires ou qu’elle soit trouvée d’une autre manière. L’erreur de Microsoft prouve – s’il y en avait encore besoin – que le danger est réel. Car si l’erreur est surtout ennuyeuse ici pour l’entreprise, elle pourrait tout aussi bien avoir lieu avec un algorithme de chiffrement conçu de cette manière. Il n’est pas exclu d’ailleurs que le FBI et d’autres agences profitent de cette erreur.
