Технологии, деньги и рынки — первымиНаписать в редакциюСтудия Dilami LabDilami Lab

Canonical исправила уязвимость CVE-2026-112816 в LXD и MicroCloud с максимальным баллом CVSS 10.0

Canonical исправила в LXD и MicroCloud критическую уязвимость CVE-2026-112816 с максимальным баллом CVSS 10.0. Ошибка позволяет войти в систему от имени доверенного клиента без его закрытого ключа, а при привилегированной учётной записи, по словам Canonical, даёт root-доступ к хосту.

Canonical исправила уязвимость CVE-2026-112816 в LXD и MicroCloud с максимальным баллом CVSS 10.0
Иллюстрация: thehackernews.com

Главное в цифрах

  • Идентификатор уязвимости: CVE-2026-112816
  • Оценка CVSS: 10.0
  • Уязвимые версии LXD: 4.0.14, 5.0.10, 5.21.8, 6.9
  • Исправление Incus: версия 7.6.0

Уязвимость позволяет подключиться к HTTPS API под видом клиента, которому сервер уже доверяет. Для атаки нужны два условия: сетевой доступ к API и открытый сертификат доверенного клиента. Сертификат не является секретом, поэтому его получение затруднено лишь частично. После входа атакующий действует от имени этого клиента и получает доступ к кластеру и его виртуальным машинам.

Уязвимость сообщил проект Incus, форк LXD. Canonical подтвердила, что ошибка затрагивает и LXD. Incus исправил её в версии 7.6.0.

В чём ошибка

LXD и MicroCloud работают с удалёнными клиентами через взаимную TLS-аутентификацию: клиент предъявляет сертификат, подтверждающий его личность. Клиент считается доверенным, если его сертификат есть в хранилище доверия сервера.

Ошибка была в проверке сертификатов. Сервер сверял с хранилищем доверия каждый сертификат из цепочки, которую прислал клиент. Однако TLS подтверждает владение закрытым ключом только для первого сертификата в цепочке, листового. Остальные звенья клиент может прикрепить произвольно. Атакующий брал открытый сертификат доверенного клиента, добавлял его за своим сертификатом, и сервер принимал его как этого клиента.

Отдельное слабое место есть у MicroCloud, который объединяет несколько машин с LXD в один кластер. По словам Canonical, атакующий, который перехватит открытый сертификат участника при его подключении к кластеру, сможет войти от имени этого участника.

Стандартная установка LXD не открывает API по сети: он слушает только локальный сокет, пока администратор не включит сетевой API параметром core.https_address.

Затронутые версии и обновление

По записи CVE уязвимыми считаются LXD 4.0.14, 5.0.10, 5.21.8 и 6.9, а также более ранние версии каждой ветки. Пакеты LXD в архиве Ubuntu помечены как не затронутые или не поставляемые, поэтому исправления выходят в виде snap-пакетов.

Администраторам следует выполнить команды sudo snap refresh lxd и sudo snap refresh microcloud. Canonical предупреждает, что на момент публикации рекомендации исправленные версии LXD ещё выкатывались из канала candidate в stable, поэтому после обновления стоит проверить фактическую версию, а не считать, что исправление уже установлено.

Временного обходного пути для LXD в рекомендации Canonical нет. Поскольку атака требует сетевого доступа к API, до обновления снизить риск можно ограничением того, кто может подключаться к нему. В Incus заявили, что исправления через конфигурацию нет и нужно ограничить сетевой доступ к слушателю. Пользователям Incus следует перейти на версию 7.6.0, которая закрывает эту уязвимость и ещё 17 проблем безопасности.

Признаки атак

Публичных признаков использования уязвимости в атаках нет. В записи CVE стоит оценка CISA от 30 октября о том, что эксплуатация не известна. Уязвимости нет в списке CISA Known Exploited Vulnerabilities, и рабочий эксплойт не опубликован.

Нашли ошибку или есть что добавить? Напишите редакции
Источник: thehackernews.com
0 новых новостей