Критическая уязвимость в LXD и MicroCloud от Canonical позволяла злоумышленнику войти в систему как доверенный клиент, не владея его закрытым ключом. Для этого атакующему требовался сетевой доступ к HTTPS API и публичный сертификат доверенного клиента. Получив доступ, злоумышленник мог действовать от имени этого клиента, получая доступ к кластеру и его виртуальным машинам. Если учетная запись была привилегированной, атакующий мог получить «root-доступ к хост-машине», как заявила Canonical.
Уязвимость, отслеживаемая как CVE-2026-112816, имеет максимальный балл CVSS 10.0. Canonical выпустила исправленные версии обоих продуктов.
LXD и MicroCloud позволяют удаленным клиентам получать доступ к своим API через взаимный TLS, при котором клиент предъявляет сертификат для подтверждения своей личности. Клиент считается доверенным, если его сертификат находится в хранилище доверия сервера — списке идентификаторов, которые сервер принимает.
Проблема заключалась в том, как сервер проверял этот сертификат. Он сравнивал каждый сертификат, отправленный клиентом, с хранилищем доверия, но TLS-соединение подтверждает владение закрытым ключом только для первого сертификата в цепочке — конечного. Остальная часть цепочки могла быть любой, которую клиент решил прикрепить. Таким образом, злоумышленник мог взять публичный сертификат доверенного клиента (который не является секретным), прикрепить его к цепочке после своего собственного, и сервер принимал бы его как этого клиента.
Для использования уязвимости требовались два условия: сетевой доступ к HTTPS API и публичный сертификат клиента, которому сервер уже доверяет.
Автономный сервер LXD по умолчанию не предоставляет этот API. Он слушает только локальный сокет, если администратор не включает сетевой API с помощью настройки `core.https_address`.
MicroCloud, объединяющий несколько машин с LXD в один кластер, имеет специфическую уязвимость. Canonical сообщила, что злоумышленник, который может перехватить публичный сертификат участника при его входе в кластер, затем может войти в систему как этот участник.
В записи CVE указаны LXD версий 4.0.14, 5.0.10, 5.2.18 и 6.9 как затронутые, каждая до выпуска исправленной версии, которая следует за ними. Canonical перечисляет следующие исправленные версии snap:
Ошибка возникла не в Canonical. Проект Incus, который начинался как форк LXD, сообщил о ней, и Canonical подтвердила, что она затронула и LXD. Incus исправил ту же уязвимость в версии 7.6.0.
Архивные пакеты LXD в Ubuntu указаны как не затронутые или не поставляемые, поэтому исправленные версии — это snap-пакеты.
Публичных свидетельств использования уязвимости в атаках нет. В записи CVE указана оценка CISA США от 30 октября, согласно которой об эксплуатации уязвимости неизвестно; она не входит в список известных уязвимостей CISA, и ни один рабочий эксплойт не был опубликован.
Обновите LXD и MicroCloud до исправленных версий. При установке через snap выполните команды `sudo snap refresh lxd` и `sudo snap refresh microcloud`.
Canonical сообщила, что исправленные релизы LXD все еще переходили из канала candidate в stable на момент публикации консультативного уведомления, поэтому проверьте версию, которая у вас есть после обновления, а не предполагайте, что исправление доставлено.
Консультативное уведомление Canonical не содержит временных обходных путей для LXD. Поскольку атака требует сетевого доступа к API, ограничение доступа к нему снижает риск до обновления. Проект Incus, сообщивший о той же уязвимости, заявил, что конфигурационного исправления нет, и единственным шагом является ограничение сетевого доступа к слушателю.
Пользователям Incus следует перейти на версию 7.6.0, которая исправила эту уязвимость вместе с 17 другими проблемами безопасности.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Swati Khandelwal
