LXD и MicroCloud от Canonical и форк Incus управляют системными контейнерами и виртуальными машинами через HTTPS-API. Модель аутентификации похожа на SSH: клиент приносит самоподписанный сертификат, администратор добавляет его в хранилище доверия, дальше клиент считается опознанным.
Проблема в том, что TLS-рукопожатие доказывает владение ключом только для первого сертификата в цепочке. Остальные сертификаты клиент присылает сам, и никто не проверяет, есть ли у него их ключи. LXD и Incus сравнивали с хранилищем доверия все сертификаты из присланной цепочки. Достаточно взять свою пару ключей, поставить собственный сертификат первым, а следом приложить открытый сертификат доверенного клиента — и приложение решит, что подключился именно он.
Чем это опасно
Открытый сертификат секретом не является. Серверные сертификаты отдаются в каждом TLS-рукопожатии, клиентские можно прочитать через API сертификатов или подсмотреть, когда клиент подключается к подконтрольному серверу. В MicroCloud сертификат участника виден при формировании кластера.
Если подставить сертификат привилегированного клиента, атакующий получает полный доступ к API, а при удачном раскладе — root на хосте и управление виртуальными машинами. Для тех, кто держит на LXD песочницы для агентов, GPU-ВМ или изолированные сборки, это по сути учётные данные гипервизора.
Статус и исправления
Canonical выпустила исправления 28 октября, Incus — 30 октября вместе с версией 7.6.0. Исправлены LXD 6.10.1, 5.21.9, 5.0.11 и 4.0.15, MicroCloud 2.1.5 и 3.4.1. Настройки, которая закрыла бы дыру, нет: единственная временная мера — не пускать к HTTPS-порту никого лишнего. В CISA KEV уязвимость пока не входит, эксплуатацию вендоры не подтверждали, но публичный агрегатор уже проиндексировал репозиторий, который выдают за proof of concept.
Canonical’s LXD and MicroCloud and the Incus fork manage system containers and virtual machines through an HTTPS API. Authentication resembles SSH: the client brings a self-signed certificate, an administrator adds it to the trust store, and from then on the client is recognised.
The problem is that the TLS handshake proves possession of the key only for the first certificate in the chain. The rest are supplied by the client, and nothing proves it holds their keys. LXD and Incus compared every certificate in the presented chain against the trust store. An attacker can generate their own key pair, put their own certificate first, append the public certificate of a trusted client — and the application treats the session as that client.
Why it matters
A public certificate is not a secret. Server certificates are returned in every handshake; trusted client certificates can be read through the certificates API, or observed when a client connects to an attacker-controlled remote. In MicroCloud, a joining member’s certificate is visible during cluster formation.
Impersonating a privileged client gives full API access and, potentially, root on the host plus control over the VMs. For anyone running agent sandboxes, GPU VMs or isolated builds on LXD, that is effectively a hypervisor credential.
Fixes and status
Canonical shipped fixes on 28 October, Incus on 30 October alongside 7.6.0. Fixed versions are LXD 6.10.1, 5.21.9, 5.0.11 and 4.0.15, and MicroCloud 2.1.5 and 3.4.1. There is no configuration workaround; the only interim measure is to limit who can reach the HTTPS listener. The flaw is not in CISA KEV and neither vendor has confirmed exploitation, but a public exploit aggregator has already indexed a repository presented as a proof of concept.