Osegi
Sicherheit·2 Min. Lesezeit

Canonical schließt Lücke mit Höchstwertung in LXD und MicroCloud

Canonical hat CVE-2026-112816 behoben: Die Lücke in LXD und MicroCloud erreicht 10,0 Punkte und erlaubt es, sich ohne privaten Schlüssel als vertrauenswürdiger Client auszugeben.

Server racks in a data center with a digital padlock overlay symbolizing a critical container management vulnerability.
Bild: Хабр
SUMODialoediviewergiftdetect

Canonical hat am 28. Oktober die Behebung der Schwachstelle CVE-2026-112816 im Container- und VM-Manager LXD sowie in der Private-Cloud-Plattform MicroCloud bekannt gegeben. Die Wissensdatenbank von CodeScoring stuft sie als kritisch ein, mit der Höchstwertung von 10,0 nach CVSS 4.0. Angreifer können sich damit als vertrauenswürdiger Client ausgeben, ohne dessen privaten Schlüssel zu besitzen.

So funktioniert der Angriff

Der Fehler steckt in der Prüfung der Zertifikatskette des Clients. Beim TLS-Handshake weist der Client den Besitz des privaten Schlüssels nur für das erste Zertifikat der Kette nach. Der Server verglich jedoch alle gesendeten Zertifikate mit seinem Speicher vertrauenswürdiger Clients. Ein Angreifer konnte daher sein eigenes Zertifikat an erste Stelle setzen, das öffentliche Zertifikat eines vertrauenswürdigen Clients anhängen und dessen Rechte erhalten.

Voraussetzung ist Zugriff auf die HTTPS-Verwaltungs-API und das öffentliche Zertifikat des Ziel-Clients. Bei MicroCloud gibt es ein weiteres Szenario: Ein Angreifer fängt das öffentliche Zertifikat eines Knotens ab, während dieser einem Cluster beitritt, und gibt sich anschließend als dieser Knoten aus.

Auf das Problem wies das Projekt Incus hin, ein offener LXD-Fork. Das Zertifikat des Servers lässt sich bei einer TLS-Verbindung abrufen; fügt man es der eigenen Kette hinzu, erhält man Zugriff auf das Datenbank-Gateway. Das Zertifikat eines anderen Knotens öffnet den internen Clusterzugang. Incus behob den Fehler in Version 7.6.0, frühere Versionen gelten als verwundbar. Laut CodeScoring existierte die Lücke in Incus seit dem ersten Release; über denselben Umweg ließen sich zudem fremde Einträge im Zertifikatsspeicher verlängern oder löschen.

Was Administratoren tun sollten

Standardmäßig arbeitet LXD über einen lokalen Unix-Socket und nimmt keine Netzwerkverbindungen an. Der Netzwerkzugriff wird über den Parameter core.https_address aktiviert. Zuerst sollte daher geprüft werden, ob die Verwaltungsschnittstelle aus einem nicht vertrauenswürdigen Netz erreichbar ist.

Die korrigierten Snap-Builds stammen vom 29. Oktober: für LXD 6.10.1, 5.21.9, 5.0.11 und 4.0.15, für MicroCloud 3.4.1 und 2.1.5. Canonical empfiehlt sudo snap refresh lxd und sudo snap refresh microcloud. Da die Fixes schrittweise ausgerollt werden, sollte die installierte Version nach dem Update mit der Liste des eigenen Kanals abgeglichen werden.

Bis zum Patch sollte der API-Zugriff auf vertrauenswürdige Hosts beschränkt werden. Die Incus-Entwickler betonen, dass es keine Einstellung gibt, die den Fehler ohne Update beseitigt. LXD, MicroCloud und Incus gehören zudem in das Inventar der Infrastruktursoftware auf Hosts mit Containern und virtuellen Maschinen.

Apps, die sich lohnen

SUMO: das Zahlenrätsel

Tippe die richtigen Felder, addiere, triff das Ziel. Leicht zu lernen, schwer zu meistern. Kostenlos, für jedes Alter.

Schlagwörter:canonicallxdmicrocloudincuscve-2026-112816vulnerability

Mehr von diesem Tag

Alle anzeigen →

Mehr aus: Sicherheit

Alle anzeigen →