Dans l'UEFI, qui remplace les anciens BIOS, vient une fonctionnalité qui a fait couler beaucoup d'encre lorsqu'elle est apparue : le Secure Boot.

La motivation officielle de celui-ci est d'apporter de la sécurité en empêchant l'exécution de code non signé au boot, le chargeur de démarrage étant signé avec une clé chiffrée autorisée par une base de donnée contenue dans le micrologiciel. Plus officieusement, à cette époque où Microsoft n'appréciait pas particulièrement Linux, le Secure Boot empêchait d'installer d'autres systèmes sur l'ordinateur, à moins que l'UEFI permette de le désactiver. Un vrai problème pour les amateurs de Linux notamment, d'où les critiques. Depuis, des distributions Linux compatibles Secure Boot ont été publiées, fort heureusement, et désormais Microsoft aime Linux nous dit l'entreprise.

Tout va donc pour le mieux ? Non pas du tout. Microsoft a égaré des clés de chiffrement de son Secure Boot. Des clés spéciales, dites 'Golden Keys', normalement fournies aux OEM pour que ceux-ci puissent tester le Secure Boot sur leurs machines. Le tester et le bypasser également. D'une certaine façon, ces Golden Keys fournissent donc une backdoor. Ces clés étant dans la nature, il est à priori possible à qui en possède les compétences d'installer des bookits ou rookits sur les machines. Des malwares qui seront approuvés par le système, même si vous, vous ne pouvez toujours pas installer sur votre machine un OS alternatif propre sur lui....

Comment Microsoft a-t-il égaré ces clefs ? Rien de sûr à ce niveau. Mais The Register pense que l'éditeur a vendu des appareils avec ce mode 'debug', certes désactivé, mais présent, ce qui aurait permis à deux hackers d'étudier la question.

Ces deux hackers ont créé pour l'occasion un site qui explique (si vous avez la patience d'écouter sa musique tapageuse suffisamment longtemps :-) comment leurrer le Secure Boot. Les clés égarées ont par ailleurs été publiées sur le net. Les deux hackers précisent également que Microsoft a tenté de remédier au problème. Notamment Redmond a publié en juillet le correctif MS16-094, puis en août le correctif MS16-100, les deux correctifs définissant un nouveau bootmgr et une liste de policies blacklistées

Malheureusement, selon nos deux hackers, cela ne fonctionne que partiellement, car le bootmgr de Windows ne vérifie cette liste qu'après le chargement des policies. Dans ces conditions, un attaquant expérimenté a toujours la possibilité de réinstaller un bootmgr antérieur à ces correctifs.

Selon The Register, Microsoft devrait publier un troisième correctif en septembre. En attendant, tous les PC 'Secure Boot' offrent potentiellement une backdoor pas du tout secure...