LXD : un certificat public suffisait pour emprunter une identité de confiance

Avis Canonical du 28 octobre 2026, détail technique publié le 4 novembre. La vulnérabilité CVE-2026-112816 tient à une confusion très précise : LXD vérifiait qu’un certificat de confiance figurait quelque part dans la chaîne envoyée par le client, alors que la négociation TLS ne prouvait la possession de la clé privée que pour le premier certificat. Un attaquant capable de joindre l’API HTTPS pouvait donc présenter sa propre clé et ajouter la copie publique d’un certificat de confiance. Canonical classe le problème à 10,0 et indique qu’une identité de membre de cluster pouvait ainsi être usurpée.

Ce que mTLS est censé prouver

Dans une connexion TLS avec authentification du client, celui-ci présente un certificat et démontre qu’il détient la clé privée associée. Le serveur peut ensuite demander si ce certificat prouvé appartient à sa liste de confiance, puis déterminer les droits correspondant à cette identité. Une chaîne peut contenir d’autres certificats pour expliquer une relation de signature. Leur présence dans le message ne prouve pas que le client possède toutes les clés privées associées. Ils sont, par définition, des données publiques que le pair peut assembler et transmettre.

Le contrôle vulnérable franchissait la frontière au mauvais endroit. Le listener HTTPS demandait un certificat client sans le vérifier pendant le handshake ; l’application parcourait ensuite tous les certificats reçus et comparait chacun au magasin de confiance. Le handshake attestait de la clé du premier élément, mais l’application pouvait retenir un élément suivant comme identité. Le raisonnement correct est : « la clé du certificat feuille a été prouvée, et ce certificat feuille est autorisé ». Le raisonnement fautif était : « une entrée autorisée figure dans la liste envoyée par le client ».

On peut représenter l’erreur sans fournir de charge utile : chaîne = [certificat de l'attaquant, certificat public du membre autorisé]. La preuve cryptographique porte sur le premier terme ; le test d’autorisation pouvait réussir sur le second. Copier le certificat public d’autrui n’exige pas de connaître sa clé privée. Le correctif décrit par Canonical limite précisément la comparaison avec le magasin de confiance au premier certificat.

Pourquoi le périmètre dépasse un simple compte API

LXD administre conteneurs, machines virtuelles et ressources du système hôte. Une identité API de confiance peut donc disposer de privilèges étendus ; Canonical indique qu’en fonction de l’identité usurpée, l’attaquant peut atteindre l’accès root sur l’hôte. Dans un cluster, un certificat serveur d’un autre membre donne accès à des fonctions internes ; le bulletin précise même que le certificat du serveur est exposé lors des négociations TLS et qu’il peut servir à atteindre la passerelle de base de données. MicroCloud connaît une variante de la même confusion lors de l’ajout d’un membre au cluster.

L’advisory énumère les chemins touchés : API principale, métriques, passerelles de cluster et de base de données, renouvellement et suppression des certificats, enrôlement par jeton et connexion de l’agent des machines virtuelles. Il ne faut donc pas réduire la faille à « quelqu’un peut se connecter à l’interface Web ». La même hypothèse d’identité circulait entre plusieurs opérations privilégiées.

L’exposition a toutefois une précondition nette : l’attaquant doit pouvoir joindre le listener HTTPS de LXD ou MicroCloud. Un service inaccessible depuis son réseau n’est pas attaquable par cette voie. Le communiqué Canonical recommande la mise à jour et précise qu’aucun simple paramètre ne corrige la validation ; restreindre l’accès réseau est la mesure temporaire documentée.

Comment retrouver une erreur de ce type

Un audit autorisé peut commencer par écrire l’invariant de sécurité : l’identité autorisée doit être le certificat dont la clé privée a été prouvée par la connexion. Il faut ensuite suivre la donnée entre l’objet TLS du serveur, le tableau de certificats transmis et chaque fonction d’autorisation. Le test négatif décisif est conceptuel : un client possédant sa propre clé, mais seulement la partie publique du certificat autorisé, ne doit jamais obtenir les droits de ce dernier. Ce test couvre les opérations qui consultent la confiance directement, mais aussi celles qui invoquent des helpers de cluster, de métriques ou de renouvellement.

Une revue de correctif serait particulièrement instructive ici : le changement d’un parcours de la chaîne entière vers le certificat feuille répare la confusion de propriété. L’examen doit aussi vérifier qu’aucun autre appel ne réutilise la liste non vérifiée comme preuve d’identité. Cette méthode décrit comment rechercher la classe de bug ; le bulletin Canonical attribue le signalement au projet Incus, sans publier dans cet avis un journal complet de découverte.

Décider et vérifier

Canonical annonce les versions corrigées LXD 6.10.1, 5.21.9, 5.0.11 et 4.0.15, ainsi que MicroCloud 3.4.1 et 2.1.5 dans leurs canaux snap. L’inventaire doit comparer la version réellement installée au canal employé, contrôler les hôtes dont l’API HTTPS est joignable, puis examiner la confiance et les actions administratives pendant la fenêtre d’exposition. Si une compromission est suspectée, changer un seul certificat ne démontre pas que les fonctions internes ou l’hôte sont sains ; l’analyse doit partir des privilèges de l’identité potentiellement usurpée.

Cette faille enseigne une règle générale : une chaîne de certificats est un ensemble de données fourni par le pair ; la preuve de possession de clé doit être attachée à l’identité que l’application autorise, et jamais déduite de la simple présence d’un certificat public dans cet ensemble.

Sources principales : advisory LXD, communiqué Canonical.