Vous souvenez-vous des occasions où nous avons parlé de Secure Boot ? Eh bien, d'une certaine manière, Redmond a laissé s'échapper certaines « clés dorées », qui symbolisent en réalité une politique spéciale équivalant à un « mode de développement », et qui désactive à son tour plusieurs fonctions principales de Secure Boot. Le meilleur dans tout ça ? Microsoft a pensé au départ que ce n'était pas un problème mais a publié deux correctifs en moins d'un mois. Le génie est-il sorti de la lampe ?
Vie privée, sécurité, code propriétaire, open source, jailbreaking, rooting… des termes qui vont, viennent, se heurtent, partagent un chemin similaire ou se déchirent mutuellement. L'utilisateur moyen se retrouve pris dans une tempête sans savoir ce qui est le plus approprié, et les arguments de toutes les parties concernées se transforment en bruit blanc. La dernière nouveauté qui vient de s'élever au-dessus de ce bruit concerne Secure Boot, vieille connaissance ici chez NeoTeo, protecteur théorique de l'intégrité de l'ordinateur et de son système d'exploitation (dans ce cas précis, plusieurs versions de Windows), et ennemi mortel de nombreux cavaliers de Linux qui ont voulu faire un « dual-boot » sur leurs nouveaux appareils et n'y sont pas parvenus. Microsoft a indiqué (à plus d'une reprise) que les systèmes certifiés basés sur x86 doivent permettre à Secure Boot d'entrer dans un « mode personnalisé » ou offrir la possibilité de le désactiver complètement, bien que cela ne s'étende pas aux appareils ARM, l'une des raisons pour lesquelles toutes ces tablettes sous Windows RT ne sont aujourd'hui guère plus que des briques. Cependant, l'état général de Secure Boot pourrait complètement changer d'ici quelques mois.
Que s'est-il passé exactement ?
Deux experts en sécurité identifiés sous les pseudonymes MY123 et Slipstream ont découvert quelque chose qu'ils ont baptisé « clés dorées », qui ne sont pas des clés numériques au sens traditionnel, mais une politique spéciale de Secure Boot qui modifie les tâches exécutées par l'UEFI au démarrage… parmi lesquelles se trouve la vérification des signatures. Apparemment, cette politique existe comme un « mode de développement » ou « mode debug » si vous préférez, qui permet aux programmeurs d'évaluer de nouvelles builds, de détecter des bugs et d'appliquer les corrections nécessaires sans avoir à tout signer. Comment est-elle arrivée entre les mains de MY123 et Slipstream ? En gros, ils l'ont trouvée à la fin mars « endormie » dans des appareils que Microsoft vend. Ils ont contacté l'entreprise en avril, et à l'époque Microsoft a estimé que ce n'était pas un risque de sécurité (cela nécessite un accès physique « ou » des privilèges d'administrateur), mais entre juin et juillet, ils ont décidé de payer une récompense et de publier deux correctifs, MS16-094 et MS16-100, qui, bien qu'ils parviennent à atténuer la situation, n'offrent pas de solution définitive.
Et ensuite ?
En quoi cela va-t-il se transformer ? La réponse est « cela dépend ». La politique pourrait permettre l'installation de systèmes d'exploitation alternatifs sur des appareils sous Windows RT (sans les correctifs susmentionnés) ou Windows Phone. Personnellement, j'aimerais voir ce que la communauté peut faire (ce ne sera pas simple, même s'il y a des génies là-bas qui vivent pour chercher ce genre de défis), mais la médaille a deux faces. Il n'est pas logique de créer une liste noire avec chaque « bootmgr » affecté car cela briserait la compatibilité dans plus d'un cas (disques d'installation d'origine, partitions de secours, sauvegardes, etc.), et si quelqu'un profite de cette brèche pour installer un « paquet » malveillant, eh bien...
(Note de la rédaction : Oui, la page officielle ressemble à un cracktro des années 90)
