A Canonical LXD és MicroCloud termékeiben talált kritikus hiba lehetővé teszi, hogy egy támadó egy megbízható kliens nevében jelentkezzen be anélkül, hogy birtokolná annak privát kulcsát. Ehhez elég, ha hálózaton keresztül eléri a HTTPS API-t, és megszerzi a megbízható kliens publikus tanúsítványát.
Ha sikerül bejutnia, a támadó úgy viselkedhet, mintha az adott kliens lenne, hozzáfér a clusterhez és a virtuális gépekhez. Ha a megszemélyesített fiók privilégizált, a támadó „root hozzáférést szerezhet a host géphez” – közölte a Canonical.
A hibát CVE-2026-112816 azonosítóval tartják nyilván, a CVSS pontszáma a maximális 10,0. A Canonical kiadta a javított verziókat mindkét termékhez.
Hogyan működik a hiba
LXD és MicroCloud esetén a távoli kliensek mutual TLS-en keresztül érik el az API-kat. Ilyenkor a kliens tanúsítvánnyal igazolja a saját kilétét. A szerver akkor tekint egy klienst megbízhatónak, ha a tanúsítványa szerepel a szerver trust store-jában, vagyis abban a listában, amelynek tagjait a szerver elfogadja.
A hiba abban volt, ahogyan a szerver ellenőrizte a tanúsítványt. A szerver minden, a kliens által küldött tanúsítványt összevetett a trust store tartalmával, miközben a TLS kapcsolat valójában csak azt bizonyítja, hogy a kliens birtokolja a lánc első, úgynevezett leaf tanúsítványhoz tartozó privát kulcsot. A lánc többi elemét a kliens tetszőlegesen csatolhatja.
Egy támadó tehát foghat egy megbízható kliens publikus tanúsítványát – ami nem titok –, hozzácsatolhatja a saját tanúsítványa mögé a láncban, és a szerver így elfogadja őt úgy, mintha az a megbízható kliens lenne.
Kiket érint
A hiba kihasználásához két feltételnek kell teljesülnie: a támadónak el kell érnie hálózaton keresztül a HTTPS API-t, és meg kell szereznie egy olyan kliens publikus tanúsítványát, amelyet a szerver már megbízhatónak tekint.
Egy önálló LXD szerver alapértelmezés szerint nem teszi ki ezt az API-t a hálózatra. Ilyenkor csak egy helyi socketen figyel, amíg egy rendszergazda be nem kapcsolja a hálózati API-t a core.https_address beállítással.
A MicroCloud, amely több LXD-t futtató gépet fog össze egy clusterbe, különösen sérülékeny pontot jelent. A Canonical szerint ha egy támadó el tudja kapni egy cluster-tag publikus tanúsítványát, miközben az csatlakozik a clusterhez, akkor később be tud jelentkezni annak a tagnak a nevében.
A CVE bejegyzés szerint az LXD 4.0.14, 5.0.10, 5.21.8 és 6.9 verziók érintettek, még a következő javított kiadás előtt. A Canonical a következő javított Snap verziókat sorolja fel:
|
Termék |
Snap csatorna |
Javított verzió |
|---|---|---|
|
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 |
A hiba nem a Canonicalnál bukkant fel először. Az Incus projekt, amely eredetileg az LXD közösségi forkjaként indult, jelentette a problémát, a Canonical pedig megerősítette, hogy az LXD-t is érinti. Az Incus ugyanazt a sebezhetőséget a 7.6.0 verzióban javította.
Ubuntu saját LXD csomagjai az archívumban nem érintettként vagy nem szállítottként szerepelnek, így a javított kiadások a snap csomagok.
Jelenleg nincs nyilvános jel arra, hogy a hibát támadásban kihasználták volna. A CVE bejegyzésben szerepel az amerikai CISA október 30-i értékelése, amely szerint a sebezhetőség kihasználása nem ismert; nem szerepel a CISA ismert, kihasznált sebezhetőségeket listázó jegyzékében, és nem jelent meg működő exploit sem.
Mit tegyünk
Frissítse az LXD-t és a MicroCloudot a javított verziókra. Snap rendszeren futtassa a sudo Snap refresh lxd és a sudo Snap refresh microcloud parancsokat.
A Canonical szerint a javított LXD pontkiadások a figyelmeztetés kiadásakor még úton voltak a candidate csatornáról a stable csatornára, ezért frissítés után mindenképp ellenőrizze a ténylegesen telepített verziót, és ne feltételezze automatikusan, hogy a javítás már megérkezett.
A Canonical közleménye nem ad ideiglenes kerülőmegoldást LXD-hez. Mivel a támadáshoz hálózati hozzáférés kell az API-hoz, a hozzáférők körének szűkítése csökkenti a kockázatot a frissítésig. Az Incus projekt, amely ugyanerről a hibáról számolt be, azt írja, nincs olyan konfigurációs javítás, amely önmagában megoldaná a problémát, az egyetlen lépés a hálózati hozzáférés korlátozása a listenerhez.
Az Incus felhasználók frissítsenek a 7.6.0 verzióra, amely ezzel a hibával együtt további 17 biztonsági problémát is javít.

