Критична уязвимост при валидирането на сертификати в LXD и Incus може да позволи на отдалечени атакуващи да заобиколят проверките за вход и да поемат контрол над клъстери и управлявани виртуални машини.
Слабостта засяга HTTPS слушателя за управление, излагайки на риск достъпните Linux системи, без да се изисква парола, откраднат частен ключ или взаимодействие с потребителя. Incus определя уязвимостта като критична с оценка по CVSS от 10.0.
В бюлетина за сигурност на Incus, публикуван на 29 октомври, се посочва, че грешката съществува от първоначалното издание на проекта. Canonical публикува своя свързан запис за LXD, CVE-2026-112816, на 30 октомври. Въпреки че Ubuntu определя среден приоритет на този запис, той описва неавтентикиран път за пълен достъп до клъстери и виртуални машини.
Уязвимост при валидирането на сертификати в LXD и Incus
Проблемът се крие в начина, по който услугата проверява сертификатите, представени по време на HTTPS връзка. TLS ръкостискането доказва, че клиентът притежава частния ключ за първия подаден от него сертификат. Останалите сертификати в тази верига обаче се контролират от клиента и не се проверяват.
След това проверките за автентикация сравняват всеки сертификат в подадената верига с хранилището за доверени сертификати на сървъра. Това създава разминаване между доказването на собственост върху сертификат и приемането на неговата идентичност. Атакуващият може да добави публичната част на доверен сертификат към собствената си верига и да бъде приет за негов собственик, въпреки че не разполага със съответния частен ключ.
Публичните сертификати не са тайна. Сървърите връщат своите сертификати по време на TLS ръкостисканията, което означава, че атакуващият не се нуждае от съществуващ акаунт, за да получи такъв. Според бюлетина представянето на собствения сертификат на сървъра дава достъп до шлюза на базата данни, докато представянето на сертификат на друг член на клъстера предоставя вътрешен достъп до клъстера и изцяло заобикаля оторизацията.
Това се различава от уязвимостите за бягство от контейнер, разгледани в доклада на Cyber Security News за уязвимостта в runc. Вместо да излиза от изолирана работна среда, тази грешка е насочена към доверения слой за управление, който контролира достъпа до средата.
В бюлетина на Incus се посочва, че атакуващите могат да имитират доверени клиентски сертификати, сертификати за метрики или сървърни сертификати, когато разполагат със съответния публичен сертификат. Същата слабост позволява подновяване или изтриване на записи в хранилището за доверени сертификати чрез пътища за самообслужване. Тя засяга и автентикацията за връзката на агента между хостовете и виртуалните машини.
Друга засегната област е скриптлетът за оторизация – скрипт, използван за вземане на решения за достъп. Incus е предавал непроверената верига от сертификати към този скрипт, позволявайки на избрани от атакуващия сертификати да влияят на решенията му. Това засяга и връзки, използващи токени или OpenID Connect, тъй като тези клиенти все пак могат да представят сертификати по време на ръкостискането.
Версии с корекции за сигурност и незабавна защита
Incus посочва версиите преди 7.6.0 като засегнати, а версия 7.6.0 и следващите като такива с инсталирани корекции за сигурност. Известието на Canonical за LXD идентифицира корекции във версии 4.0.15, 5.0.11, 5.21.9 и 6.10.1 за засегнатите клонове на изданията. Администраторите трябва да проверят инсталираната си версия спрямо съответния бюлетин на доставчика.
Докато бъдат приложени обновяванията, Incus съветва да се ограничи достъпът до HTTPS слушателя само до доверени хостове. Няма заобиколно решение, базирано на конфигурация, което да отстранява основната грешка при валидирането. Мрежовите ограничения намаляват излагането на риск, но не заменят инсталирането на корекции за сигурност.
Ръководството за сигурност на Linux контейнери на Cyber Security News предоставя по-широк контекст относно защитата на контейнерни среди. За тази уязвимост незабавният фокус е по-тесен: обновете засегнатите услуги и ограничете кой може да достига до техните интерфейси за управление. Нито един от цитираните бюлетини не съобщава за активна експлоатация, така че излагането на риск не трябва да се бърка с потвърдено компрометиране.