
Критична вразливість CVSS 10.0 у LXD і MicroCloud дозволяє видавати себе за довірених клієнтів
Canonical виправила вразливість CVSS 10.0 у LXD і MicroCloud, яка дозволяє атакувальнику увійти як довірений клієнт без його приватного ключа за наявності мережевого доступу до HTTPS API та відкритого сертифіката клієнта.
Canonical випустила виправлені версії LXD і MicroCloud для критичної вразливості, яка дозволяє атакувальнику увійти як довірений клієнт без приватного ключа цього клієнта. Вразливість, позначена як CVE-2026-112816, має оцінку CVSS 10.0 і потребує мережевого доступу до HTTPS API та відкритого сертифіката довіреного клієнта. Якщо обліковий запис, який підмінюють, має привілеї, атакувальник може отримати root-доступ до хост-машини, повідомила 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.21.8 і 6.9 як зачеплені, кожну до виправленого випуску, що йде далі.
Виправлені версії
Canonical наводить такі виправлені версії snap: LXD 6/stable 6.10.1, LXD 5.21/stable 5.21.9, LXD 5.0/stable 5.0.11, LXD 4.0/stable 4.0.15, MicroCloud 3/stable 3.4.1 і MicroCloud 2/stable 2.1.5. Помилка не почалася в Canonical: проєкт Incus, який розпочався як спільнотний форк LXD, повідомив про неї, а Canonical підтвердила, що вона зачіпає також LXD. Incus виправив ту саму вразливість у версії 7.6.0. Власні архівні пакети Ubuntu для LXD зазначені як не зачеплені або такі, що не постачаються, тому виправлені випуски є snap-пакетами. Немає публічних ознак, що вразливість використовували в атаці. Запис CVE містить оцінку CISA США, датовану 30 жовтня, що вразливість, як відомо, не експлуатували; вона не входить до списку CISA Known Exploited Vulnerabilities, і робочий експлойт не був опублікований.
Що робити
Оновіть LXD і MicroCloud до виправлених версій. У snap-встановленні виконайте sudo snap refresh lxd і sudo snap refresh microcloud. Canonical повідомила, що виправлені точкові випуски LXD на момент її рекомендації ще переходили з канала candidate у stable, тому після оновлення перевірте версію, яку ви фактично маєте, а не припускайте, що виправлення вже надійшло. Рекомендація Canonical не містить тимчасового обхідного рішення для LXD. Оскільки атака потребує мережевого доступу до API, обмеження того, хто може досягти його, знижує ризик до оновлення. Проєкт Incus, який повідомив про ту саму вразливість, сказав, що конфігураційного виправлення немає і що єдиним кроком є обмеження мережевого доступу до слухача. Користувачам Incus слід перейти на 7.6.0, яка виправила цю вразливість разом із 17 іншими проблемами безпеки.
Джерела: The Hacker News
SiTech — веброзробка з підтримкою AI
Створюємо швидкі та сучасні сайти й інтегруємо AI у бізнес-процеси. Маєте проєкт чи запитання? Із задоволенням допоможемо.