Secure Boot : Microsoft a-t-il ouvert trop grand la porte ?

En voulant rendre le Secure Boot plus flexible, Microsoft l’a-t-il affaibli au point d’ouvrir la porte à l’exécution, sur toutes les machines livrées avec Windows, de code malveillant de type rootkit et bootkit ?

C’est, en substance, ce que prétendent deux chercheurs en sécurité qui se présentent sous les pseudos « my123 » et « slipstream ».

La faille qu’ils pointent du doigt est apparue pendant le développement de Windows 10 « Redstone », finalement baptisé « Anniversary Update ». Elle est liée à l’introduction d’un nouveau type de politique applicable au Secure Boot, du nom de cette composante de l’UEFI (Universal Extensible Firmware Interface ; successeur du BIOS) qui empêche l’exécution de code non signé et/ou révoqué.

Sur les appareils équipés de certaines versions de Windows (Windows RT, Windows Phone, Windows 10 pour Hololens), le Secure Boot ne peut être désactivé.

À des fins telles que le développement ou le reconditionnement de machines, il peut être modifié, via des fichiers binaires qui doivent eux aussi être signés et auxquels le chargeur d’amorçage (bootmgr) fait appel très en amont dans la séquence de boot.

Ce fichier, chargé à partir d’une variable dans l’UEFI, peut définir soit des informations de démarrage (BCD, pour « Boot configuration data », équivalent du boot.ini utilisé jusqu’à Windows XP), soit des règles de registre.

Pendant la phase bêta de Windows 10 « Redstone », Microsoft a ajouté un nouveau type de fichier binaire capable d’intégrer d’enrichir les politiques existantes sans les remplacer, à partir non pas d’une variable UEFI, mais de la partition système EFI.

Qui a signé ?

Le bootmgr de Redstone charge d’abord la politique par défaut. Il intègre ensuite les politiques supplémentaires.

À une période du développement de l’OS, plus aucune vérification n’était faite à part la signature de la politique par défaut et du DeviceID, identifiant unique inséré dans un hash SHA-256 et qui doit absolument correspondre à celui de l’appareil.

Plus inquiétant : les anciennes versions de bootmgr n’étant pas capable de détecter les « politiques supplémentaires » comme telles, elles les considèrent comme parfaitement valides, aussi longtemps qu’elles sont signées… par quiconque se présente comme une autorité certifiante.

Ces politiques supplémentaires ne contenant ni DeviceID, ni de BCD, elles peuvent être utilisées pour activer le mode testsigning (test de code non signé), y compris sur bootmgr : assez pour installer un bootkit qui s’injectera, au démarrage, dans le noyau de Windows.

La découverte de « my123 » et « slipstream » remonte au mois de mars. Au début, Microsoft avait semblé écarter le problème, considérant que ce n’en était pas un. L’éditeur a finalement retourné sa veste et diffusé, dans le Patch Tuesday de juillet, des correctifs (MS16-094 et MS16-100)*.

D’après les chercheurs, aucun de ces correctifs ne colmate directement la faille : d’un côté, Microsoft ne peut pas révoquer les versions trop anciennes de bootmgr, sous peine de bloquer des machines ; de l’autre, des pirates peuvent remplacer les bootmgr les plus récents par des moutures antérieures.

* Microsoft propose une méthode de contournement : configurer BitLocker pour utiliser, sur les machines compatibles, le module TPM et la protection par code PIN.