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.
Commentaires (108)
#1
Enorme
" />
" />
mais en pratique c’est jamais actif à 100% non ? toujours pu installer un autre OS non Microsoft sans problème (autre que faire gaffe à ses partitions et secteur de démarrage)
#2
En fait c’est surtout sur les Surface RT et autres appareils du genre que le Secure Boot est activé, et empêche l’installation de tout autre OS.
#3
Le truc que je désactive à chaque coup..
#4
Je ne comprends pas trop la corrélation entre le boot sur un OS et une porte dérobée ?
Ça veut dire qu’un boot Windows implique des échanges ?
#5
J’ai vu plusieurs petits PC (hybrides ou PC de taille similaire) sur lesquels ça empêchait d’installer Ubuntu. Et l’article parle aussi des smartphones Lumia pour lesquels il y a de grandes chances que ce soit actif à 100%.
#6
L’appareil accepte de booter sur l’OS proposé seulement si il a une clé windows. La porte dérober permet de faire booter l’appareil sur n’importe quel OS :-)
#7
Si ça peut effectivement me refaire sortir ma Surface RT, ça serait très intéressant.
#8
Comment ? Qu’est-ce que j’apprends ? Les backdoors sont des failles de sécurité ?
" />
Je tombe des nues…
#9
#10
#11
#12
99.99% des malwares et des adwares s’installent sur le compte de l’utilisateur courant limité et le vivent très bien. Microsoft a toujours assuré la rétro-compatibilité avec leurs conneries 😃
" />
Pourquoi chercher plus compliqué ?
#13
j’ai lu un commentaire ici, il n’y a pas si longtemps, sur quelqu’un qui avait plus confiance en Microsoft que Google et Apple pour la sécurité.
" />
#14
Ben Google et Apple aussi ont des failles dans leurs systèmes.
Si tu abandonnes un éditeur à la première bourde de sécurité, t’as pas fini de changer d’OS.
#15
#16
Je comprends pas comment la signature a pu être réservée au seul Microsoft (et on voit où ça nous a mené).
Tous les systèmes vendus en Europe devraient intégrer un certificat qui permettrait de signer les bootloaders après audit.
#17
Il faut en effet bien pouvoir tester: Mon petit doigt me dit que ces bypass aux modes de boot sécurisés doivent exister a peu près partout, plus ou moins bien planqué!
C’est un concept qui ne sert qu’a priver l’utilisateur du droit de faire ce qu’il veut de ce qu’il achète, pas à sécuriser sa machine. Surtout sur un élément pas vraiment facile à exploiter de manière fiable.
#18
#19
Si ça ne permet pas d’infiltrer un malware mais permet de booter sur l’OS que l’on veut c’est plutôt une bonne chose non ? Sauf peut-être pour MS mais qu’est ce qu’on s’en fout ?
#20
#21
Genre hier ?
" />
#22
#23
Dans l’article original, les auteurs interpellent directement le FBI sur son idée d’intégrer des portes dérobées. Dommage que NXInpact n’est pas souligné ce point!
#24
C’est plus une faille pour l’exclusivité de Microsoft sur une machine donnée que pour un utilisateur final. Pour l’exploiter il faut être en possession de la machine, cas pour lequel un chiffrage des données fera sans doute mieux qu’une impossibilité d’installer un jailbreak.
En plus, le terme porte dérobée laisse à penser que c’est un outil d’espionnage, ce qui n’est pas le cas (ou alors c’est ma définition qui en est trop réduite).
Après, oui, il y a une bourde technique sévère du point de vue respect du cahier des charges, mais l’utilisateur final n’a pas trop à s’en inquiéter, je pense.
#25
Android sur un Lumia? Pas besoin de racheter un tel, qui fonctionne, pour jouer à Pokemon go? Cool!
#26
#27
Super nouvelle, maintenant que (in)Secure Boot équipe la quasi-totalité des PC vendus…
" />
Pourquoi est-ce qu’une telle nouvelle ne m’étonne pas ?
Il n’est pas exclu d’ailleurs que le FBI et d’autres agences profitent de cette erreur.
Dites que je suis parano, mais pour moi, il n’est pas impossible non plus que cette « erreur » ait été intentionnellement conçue par le FBI et/ou la NSA, en collaboration avec Microsoft.
2005 : début de la conception de l’UEFI, remplaçant du BIOS.
2011 : Microsoft annonce que les PC faisant tourner Windows 8 devront impérativement être équipés de Secure Boot, ce qui fait râler pas mal de monde (notamment du côté des distributions GNU/Linux, que Secure Boot risque d’empêcher de démarrer faute de clé valide).
2012 : ajout officiel de Secure Boot à la norme UEFI (Spec 2.3.1 Errata C).
2013 : début des révélations d’Edward Snowden.
Autrement dit cette backdoor a été introduite bien avant les révélations de Snowden… À une époque où l’on sait (grâce à Snowden justement) que Microsoft travaillait main dans la main avec la NSA. Alors, erreur ? Coïncidence ? On en saura peut-être plus à l’avenir…
#28
#29
#30
#31
Hein ?
C’est quoi ce vieux FUD que vous nous faites ?
Non parce que Windows ne demande qu’une chose : que le secure boot soit actif.
Il est parfaitement possible d’installer son propre jeu de clés persos, genre clés privées, publiques et tuti quanti et de faire ses propres certifs sans que windows ne dise rien.
http://www.rodsbooks.com/efi-bootloaders/controlling-sb.html
Cadeau.
Et vous pouvez du coup, dire “merde” a cette faille lolesque : personne n’ira installer d’autres clés que les votre. En revanche, là ou c’est problématique, c’est que cette faille permette de démarrer windows en mode secure, sans l’être. Et ça, c’est pas un problème de secure boot, mais de windows.
Edit : et bien entendu avec vos propres KEK et db/dbx, la goldenkey de microsoft, ben elle existe plus.
#32
Cool story… mais heu… c’est quand qu’on parle de backdoor là ?
Surtout je ne vois pas trop le rapport entre le secure boot et le backdoor. Le secure boot à pour but de garantir qu’il n’y a aucun logiciel qui s’est lancé entre le “BIOS/UEFI” et l’OS afin de réduire le risque de logiciel malveillant.
Dans le pire des cas, si il y a un backdoor dans le secure boot, ça revient au même que l’absence secure boot. Ainsi, le secure boot n’est pas un danger supplémentaire d’intrusion par rapport à son absence.
#33
mode conspiration ou pas
" />si j’y arrive 
" />
J’arrivais avec mon Win 7 à jouer avec une fluidité acceptable au dernier Tombraider (rise of..), aujourd’hui avec toujours mon Win 7, c’est moins bien, que s’est-il passé depuis que les màj pour forcer à passer à 10.
Mon PC est plus lent. Un bon nettoyage s’impose
#34
#35
Il n’y a pas de backdoor dans le secure boot. Le seul backdoor ici c’est : goldenkey dans la nature pour microsoft et ses certifs, et windows qui boot en mode debug. Secureboot n’est pas impacté.
Tu change tes clés, tu force les clés BCD secure et tu efface toute les entrées merdique, tu change les db/dbx et t’es peinard.
#36
#37
Ouais mais faut voir l’intérêt du truc avant de voir le complot…
Empecher un OS de booté sur un produit vendu avec du Windows à l’intérieur. Pas sur que la NSA ou FBI avait ce besoin. Par compte si ça donnait la possibilité à une backdoor dans lequel un malware ou autre pouvait se faufiler là ouai.
La seule personne à qui ça pose préjudice est Microsoft. Je crois pas que voir une machine Surface fonctionnait sous android leur ferai plaisir :-/
#38
#39
#40
#41
Shim a une clé valide. Tu peut installer une MOK sur Shim. Tu as donc des clés valides.
Pour les tablettes et autres : suffit de passer en mode debug hard (qui lui est obligatoire ne serait-ce que pour initier les puces) qui te permet … De passer outre secure boot et d’installer n’importe quoi dessus.
J’ai une surface pro avec mes propres bd/bdx/PK et KEK, en dual boot linux/windows et j’ai juste aucuns soucis.
#42
L’option de désactiver le secure boot peut bien ne plus être présente : c’est un faux problème, CF au dessus, tu peut installer tes propres clés.
#43
#44
#45
Bon, je le redis parce que visiblement, y’en a qui sont dur de la feuille : la question des certificats est un faux problème.
Vous pouvez être votre propre autorité de certification. CF le lien posté au dessus. La question de microsoft seul et unique signataire est donc nulle. Qu’ils soient la seule autorité reconnue au niveau industriel est un fait, encore que c’est VeriSign qui signe les certificats pour microsoft. Qu’il ne soit pas possible de signer les certificats autrement est faux.
Si les certificats sont révoqués : pas de soucis, signe tes propres certificats épicétou.
Edit : le problème ici n’est pas que seul microsoft puisse signer, mais que windows laisse une possibilité de booter en mode debug, et que des golden keys sont dans la nature. (édition BCD et certificats propres permettent de virer totalement la faille.)
#46
#47
D’ailleurs, sur ma carte mère (une MSI 990FXA Gaming), par défaut, les clefs de Microsoft ne sont pas chargées. Il propose d’abord de mettre les siennes.
Du coup, il m’a fallut un peu de temps pour comprendre qu’il fallait faire “charger les valeurs par défaut” pour qu’il importe les clefs de Microsoft et que je ne me prenne pas la tête à les créer moi-même !
#48
#49
http://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Tout est expliqué, ici.
Tout est expliqué dans l’implémentation de secureboot sur le site d’intel. Tout est expliqué dans le compendium pour l’EDK, et depuis que l’EFI existe sur plateforme itanium, et qu’apple ont commencés a installer les premiers éléments de sécurisation du boot.
Et c’est pas de la crypto mais de l’admin sys.
Et c’est de la très mauvaise fois que de basher microsoft sur ce point : ils sont unique certificateurs par défaut parce que personne d’autre ne veux le faire, les industriels demandant des garanties juste impressionnantes.
De plus, la certification et la révocation, sont sur plateforme microsoft, juste transparente. C’est pas comme si l’OS avait accès a la partie dbx/KEK/KEXt de la nvram stockant les infos UEFI/Boot/BCD.
Et d’ailleurs, de ce point de vue, linux est une faille de sécurité a lui tout seul : lui y accède en dur via le shell.
Et là, entre nous, si tu t’intéresse un minimum au sujet, tu verra que l’utilisateur lambda tel que tu le décris ne pourra être impacté par ce genre de failles : faut un accès physique a la machine. Ca peut permettre de véroler un kiosk sous windows et de le démarrer en mode “admin”, mais dans les faits avant de pouvoir installer un malware qui ira te véroler l’OS, voir un OS vérolé tout court, y’a un gouffre.
Et non, ça ne sera jamais simple, car c’est une fonction qui peut bricker une carte mère. (modifier les db/PK demande d’aller directement éditer les bases dans les oproms contenant l’UEFI, et donc d’écrire en mode réel, et donc … de ne plus être en mesure de booter, du tout.).
Seule exception, les périph ARM qui ont leurs mécanismes par design sur une partoche spécifique du stockage de masse. Seul le POST est réalisé en hard (et intégré au SoC).
#50
Tu ne veux pas mettre quelques sauts de lignes ?
" />
#51
Y’en avait, ils ont sauté. Je tente l’edit :O
Edit : ça me fait penser qu’il y a des goldens arm dans la nature depuis 2010 qui permettent de booter sur des chip samsung et snapdragon.
Quand c’est pour du jailbreak, on en parle positivement, mais quand c’est sur x86, oulalala.
#52
#53
#54
J’avais déjà survolé ton lien que tu avais mis dans un post précédent et je répète en plus clair : le problème n’est pas que gérer tout ce mécanisme de clés est infaisable, mais que d’un point de vue utilisateur, ce sera vu comme une forme de sabotage à coup de complexité inutilement excessive.
C’est pas comme si l’OS avait accès a la partie dbx/KEK/KEXt de la nvram stockant les infos UEFI/Boot/BCD
Peut-être pas ça, mais après l’Anniversary Update, mon Secure Boot s’est remis en Windows UEFI alors que je suis persuadé de l’avoir réglé autrement. Je ne sais pas si c’est lié à l’update, ou si je n’aurai pas bêtement oublié de le retirer après une récente update du BIOS (c’est toujours possible). Mais ça ne retire pas l’impression que mon ordinateur appartiendrait plutôt à Microsoft Corp qu’à moi-même (il faut dire que W10 et ses mises à jour majeures remet par défaut certains réglages donc…).
#55
à un moment ou à un autre t’achètes bien la carte mère non ?
(Même si c’est pour mettre un Linux)
Moi je vois une certification par un organisme européen ad hoc. Histoire de ne pas confier les clés du camion à une société américaine…
#56
#57
#58
M$ est vraiment nul a chier.
#59
Parfaitement dit.
La détection d’un support bootable (cd/dvd/clé usb) contenant un certificat devrait proposer l’insertion de ce certificat.
Bie sûr en précisant bien les implications de son acceptation et avec un mécanisme d’acceptation non trivial : taper “oui” (ou le CRC de la clé) et pas simplement entrée)
#60
Et bien pour pouvoir être vendue en Europe toute carte mère disposant d’un mécanisme de sécurité devrait obligatoirement être préinstallée avec un certificat dont la gestion serait assuré par un organisme européen.
Au lieu de venir simplement avec le certificat MS de facto
#61
#62
#63
#64
Exigences qui sont : faire partit des promoters. (http://uefi.org/members )
Avoir une procédure de validation visible par tous, disponible pour tous, le financement ne rentrant pas en compte. Que la procédure de validation soit acceptée par tout les promoters.
Que les certificats soient révocables, et de pouvoir répondre à toutes demandes.
D’avoir une procédure d’audit des codes, obligeant à la confidentialité mais qui soit suffisamment performante en termes sécuritaires pour pas valider n’importe quoi.
Que les certificats racines ne soient pas hébergés en interne.
Que les certificats racines et l’organisme de certification soit connu et reconnu de tous.
Bref … Pas a la portée du premier venu. Et vu le prix que fait raquer VeriSign a Microsoft, 99$ la clé KEK privée pour installer ses propres MOK et avoir son propre Shim, c’est pas cher payé.
Et n’en déplaise à la majorité, ceux qui ont poussés pour l’adoption du secure boot sont Apple, Intel, IBM et RedHat. Pas Microsoft.
#65
Tu saute directement a la case “utiliser KeyTool”.
#66
Et en plus je suis sûr que t’es sérieux en disant ça…
#67
#68
#69
Je te laisse voir les spec d’EFI sur Itanium, d’EFI sur matos Apple. Du blindage demandé par IBM sur leurs serveurs. Et les demandes de RedHat concernant l’UEFI, d’ailleurs, Shim, c’est pas un hasard si ça provient de RedHat (il était dans les cartons depuis un bout de temps, puisqu’ils ont bossés a l’intégration de x509 non seulement dans le kernel linux mais aussi dans l’EFI, c’est AUSSI pour ça que Linus l’a mauvaise concernant le secure boot.)
Le problème n’est encore une fois, pas la technologie en elle même, ni l’organisme certificateur.
Le problème ici, c’est, encore une fois, microsoft qui fait deux bourdes a laisser le mode debug, et une golden key kek dans la nature.
Braif.
Avant de crier au complotisme, faudrait déjà arrêter de regarder les faits de manière biaisées : hormis des suppositions sur se que voudrait microsoft. Le contrat VeriSign se chiffre en millions de dollar/ans pour “valider” une db et des PK. Le gain pour microsoft est quasi nul, la KEK a 99$ c’est vraiment économique, surtout pour RedHat avec son Shim du coup, si vous avez pas encore capté les mécanismes en jeu, même sans parler de la faille, vous avez, grâce a shim, la possibilité de signer vos kernel sans soucis avec un MOK. Mais il a été demandé a microsoft de devenir organisme certificateur, parce que personne n’avait (et n’a encore) l’équipe de dev a coller pour mater les boots process, drivers EFI et autre à valider.
Secure boot obligatoire ? A ma connaissance, il n’y a que les device arm qui IMPOSENT secure boot à l’heure actuelle. Je te laisse regarder se qu’en une bootchain et comment fonctionne un ordinateur a partir du POST jusqu’au log.
UEFI est plus simple a utiliser que BIOS. UEFI est carrément plus portable que BIOS. Et rien qu’un truc que vous avez pas encore compris : avec UEFI, c’est la FIN DES PROBLEMES D’ACPI/APIC et définition hasardeuses de matos dans une table obscure. La sécurité avec secure boot, c’était juste demandé par tout les acteurs un tant soit peu dans le coup. La mise en oeuvre vous plait pas ? Et bien faite en un vous même, proposez, si y’a autant de brouzouf a se faire, vous allez être millionnaires. (un indice : personne veux se mettre sur le créneau parce que c’est un service A PERTE).
Donc comme le BIOS : vous apprenez a utiliser l’UEFI et on en reparle au lieu de critiquer. D’ailleurs, je pense pas que les devs kernel linux soient mécontents d’être passés sur UEFI.
#70
#71
#72
Je ne comprend pas la dernière phrase.
La porte dérobé a toujours existé, mais elle a été mis en lumière par 2 chercheurs.
Le FBI pouvait très bien être au courant et utiliser abondamment cette porte bien avant que des chercheurs la publie.
#73
Une backdoor normalement destinée à un environnement de debug, ce n’est pas vraiment une backdoor. Le problème est que ça s’est retrouvé dans la nature, pas qu’ils aient créé cette backdoor dès le départ.
#74
#75
#76
#77
En gros le fbi n’est plus obliger d’agir machine par machine, mais il peut avoir l’anneau pour les gouverner tous … :)
#78
C’est tellement gros qu’on se demande si c’était pas voulu…
#79
PROJECT SAURON c’est la news d’à coté.
" />
#80
Exactement, car l’étape suivante après l’avoir rendu “optionnel” (et oublié sciemment de mentionner la possibilité de mettre ses propres clés) c’est de le rendre “non désactivable”.
Bref cela ne “Sécurise” qu’une chose : le modèle économique basé sur le racket de M$ !..
#81
Cette backdoor permet de booter n’importe quoi.
Tu bootes sur Kon Boot et tu as le système tout entier, il supporte Windows 10.
Tu vois l’enjeu ? C’est énorme.
#82
J’ai cru lire que tu étais tombé tout nu !
" />
#83
On est d’accord que pour effectuer une telle manipulation et un tel reboot sur un autre OS, il faut que les conditions suivantes soient requises :
Parce qu’une faille de la mort qui tue qui fait que ton pc reboote sur un autre OS que le tien, c’est limite niveau discrétion. Donc je vois pas trop le danger en fait (Outre l’aspect commercial qui permet de booter des autres OS sur des plateformes pour laquelle Microsoft a signé le deal licence moins chères contre pas de changement d’OS).
#84
#85
Du coup hack de la Xbox One soon non ?
#86
voila qui ressemble à une signature ;) :
075eea060589548ba060b2feed10da3c20c7fe9b17cd026b94e8a683b8115238
07e6c6a858646fb1efc67903fe28b116011f2367fe92e6be2b36999eff39d09e
09df5f4e511208ec78b96d12d08125fdb603868de39f6f72927852599b659c26
0bbb4392daac7ab89b30a4ac657531b97bfaab04f90b0dafe5f9b6eb90a06374
0c189339762df336ab3dd006a463df715a39cfb0f492465c600e6c6bd7bd898c
0d0dbeca6f29eca06f331a7d72e4884b12097fb348983a2a14a0d73f4f10140f
0dc9f3fb99962148c3ca833632758d3ed4fc8d0b0007b95b31e6528f2acd5bfc
106faceacfecfd4e303b74f480a08098e2d0802b936f8ec774ce21f31686689c
174e3a0b5b43c6a607bbd3404f05341e3dcf396267ce94f8b50e2e23a9da920c
18333429ff0562ed9f97033e1148dceee52dbe2e496d5410b5cfd6c864d2d10f
2b99cf26422e92fe365fbf4bc30d27086c9ee14b7a6fff44fb2f6b9001699939
2bbf2ca7b8f1d91f27ee52b6fb2a5dd049b85a2b9b529c5d6662068104b055f8
2c73d93325ba6dcbe589d4a4c63c5b935559ef92fbf050ed50c4e2085206f17d
2e70916786a6f773511fa7181fab0f1d70b557c6322ea923b2a8d3b92b51af7d
306628fa5477305728ba4a467de7d0387a54f569d3769fce5e75ec89d28d1593
3608edbaf5ad0f41a414a1777abf2faf5e670334675ec3995e6935829e0caad2
3841d221368d1583d75c0a02e62160394d6c4e0a6760b6f607b90362bc855b02
3fce9b9fdf3ef09d5452b0f95ee481c2b7f06d743a737971558e70136ace3e73
4397daca839e7f63077cb50c92df43bc2d2fb2a8f59f26fc7a0e4bd4d9751692
47cc086127e2069a86e03a6bef2cd410f8c55a6d6bdb362168c31b2ce32a5adf
518831fe7382b514d03e15c621228b8ab65479bd0cbfa3c5c1d0f48d9c306135
5ae949ea8855eb93e439dbc65bda2e42852c2fdf6789fa146736e3c3410f2b5c
6b1d138078e4418aa68deb7bb35e066092cf479eeb8ce4cd12e7d072ccb42f66
6c8854478dd559e29351b826c06cb8bfef2b94ad3538358772d193f82ed1ca11
6f1428ff71c9db0ed5af1f2e7bbfcbab647cc265ddf5b293cdb626f50a3a785e
71f2906fd222497e54a34662ab2497fcc81020770ff51368e9e3d9bfcbfd6375
726b3eb654046a30f3f83d9b96ce03f670e9a806d1708a0371e62dc49d2c23c1
72e0bd1867cf5d9d56ab158adf3bddbc82bf32a8d8aa1d8c5e2f6df29428d6d8
7827af99362cfaf0717dade4b1bfe0438ad171c15addc248b75bf8caa44bb2c5
81a8b965bb84d3876b9429a95481cc955318cfaa1412d808c8a33bfd33fff0e4
82db3bceb4f60843ce9d97c3d187cd9b5941cd3de8100e586f2bda5637575f67
895a9785f617ca1d7ed44fc1a1470b71f3f1223862d9ff9dcc3ae2df92163daf
8ad64859f195b5f58dafaa940b6a6167acd67a886e8f469364177221c55945b9
8bf434b49e00ccf71502a2cd900865cb01ec3b3da03c35be505fdf7bd563f521
8d8ea289cfe70a1c07ab7365cb28ee51edd33cf2506de888fbadd60ebf80481c
9998d363c491be16bd74ba10b94d9291001611736fdca643a36664bc0f315a42
9e4a69173161682e55fde8fef560eb88ec1ffedcaf04001f66c0caf707b2b734
a6b5151f3655d3a2af0d472759796be4a4200e5495a7d869754c4848857408a7
a7f32f508d4eb0fead9a087ef94ed1ba0aec5de6f7ef6ff0a62b93bedf5d458d
ad6826e1946d26d3eaf3685c88d97d85de3b4dcb3d0ee2ae81c70560d13c5720
aeebae3151271273ed95aa2e671139ed31a98567303a332298f83709a9d55aa1
afe2030afb7d2cda13f9fa333a02e34f6751afec11b010dbcd441fdf4c4002b3
b54f1ee636631fad68058d3b0937031ac1b90ccb17062a391cca68afdbe40d55
b8f078d983a24ac433216393883514cd932c33af18e7dd70884c8235f4275736
b97a0889059c035ff1d54b6db53b11b9766668d9f955247c028b2837d7a04cd9
bc87a668e81966489cb508ee805183c19e6acd24cf17799ca062d2e384da0ea7
c409bdac4775add8db92aa22b5b718fb8c94a1462c1fe9a416b95d8a3388c2fc
c617c1a8b1ee2a811c28b5a81b4c83d7c98b5b0c27281d610207ebe692c2967f
c90f336617b8e7f983975413c997f10b73eb267fd8a10cb9e3bdbfc667abdb8b
cb6b858b40d3a098765815b592c1514a49604fafd60819da88d7a76e9778fef7
ce3bfabe59d67ce8ac8dfd4a16f7c43ef9c224513fbc655957d735fa29f540ce
d8cbeb9735f5672b367e4f96cdc74969615d17074ae96c724d42ce0216f8f3fa
e92c22eb3b5642d65c1ec2caf247d2594738eebb7fb3841a44956f59e2b0d1fa
fddd6e3d29ea84c7743dad4a1bdbc700b5fec1b391f932409086acc71dd6dbd8
fe63a84f782cc9d3fcf2ccf9fc11fbd03760878758d26285ed12669bdc6e6d01
fecfb232d12e994b6d485d2c7167728aa5525984ad5ca61e7516221f079a1436
ca171d614a8d7e121c93948cd0fe55d39981f9d11aa96e03450a415227c2c65b
55b99b0de53dbcfe485aa9c737cf3fb616ef3d91fab599aa7cab19eda763b5ba
77dd190fa30d88ff5e3b011a0ae61e6209780c130b535ecb87e6f0888a0b6b2f
c83cb13922ad99f560744675dd37cc94dcad5a1fcba6472fee341171d939e884
3b0287533e0cc3d0ec1aa823cbf0a941aad8721579d1c499802dd1c3a636b8a9
939aeef4f5fa51e23340c3f2e49048ce8872526afdf752c3a7f3a3f2bc9f6049
64575bd912789a2e14ad56f6341f52af6bf80cf94400785975e9f04e2d64d745
45c7c8ae750acfbb48fc37527d6412dd644daed8913ccd8a24c94d856967df8e
#87
C’est le cas, pourtant.
#88
#89
#90
Si j’ai bien compris, ca ne changera pas grand chose…
Rien n’empeche une distro linux, voire un utilisateur de modifier, recompiler et installer une version modifiée d’un élément de boot de ton système (grub, kernel, autre?).
Et cet élément modifié ne sera jamais signé par quiconque de reconnu. (exception pour les distros qui se seront faites connaitre par ton consortium)
(OK, un utilisateur, y a peu de chance que ca arrive, mais une distro, pq pas…)
Bonus si tu trouves une solution pour les distribs sources comme gentoo pour signer tes binaires sans avoir leurs clés (si ils en avaient) !
=> à moins de le faire avec tes propres clés et de les ajouter dans le hard, c’est mort. Et on en revient a ce qui est expliqué plus haut.
Et ton consortium, c’est lui qui va aller voir les constructeurs de CM pour leur filer les clés des différentes distros qui ont été lui demander d’être reconnus ?
#91
#92
Je me permet une grosse correction : SecureBoot poussé par RedHat… Il me semble que c’est réécrire l’histoire ! (et dans ta page parlant d’UEFI en général, ils ne sont pas promoters mais contributors)
Ils ont été les premiers à soulever le problème que posera SecureBoot sur les machines certifiées Win8.
Ensuite il y a eu 2 solutions qui ont été bossées en parallèle pour les distributions linux :
Pas vraiment ce qu’on peut appeler des encouragements vers SB…
Si mes souvenirs ne sont plus corrects, corrigez moi, mais il me semble que c’est ca.
#93
Grosso modo, c’est ça. Hormis qu’ils ont bien poussés en tant que contrib a l’adoption de SB pour une raison : securiser des firmware (comprendre firmware dans le sens association matériel + logiciel créés et bloqués par des firmes/industriels). Pour une raison simple : ils sont les premiers pourvoyeurs de solutions sécurisées “open source” pour le gourvernement US. Miscrosoft arrive bien après ceux mentionnés.
Pour les solutions, il y à en réalité 3 :
-Shim, poussé par RedHat et canonical.
-PreLoader signé par MS pour la Linux Foundation.
-Canonical qui fait signer ses kernels en passant par les mêmes certifs que MS auprès de VeriSign/Symantec (ils ont les mêmes signatures hash)
Actuellement, les premiers “promoters” de SB sont même pas les promoters de UEFI mais les fabricants de portables, IoT et autres single board computer : ça leurs permet de contrôler se qui tourne sur leurs machines (chose que microsoft, par design, ne peut pas faire, même si ils aimeraient et à la condition qu’ils le veuillent).
#94
Et toujours si je ne me trompe pas :
Il reste à l’intégrer dans les données utilisateurs (ou via les clouds) et on verra qu’un concept comme palladium, ca met 15 à 20 ans pour se mettre en place.
#95
Techniquement, non, tout device peut être locké par firmware de bout en bout de la chaine : CF l’utilité d’une puce type Nuvoton, IPMI management board et autres concepts de management OOB et BMC. Hormis que les canaux ne sont pas pour le moment signés de manière obligatoire.
" />
Il y a des POC qui circulent sur du trusted computing.
Pour voir des trucs vraiment crasses faut plutôt aller jeter un oeuil direction TCG, TPM et autre http://www.trustedcomputinggroup.org/ ou là, on parle vraiment de cadenasser l’infra et les device.
http://www.iotsworldcongress.com/ge-intel-microsoft-mit-red-hat-schneider-and-th…
Vous comprendrez que SB n’est pas un enjeux prioritaire : ils ont autre chose a se foutre sous la dent (généralisation d’Opal dans les puces Nuvoton, TPM a tout les niveaux)
#96
#97
Ca reste les mêmes concepts en version light pour le moment, contournable, histoire de pas faire gueuler les acheteurs, habituer la population.
Mais je continue de croire que c’est malheureusement la tendance générale au nom d’une certaine “sécurité”.
#98
Il y a des concepts sympathiques, reste a savoir combien de temps l’utilisateur final d’un produit restera concerné.
Je fait partie des rares fouteurs de merde dans ce genre de consortiums, en revanche, j’exècre le fait de cracher sur la technologie pour des problèmes philosophiques. La technologie est neutre jusqu’à présent, et le soucis : plus les gens cracheront dessus, plus les industriels feront tout pour passer en force avec des éléments techniques où justement, les mecs comme moi n’auront plus leurs mots a dire. Et donc, moins la technologie sera neutre (et génératrice de problèmes d’administration.)
Faut bien comprendre qu’il faut une évolution, le mieux restant de laisser aux gens dont c’est leurs travail, le faire et pas coller des assertions juste par principe : ça ne fait que modifier les opinions mais pas le fondement. Le fond est “honnête”, la résultante l’est moins, et le sera de moins en moins, parce que l’utilisateur final refuse de faire sa part de taff : apprendre a utiliser le système.
#99
#100
Je suis sysadmin. Et je préfère 100 fois plus UEFI que BIOS.
#101
#102
L’implémentation est laissée libre aux intégrateurs, OEM et fabricants de CM. Le problème n’est pas Microsoft mais les intégrateurs, OEM et fabricants de CM.
SB n’est qu’un élément d’un tout, UEFI a simplifié et formaté les choses : c’est un standard. Avant, c’était bien pire : une table ACPI mal fichu t’empêchait d’installer ta distro sur certains mobales. Comme le dit Linus, le problème n’est pas SB, Linux supporte le x509 (et ce de manière active puisque les devs kernels sont les principaux contributeurs), mais l’implémentation qui n’a pas été standardisée.
Si tu prend tianocore de base, le module secure boot se résume a intégration de certifs x509, une fonction sha256 pour le hash, db et dbx. Microsoft demande une interface compilée avec leurs compilo UEFI maison avec un flag mft sur le module, et que le binaire soit signé via HSM. Y’a pas de standardisation. CoreBoot a techniquement un moteur de gestion de signatures qui permet d’avoir un secureboot fonctionnel mais pas de clés MS intégrées : c’est pas standard encore une fois.
Donc les fabricants de CM/OEM/Intégrateurs font se qui va leurs rapporter des brouzoufs : certif microsoft même si c’est pas standard et basta.
Le soucis, c’est que si les utilisateurs ne poussent pas a demander un standard avec une gestion centralisée documentée, MS se bougera pas et les fabricants de CM non plus, la réponse que les utilisateurs sortent c’est “je désactive SB” ou “je passe en legacy + CSM” (se qui est encore pire). Quant tu vois des systèmes comme GPT + EFS + stack drivers .efi sous utilisés, qu’on conseille d’utiliser grub et de rester en mode legacy pour 99% des tutos, ça fait peur. “c’est compliqué” : Non, c’est carrément plus simple, UEFI détecte lui même les bootloader, et le chainloading n’existe plus. Grub/Elilo/Whatever, ça ne sert plus a rien en réalité : l’amorçage en UEFI n’existe pas. Suffit juste d’un manager (soit intégré a la CM soit custom style refind/BCDmanager de microsoft).
C’est tellement simple que ça permet de faire du stateless dès le PE.
Moralité, c’est pas après microsoft qu’il faut gueulé, mais après asus, gigabyte, whatever, de supporter le soft.
#103
#104
L’UEFI permet surtout à microsoft de réécrire l’ordre de démarrage en mémoire à son avantage. Sur plusieurs modèles, un simple passage dans le BIOS et hop : votre grub disparaît ! Il faut repasser par efibootmgr pour arrêter les conneries. Certains copains fabricants continuent ainsi de lécher les bottes de microsoft à tout va, et ce superbe abus de position dominante n’est pas un hasard de plus.
Concrètement, le SB, n’ajoute aucune sécurité réelle, et est surtout là pour emmerder les libristes. N’oublions pas que la partition UEFI est en FAT, et que c’est microsoft qui distribue les clés, et a ansi réussi à se rendre indispensable de fait. Encore un abus de plus pour une société qui n’a plus rien dans les boyaux. Il est heureux que les fabricants aient compris qu’il valait mieux pour eux laisser l’option de désactivation de cette merde.
Plus globalement, le SB n’ajoute finalement rien à la sécurité bancale de windows. Non content d’utiliser ses mises à jour en cheval de troie, en les rendant encore obligatoires et non désactivables sur les versions grand public, on ne compte plus les plantages de machines dues à ces même mises à jour, ce qui prouve bien que l’éditeur ne maîtrise plus son propre produit. On a désormais plus de problèmes en laissant les mises à jour activées qu’en bridant ces mises à jour. Et là je parle de versions pro, qui constituent malheureusement l’énorme majorité des windows en PME/PMI. Je n’ose même pas imaginer le bordel subit côté particuliers !
Finalement, la seule bonne nouvelle de cette news, c’est qu’on pourra peut être récupérer du matériel bridé avec de l’OS GNU/Linux, si certains ont envie de s’amuser. Pour ma part, cela prouve surtout que la NSA a encore bien travaillé, et que le “fait moi confiance” de nos amis GAFAM est la meilleure méthode pour se faire plumer.
Pour le reste, la dernière Ubuntu 16.04 fonctionne nickel. Idem côté Debian 8. Difficile de demander plus qu’un ordinateur qui marche, sans se prendre la tête. Il est surtout surprenant, quand on compare les deux OS, qu’il y ait encore des gens sous windows…
#105
#106
#107
#108