Canonical poinformował o krytycznej luce bezpieczeństwa w swoich rozwiązaniach LXD oraz MicroCloud. Błąd otrzymał identyfikator CVE-2026-112816 oraz maksymalną możliwą ocenę ryzyka CVSS 10.0.
Ta nowa podatność w LXD i MicroCloud pozwala atakującemu podszyć się pod dowolnego zaufanego klienta klastra. Co najbardziej zaskakujące, agresor nie musi posiadać klucza prywatnego ofiary. Wystarczy sam certyfikat publiczny, aby przejąć kontrolę nad kontenerami, maszynami wirtualnymi oraz uzyskać uprawnienia root na fizycznym hoście.
Podatność w LXD i MicroCloud – szybkie podsumowanie (TL;DR)
- Identyfikator błędu:
CVE-2026-112816(maksymalna ocena powagi: CVSS 10.0). - Podatne wersje: Canonical LXD (
4.0.14,5.0.10,5.21.8,6.9i starsze w tych gałęziach), MicroCloud (gałęzie2.xoraz3.x), a także fork Incus (wersje starsze niż7.6.0). - Wymagania do ataku: Dostęp sieciowy do interfejsu API HTTPS oraz znajomość publicznego certyfikatu zaufanego klienta.
- Skutki eksploatacji: Całkowite ominięcie uwierzytelniania mTLS, przejęcie tożsamości administratora oraz dostęp
rootdo maszyny gospodarza. - Status zagrożenia: Według agencji CISA luka nie jest jeszcze wykorzystywana w aktywnych atakach (brak publicznego exploita).
Jak działa błąd w mTLS? Wystarczy dokleić cudzy certyfikat
Zarówno LXD, jak i klastry MicroCloud udostępniają zdalnym klientom interfejs API zabezpieczony przez wzajemne uwierzytelnianie TLS (mTLS). W tym modelu klient przedstawia swój certyfikat, a serwer sprawdza, czy dokument znajduje się w lokalnej bazie zaufanych podmiotów (trust store).
Dlaczego ta podatność w LXD i MicroCloud jest tak groźna i prosta w wykorzystaniu? Cały problem wynika z błędnej weryfikacji łańcucha certyfikatów.
1. Zasada działania protokołu TLS
Podczas nawiązywania połączenia TLS klient udowadnia posiadanie klucza prywatnego wyłącznie dla pierwszego certyfikatu w łańcuchu (tzw. certyfikatu liścia – leaf certificate). Pozostałe certyfikaty w łańcuchu klient może dołączyć zupełnie dowolnie.
2. Kardynalny błąd po stronie serwera
Podatny kod LXD oraz MicroCloud sprawdzał każdy certyfikat przesłany w łańcuchu względem swojej bazy zaufanych podmiotów. Jeżeli którykolwiek certyfikat z listy pasował do bazy, serwer natychmiast wpuszczał klienta.
3. Banalny scenariusz ataku
Certyfikaty publiczne z założenia nie są tajne. W rezultacie atakujący może wygenerować własny certyfikat (do którego ma klucz prywatny), a tuż za nim dokleić w łańcuchu publiczny certyfikat administratora. Serwer potwierdzi własność klucza dla pierwszego pliku, ale uprawnienia przyzna na podstawie drugiego certyfikatu. Dzięki temu agresor loguje się jako administrator bez łamania kryptografii.
Kto jest bezpośrednio zagrożony?
Do przeprowadzenia udanego ataku haker potrzebuje dwóch elementów: dostępu sieciowego do portu API HTTPS oraz publicznego certyfikatu zaufanego klienta.
Pojedyncze instalacje LXD
Domyślnie samodzielny serwer LXD nie wystawia interfejsu API do sieci. Nasłuchuje on wyłącznie na lokalnym gnieździe uniksowym (local socket). Dlatego pojedyncze maszyny są podatne tylko wtedy, gdy administrator ręcznie włączył nasłuchiwanie sieciowe parametrem core.https_address.
Klastry MicroCloud oraz projekt Incus
Znacznie gorzej wygląda sytuacja w klastrach MicroCloud, które łączą wiele instancji LXD przez sieć. Canonical ostrzega, że napastnik może przechwycić publiczny certyfikat nowego węzła podczas jego dołączania do klastra. Następnie agresor wykorzysta ten plik, aby zalogować się jako pełnoprawny członek klastra.
Warto dodać, że lukę odkryli i zgłosili twórcy projektu Incus (społecznościowego forka LXD). Błąd występował w obu projektach.
Co robić? Instrukcja łatania i zalecenia dla administratorów
Dla tej luki nie istnieje żadne bezpieczne obejście konfiguracyjne (workaround). Jedynym sposobem zabezpieczenia infrastruktury jest aktualizacja pakietów oraz ścisłe ograniczenie dostępu do API na firewallu.
1. Natychmiast zaktualizuj pakiety Snap
Standardowe pakiety .deb w repozytoriach Ubuntu nie są podatne – problem dotyczy instalacji opartych na paczkach Snap. Zaktualizuj system poniższymi poleceniami:
Bash
sudo snap refresh lxd
sudo snap refresh microcloud
Ważna uwaga dla adminów: Canonical zaznacza, że poprawki dla LXD są stopniowo przenoszone z kanału candidate do stable. Po wykonaniu aktualizacji koniecznie sprawdź poleceniem snap list, czy masz już zainstalowaną bezpieczną wersję:
- LXD (kanał 6/stable): wersja
6.10.1 - LXD (kanał 5.21/stable): wersja
5.21.9 - LXD (kanał 5.0/stable): wersja
5.0.11 - LXD (kanał 4.0/stable): wersja
4.0.15 - MicroCloud (kanał 3/stable): wersja
3.4.1 - MicroCloud (kanał 2/stable): wersja
2.1.5
2. Zaktualizuj środowisko Incus
Jeżeli zamiast LXD używasz projektu Incus, zaktualizuj oprogramowanie do wersji 7.6.0. Wydanie to łata opisywaną lukę CVE-2026-112816 oraz 17 innych błędów bezpieczeństwa.
3. Wytnij dostęp do API na zaporze sieciowej
Dopóki poprawka nie trafi na Twoje serwery, bezwzględnie ogranicz dostęp sieciowy do portu nasłuchiwania HTTPS API. Skonfiguruj reguły nftables, iptables lub zewnętrzny firewall tak, aby do API mogły łączyć się wyłącznie ściśle określone adresy IP administratorów oraz węzłów klastra.
Dodaj komentarz