Qubes : le badge dit « cette clé seulement », le proxy CTAP ne lit pas l'étiquette

On te tend un badge à l'entrée du couloir. Dessus, une étiquette : cette clé-là, pas les autres. La porte, derrière, lit le badge assez pour savoir que tu as le droit d'entrer dans le service. Elle ne lit pas le type de demande que tu glisses dans la fente. Tu peux montrer le badge « renseignements » et envoyer une demande d'authentification. Le règlement, lui, est affiché correctement. C'est le lecteur de la porte qui ne fait pas le travail que le règlement décrit.

Le 8 octobre 2026, l'équipe Qubes publie le QSB-120. Deux failles dans le proxy CTAP. CTAP, c'est le protocole entre une clé d'authentification, au bout de l'USB, et la machine. Le proxy de Qubes sert à utiliser cette clé dans un qube sans lui donner toute la pile USB, sur le même principe que les proxys clavier et souris. Le bulletin énumère les noms qui traînent autour : U2F, CTAP1, CTAP2, FIDO2, WebAuthn, passkeys. Quatre services qrexec portent les requêtes : ctap.ClientPin, ctap.GetInfo, u2f.Authenticate, u2f.Register. On peut en plus limiter u2f.Authenticate à des identifiants précis, en n'autorisant que certains arguments.

Deux trous, pas le même lot

La première faille : les requêtes CTAP sont censées correspondre au type de service demandé, et le proxy ne le fait pas respecter. Un qube autorisé à n'importe lequel de ces services peut envoyer n'importe quel type de requête. L'exemple du bulletin : la politique ne te laisse que ctap.GetInfo, et tu envoies quand même une authentification. Dans une configuration réaliste, écrit le texte, filtrer l'accès à des identifiants précis par les arguments ne sert plus à rien, puisqu'on peut passer l'authentification par un autre service autorisé. Cette faille touche toutes les versions de CTAP.

La seconde : quand la politique limite un qube à des arguments précis, u2f.Authenticate accepte quand même plusieurs assertions, pourvu que l'une d'elles corresponde à l'argument permis. Le qube qui ne devait toucher que certaines clés sur l'appareil peut donc utiliser n'importe laquelle, pour des requêtes d'assertion CTAP2. Pas CTAP1. Le bulletin sépare les deux. Je ne colle pas la seconde faille sur l'ancienne version du protocole.

Qui est concerné tient en trois phrases, et la troisième est la plus étroite. Seulement les gens qui utilisent le proxy CTAP, sur une version de Qubes supportée. Qui ne s'en sert pas n'est pas concerné. En pratique, seulement les systèmes dont les politiques RPC restreignent un qube à un sous-ensemble des identifiants de la clé. Sinon, le qube a déjà, volontairement, accès à tous. Les failles sont arrivées avec qubes-ctap 2.0.0. Les versions plus anciennes du paquet, qui s'appelait qubes-u2f, ne sont pas touchées. Le bulletin ne liste pas 2.0.1, 2.0.2, ni les numéros d'après. Il donne le début, et le paquet qui corrige.

La discussion remet la faute au bon endroit. Les politiques RPC, elles, sont correctement appliquées. Ce n'est pas une faille de qrexec. C'est l'implémentation des services dans le proxy qui casse le sens que ces politiques étaient censées avoir. Le badge est imprimé juste. Le lecteur déforme la consigne.

La phrase du haut, et celle du redémarrage

Tout en haut, la section « User action » tient en deux lignes. Continuer à mettre à jour normalement, pour recevoir les correctifs décrits plus bas. Aucune autre action n'est requise en réponse à ce QSB.

Plus bas, la section « Patching » décrit le paquet. Pour Qubes 4.3, dans le template des qubes USB : qubes-ctap 2.0.8. Le paquet passe du dépôt security-testing au dépôt stable dans les deux semaines qui suivent, après les essais de la communauté. Une fois disponible, on l'installe par l'outil de mise à jour, ou l'équivalent en ligne de commande. Et la phrase d'après : pour que la mise à jour prenne effet, tous les qubes USB doivent être redémarrés, après que leurs templates ont été mis à jour et éteints.

Je pose les deux phrases l'une à côté de l'autre, sans les recoudre. Le haut dit qu'il n'y a pas d'autre geste que la mise à jour habituelle. Le bas décrit un paquet, un délai de deux semaines hors du dépôt stable, et un redémarrage des qubes USB une fois le template à jour et arrêté. Le bulletin ne dit pas que le redémarrage « ne compte pas » comme une action. Il l'écrit dans une autre section. Si tu t'arrêtes à la section du haut, tu n'as pas lu la condition pour que le correctif soit en service.

La ligne de paquet ne nomme que 4.3. La phrase « versions supportées », plus haut, ne donne pas la liste. Je ne fabrique pas un paquet pour une autre branche, et je ne déclare pas une autre branche hors de cause.

Les crédits sont séparés, comme les failles. La seconde a été trouvée par Giulio Berra, de la Freedom of the Press Foundation. La première a été trouvée en interne par Piotr Bartman-Szwarc, en relisant ce signalement. L'annonce porte deux signatures PGP, Marek Marczykowski-Górecki et Simon Gaiser, et une procédure pour les vérifier. Je ne l'ai pas lancée. Le bulletin ne donne pas de CVE. Je n'en ajoute pas. Il ne dit pas que quelqu'un s'en sert déjà dehors.

Le site web n'est pas le qube

Le logiciel qui parle à la clé, en général un navigateur, doit limiter ce qu'un site peut demander. L'exemple du bulletin : sur https://example.org, le navigateur ne doit laisser ce site demander une authentification que pour https://example.org. Donc, en l'absence d'une autre faille exploitable dans le navigateur, un site malveillant ne peut exploiter ni l'une ni l'autre de ces failles.

Le proxy a une deuxième ambition, écrite juste après. Rendre les clés utilisables, oui. Et aussi borner ce qu'un qube peut atteindre sur la clé, même si le qube est compromis : pas les identifiants qu'on ne lui a pas donnés. C'est cette deuxième protection que le QSB dit touchée. Le site web et le qube compromis ne sont pas le même attaquant. Le bulletin écarte le premier sous condition. Il ne raconte pas que le second est théorique.

✍️ À toi : si tu as vraiment une politique qui limite une clé à un qube, et si tes qubes USB ont été redémarrés après le 2.0.8, template éteint compris. Le bulletin décrit le badge. Ta politique, elle, est dans ton fichier.

Le badge peut dire « cette clé seulement ». La porte, jusqu'au 2.0.8, ne vérifie pas que la demande correspond au service, et elle laisse passer un lot CTAP2 dès qu'une assertion du lot est autorisée. La politique qrexec, elle, n'est pas le trou. Le trou est dans le proxy qui était censé lui donner un sens. Et le correctif n'est pas seulement un numéro de paquet : le bulletin demande que les qubes USB repartent, une section plus bas que la phrase qui disait qu'il n'y avait rien d'autre à faire.