Pour déjouer la technique d'infection « bring your own vulnerable driver » (BYOVD), Microsoft expliquait depuis 2 ans avoir mis en place dans son système de mises à jour une liste noire des pilotes dangereux permettant de bloquer toute installation d'un de ces pilotes.
En effet, la technique BYOVD consiste à installer un pilote connu pour contenir une faille de sécurité puis de l'exploiter. Problème, comme l'a découvert Ars Technica, cette liste n'était pas mise à jour correctement, laissant les systèmes d'exploitation de Microsoft faillibles à ce genre d'attaques.
Microsoft a publié un outil permettant de mettre à jour la liste des pilotes dangereux de ces trois dernières années mais, comme l’expliquent nos confrères, c’est une mise à jour exceptionnelle et il n’est pas certain que Microsoft puisse la faire régulièrement.
Commentaires (24)
#1
Pourquoi est-ce qu’il y a besoin de ce montage avec une liste de drivers à mettre à jour par un système spécifique ? Les drivers sont signés par Microsoft ; ils ne peuvent pas simplement révoquer leur certificat, et basta ?
#1.1
Si tu révoques le certificat, tu invalides la signature de tous les drivers signés avec celui-ci.
#1.2
Oui, si tu signes directement avec le certificat racine. Mais on sait faire mieux, surtout en 2022.
#1.3
Non. On ne signe jamais un logiciel avec un certificat racine.
On ne créée jamais non plus un certificat par logiciel à signer.
Donc, Freeben666 a raison.
De plus, pour connaître les certificats invalidés, il faut une liste qu’il faut aussi mettre à jour et télécharger.
Ici, on a une liste des pilotes dangereux et quelle surprise, il faut la maintenir à jour et la télécharger !
#2
C’est beaucoup plus simple de se reposer sur les listes de certificats invalidés (qui existe déjà chez MS, espérons-le), plutôt que de mettre en place un système ad-hoc qui n’est pas maintenu.
#2.1
Qu’est-ce que tu n’as pas compris dans les réponses de Freeben666 et la mienne (la partie que tu n’as pas citée) ?
#2.2
Reprenons, donc la partie élidée.
Bien entendu, on est d’accord.
On ne le fait pas, certes, mais pourquoi ? Moi on m’a toujours enseigné dans mes cours de crypto qu’un certificat doit toujours être révocable, sinon il n’est pas utilisable en pratique, et donc c’est comme s’il n’existait pas. Si pour pouvoir révoquer la signature de drivers véreux, il faut un certificat par driver, alors pourquoi ne pas l’avoir prévu comme ça ? Signer les drivers, c’est bien pour éviter les drivers véreux, donc la capacité de révoquer la signature d’un driver dont on découvre a posteriori qu’il est véreux, ça me semble être une fonctionnalité de base du système. Difficile de croire que ça n’ait pas été prévu.
Ah, ok alors. J’entends bien l’argument.
#3
Pourtant on crée bien un certificat par site Web (pour l’utilisation du SSL (aka HTTPS)).
#3.1
Ça n’a rien à voir. Ce dont tu parles est un certificat utilisé pour le chiffrement de la liaison, pas la signature d’un logiciel.
#4
Et chaque développeur agréé par Microsoft a un certificat pour pouvoir publier sur le Microsoft Store.
#5
La solution de ne pas que se baser sur la révocation de certificat est logique. Car un même certificat peut signer plusieurs drivers. Et il se peut qu’un seul de ces drivers soit compromis, et que le certificat ne soit pas compromis.
C’est pour cela que Microsoft a ajouté cette liste des drivers compromis, en plus de la révocation des certificats compromis.
Et mettre cette liste à jour très rapidement, pourrait désactiver de très nombreux périphériques. Un arbitrage classique dans la sécurité entre la disponibilité et l’intégrité…
Accessoirement, cette protection (temporairement dysfonctionnelle) nécessite d’activer hypervisor-protected code integrity or HVCI, ce qui revient à mettre le cœur de Windows dans une machine virtuelle. C’est sécurisé, mais à moins d’avoir un PC très récent cela ralenti la machine et consomme plus, sur mon portable avec un i5 de génération 8 j’ai dû revenir en arrière pour le confort.
Ce n’est activé par défaut que sur Windows 11 et des PC récents.
Donc cette news concerne encore peu de monde, me semble-t-il.
#5.1
je l’avais d’activer sur ma précédente machine, ça fonctionne bien par contre ça bloquait ryzen master
#6
Penser qu’une simple révocation de certificat permettrait de résoudre le problème, c’est tout simplement ne pas comprendre les mécanismes qui sont en jeu.
Les certificats ont pour but de créer une hiérarchie de confiance. Il faut une autorité racine, qui va elle-même “certifier” des autorités intermédiaires (qui peuvent éventuellement certifier d’autres autorités intermédiaires), pour certifier une autorité finale (ici, l’éditeur du driver).
Un certificat, c’est fait pour gérer l’identification, l’authentification, la signature et la non répudiation. Ce n’est pas fait pour interdire un truc sous prétexte qu’il y a une faille de sécurité. Et surtout, c’est fait pour que hiérarchiquement, chacun prenne ses responsabilités.
Si une autorité présente une défaillance, alors son autorité “de tutelle” peut la révoquer. Et l’autorité de tutelle peut elle-même être révoquée si elle ne fait pas correctement son travail et ainsi de suite jusqu’à remonter au certificat racine (qui lui, ne peut pas se révoquer).
Utiliser un certificat pour gérer la révocation des drivers, cela sous-entend donc
Ne pas se baser sur les certificats pour gérer une liste de pilotes malveillants, c’est permettre à une seule entité (ici Microsoft) d’agir dès qu’une faille est détectée, sans avoir besoin d’attendre une action de la part de l’éditeur correspondant.
Maintenant, se pose le problème de la mise à jour. Mais si Microsoft ne le fait pas (alors qu’il a tout intérêt d’un point de vue sécurité), il est illusoire de penser que les éditeurs le feront d’eux-mêmes…
#7
La signature des drivers certifie que le driver est digne de confiance. Le driver n’est plus digne de confiance ? On révoque son certificat. Je ne vois pas où est le détournement, ça me semble au contraire couler de source. D’ailleurs, quand on lit la doc Microsoft, ils parlent bien de révoquer un driver déjà signé, eux aussi mettent bien en évidence que ne jamais l’avoir signé aurait réglé le problème.
Oui, et ? Un certificat, c’est un fichier, rien de plus. Faut un peu démystifier le truc, hein. Si tu gardes une trace de ce que tu signes (en général, c’est conseillé), tu as déjà un autre fichier pour chaque driver : le driver lui-même.
Ah bon ? Tu sais que tu peux générer des certificats intermédiaires sans déléguer pour autant. D’ailleurs, actuellement c’est déjà le cas, MS ne signe pas avec la clef racine, ils possèdent donc eux-même un certificat intermédiaire signé par eux-mêmes.
#8
Un certificat aujourd’hui est utilisé pour signer plein de pilotes. Ce n’est peut-être pas la “bonne” façon de faire, mais on en est là.
Donc révoquer un certificat pour un pilote en particulier va en invalider plein qui ne sont pas compromis.
D’où un mécanisme autre pour invalider un pilote particulier sans passer par la révocation d’un certificat.
Mais bon à partir du moment où un certificat a pu être utiliser pour signer un pilote frauduleux, peut-on vraiment considérer comme fiable le-dit certificat ?
#9
Ce dont on parle, ce n’est pas un pilote “frauduleux” mais un pilote avec des failles corrigées par un pilote plus récent. L’attaque consiste à réinstaller ce pilote pour ensuite utiliser ses failles. Sans liste de drivers vulnérables, le système autorise l’installation de ce driver puisqu’il est signé.
#9.1
Effectivement, j’suis resté sur le titre, pour moi malveillants, implique une intentionnalité, que le pilote ait des failles de sécurité ça arrive tout le temps.
Ça serait un beau bordel si pour chaque pilote buggé, il fallait invalider tout un tas d’autre pilote
#10
Parce que celui qui va révoquer n’est pas celui qui va signer. Je l’ai précisé dans mon précédent message (partie que tu ne commentes absolument pas alors que ça fout justement en l’air l’utilisation des certificats pour un tel usage). Lorsqu’une autorité révoque un certificat, c’est qu’il y a un souci avec ce certificat (volé, fuite de la clé privée, ou que sais-je). Celui qui révoque est donc celui qui a émit le certificat. La situation est ici fort différente, puisque Microsoft, sur la base des failles découvertes, décide de bloquer un driver malveillant ou présentant une faille de sécurité. Microsoft, pas l’éditeur dudit driver.
C’est une complexité supplémentaire sous estimé (gestion de la clé privée oublié par exemple), mais surtout inutile car inefficace et non adapté techniquement.
Il va falloir m’expliquer l’intérêt d’avoir un certificat intermédiaire s’il n’y a aucune délégation
Et heureusement que Microsoft ne signe pas avec son certificat racine. Le certificat racine (enfin sa clé privée surtout) ne sert que dans très peu d’occasion (pour des raisons de sécurité) et est conservé à part (et normalement, hors ligne pour une sécurité maximum).
Maintenant, un éditeur se retrouvera de facto autorité intermédiaire, puisqu’il devrait gérer les certificats de ses propres drivers. C’est une complexité supplémentaire qui n’apporte absolument rien, car comme dit dans mon message précédant, le certificat d’un driver ne pourra être révoqué que par le certificat de son éditeur, pas par l’autorité qui a certifié l’éditeur. C’est ainsi que fonctionne la hiérarchie des certificats et le principe de révocation.
En attendant, tu fais tout un laïus en essayant de montrer que si c’est possible et techniquement faisable, en omettant clairement de contrer les deux arguments qui remettent en cause même l’utilisation des certificats pour cet usage :
#11
C’est déjà Microsoft qui signe les drivers via WHQL. Donc le même Microsoft peut les révoquer.
On ne m’enlèvera pas de l’idée que le mécanisme de signature des drivers, si dès le départ il ne prévoit pas la révocation, c’est plutôt stupide.
#11.1
Un pilote doit être signé avec certificat EV (Extended Validation) pour recevoir le tampon WHQL de Microsoft, et c’est quand même assez contraignant d’en obtenir un, donc non, ce n’est pas possible/facile de faire un certificat par pilote, ni même par famille de pilote (parce que comme cela a déjà été mentionné précédemment, ce qui est bloqué c’est une version particulière connue comme présentant une vulnérabilité)
#12
Raté.
Microsoft peut les signer, mais des éditeurs tiers aussi. Et cela ne concerne que les drivers en mode noyau.
Pour des drivers en mode utilisateur (comme les imprimantes), c’est encore différents.
Encore une fois, le mécanisme de signature des drivers n’est pas fait pour ça. Il est fait pour garantir la provenance et l’authenticité des drivers, pas pour gérer la sécurité (absence de faille) des drivers.
#13
Est-ce qu’on sait comment Microsoft maintient à jour cette liste de pilotes à considérer comme révoqués par Windows (enfin leurs certificats utilisés pour les signer) ?
Ce sont les éditeurs eux-mêmes qui envoient les infos’ à Microsoft et/ou ce dernier qui utilise sa propre veille (threat intelligence pour faire stylé) ?
#14
OK la réponse est dans l’article de Microsoft.