Podatności Incus

Incus przed wersją 7.2.0 zawiera brak kontroli autoryzacji przy kopiowaniu instancji, co pozwala atakującemu znającemu nazwę projektu i instancji, do których nie ma dostępu, na skopiowanie instancji do nowego projektu.

Incus przed wersją 7.2.0 ma brak autoryzacji przy kopiowaniu woluminów niestandardowych. Atakujący znający nazwę projektu, do którego nie ma dostępu, oraz nazwę woluminu w tym projekcie, może skopiować wolumin do nowego projektu. Może to pozwolić na dostęp do sekretów w woluminach, do których nie jest upoważniony.

Incus przed wersją 7.1.0 zawiera podatność na dereferencję wskaźnika null w funkcji `(*backend).CreateInstanceFromBackup`. Uwierzytelniony użytkownik z uprawnieniami do tworzenia instancji może zdalnie wywołać awarię demona Incus, przesyłając spreparowany plik kopii zapasowej, co prowadzi do odmowy usługi dla wszystkich projektów na danym członku klastra.

Incus w wersjach 6.21.0 i niższych umożliwia użytkownikowi z możliwością uruchomienia kontenera z niestandardowym obrazem (np. członkowi grupy 'incus') wykorzystanie przechodzenia po katalogach lub dowiązań symbolicznych w funkcji szablonów do odczytu i zapisu dowolnych plików na hoście, co prowadzi do wykonania dowolnych komend na hoście. Poprawka planowana jest w wersjach 6.0.6 i 6.21.0.

Incus w wersjach 6.20.0 i niższych umożliwia użytkownikowi z możliwością uruchomienia kontenera z niestandardową konfiguracją YAML (np. członkowi grupy 'incus') utworzenie zmiennej środowiskowej zawierającej znaki nowej linii, co może być wykorzystane do dodania dodatkowych elementów konfiguracji w lxc.conf kontenera. Może to pozwolić na dodanie dowolnych haków cyklu życia, prowadząc do wykonania dowolnych komend na hoście. Poprawka planowana jest w wersjach 6.0.6 i 6.21.0.

Incus przed wersją 7.3.0 zawiera podatność, w której złośliwy obraz zawierający dowiązanie symboliczne `metadata.yaml` wskazujące na dowolną ścieżkę hosta pozwala uwierzytelnionemu użytkownikowi Incus na odczyt lub nadpisanie dowolnego pliku na hoście jako root przez API metadanych instancji. Ścieżki `exec-output` i `templates/` zostały załatane wcześniej, ale `metadata.yaml` nie został objęty poprawką i pozostaje podatny.

Incus przed wersją 7.3.0 pozwala nieuprzywilejowanemu użytkownikowi ograniczonemu do projektu (niebędącemu administratorem TLS/RBAC z uprawnieniami `can_create_images` i `can_create_instances`) na wykonanie dowolnego kodu jako root na hoście. Złośliwy obraz zawiera `backup.yaml` jako dowiązanie symboliczne do pliku hosta. Gdy root daemon zapisuje plik kopii zapasowej instancji, podąża za dowiązaniem symbolicznym.

Incus przed wersją 7.3.0 ma podatność, w której podczas kopiowania instancji między projektami sprawdzenie ograniczeń projektu (`AllowInstanceCreation`) jest wykonywane PRZED scaleniem konfiguracji źródłowej instancji z żądaniem. Niebezpieczne klucze konfiguracji (takie jak `security.privileged`, `raw.lxc`, `raw.apparmor`) ze źródłowej instancji są scalane PO przejściu kontroli, omijając wszystkie ograniczenia projektu w projekcie docelowym.

Incus przed wersją 7.3.0 ma podatność, w której podczas migracji instancji do innego członka klastra, nadpisania konfiguracji dostarczone przez użytkownika (w tym klucze krytyczne dla bezpieczeństwa, takie jak `security.privileged` i `raw.lxc`) są stosowane bez egzekwowania jakichkolwiek ograniczeń projektu, co pozwala użytkownikowi z ograniczonego projektu na eskalację do uprzywilejowanego kontenera i ucieczkę do hosta.

Incus przed wersją 7.3.0 ma podatność, w której nieprawidłowa walidacja dostarczonego przez użytkownika `block.create_options` w konfiguracji woluminu magazynu prowadzi do wstrzyknięcia argumentów w konstruowanej linii poleceń tworzenia systemu plików. Pozwala to użytkownikowi z ograniczeniem do projektu na wstrzyknięcie dowolnych argumentów do binarnego wykonywanego jako root.

Incus przed wersją 7.2.0 ma podatność polegającą na dowolnym zapisie pliku w kliencie Incus, gdy złośliwy serwer obrazów zwraca spreparowany nagłówek `Incus-Image-Hash`. Może to prowadzić do wykonania dowolnych poleceń jako root na serwerze.

Incus przed wersją 7.1.0 ma podatność, w której nieprawidłowa walidacja dostarczonego przez użytkownika algorytmu kompresji kopii zapasowej prowadzi do wstrzyknięcia argumentów w konstruowanej linii poleceń. Prowadzi to do dowolnego zapisu pliku na hoście, co może prowadzić do wykonania dowolnych poleceń.

Incus przed wersją 7.1.0 zawiera podatność na przechodzenie po ścieżkach w punkcie końcowym przesyłania danych protokołu S3, co pozwala na tworzenie dowolnych plików na hoście. Może to prowadzić do wykonania dowolnych poleceń. Wersja 7.1.0 naprawia ten problem.

Incus przed wersją 7.2.0 pozwala na użycie specjalnie spreparowanego obrazu lub kopii zapasowej instancji do odczytu lub tworzenia/zapisu dowolnych plików na hoście, co może prowadzić do wykonania dowolnych poleceń. Wersja 7.2.0 zawiera poprawkę.

Incus przed wersją 7.2.0 ignoruje ustawienie `restricted.containers.lowlevel=block` w przypadku migawek instancji, co pozwala na wykonanie dowolnych poleceń na serwerze Incus poprzez nadużycie niskopoziomowych haków, takich jak `raw.lxc` i `raw.qemu`. Wersja 7.2.0 zawiera poprawkę.

Incus przed wersją 7.2.0 ma podatność w parametrze `record-output` punktu końcowego `/instances/$name/exec`, gdzie jeśli katalog `exec-output` jest dowiązaniem symbolicznym, pliki `exec_UUID.stdout` i `exec_UUID.stderr` mogą być zapisywane w dowolnej lokalizacji, a plik `.stdout` może zawierać dowolną treść. Może to być wykorzystane do wykonania dowolnych poleceń. Wersja 7.2.0 zawiera poprawkę.

Incus przed wersją 7.2.0 pozwala na użycie specjalnie spreparowanego obrazu do odczytu lub tworzenia/zapisu dowolnych plików na hoście, co może prowadzić do wykonania dowolnych poleceń. Wersja 7.2.0 naprawia ten problem.

Incus przed wersją 7.3.0 umożliwia obejście ograniczenia `restricted.containers.privilege=isolated` na poziomie projektu. Użytkownik może utworzyć kontener nieizolowany, pomijając klucz `security.idmap.isolated`, co domyślnie ustawia wartość `false` i pozwala na współdzielenie mapy uid/gid hosta. To osłabia izolację między dzierżawcami a hostem.

Incus to menedżer kontenerów systemowych i maszyn wirtualnych. Przed wersją 7.1.0, funkcja `(*backend).CreateCustomVolumeFromBackup` w `internal/server/storage/backend.go` zawiera niechronione wyłuskanie wskaźnika `*time.Time` na polu `ExpiresAt` każdego wpisu snapshotu wolumenu w importowanym backupie wolumenu niestandardowego. Uwierzytelniony użytkownik z uprawnieniem `can_create_storage_volumes` w dowolnym projekcie może doprowadzić do awarii demona `incusd` poprzez przesłanie archiwum backupu, w którym pole `volume_snapshots[*].expires_at` jest nieobecne. Jest to wariant siostrzanego pola GHSA-r7w7-mmxr-47r9 (CVE-2026-40197). Commit `985a1dedf9f3e7ba729c93b654905ed510de25c2` dodał `if s == nil` na początku pętli, ale nie zabezpieczył sąsiedniego wyłuskania `*snapshot.ExpiresAt` 19 linii dalej. Każdy inny konsument `Config.VolumeSnapshots[i].ExpiresAt` w tym samym pliku już zabezpiecza wyłuskanie sprawdzeniem nil — asymetryczne zabezpieczenie jest błędem. Wersja 7.1.0 zawiera zaktualizowaną poprawkę.

Incus to menedżer kontenerów systemowych i maszyn wirtualnych. Przed wersją 7.1.0, funkcja `(*backend).createDependentVolumesFromBackup` w `internal/server/storage/backend.go` zawiera grupę niechronionych wyłuskań wskaźników na polach `VolumeSnapshots[i]`, `Volume` i `Pool` każdego wpisu wolumenu zależnego. Uwierzytelniony użytkownik z uprawnieniem `can_create_instances` w dowolnym projekcie może doprowadzić do awarii demona `incusd` poprzez przesłanie archiwum backupu instancji, w którym blok `dependent_volumes[*]` zawiera wskaźnik nil snapshotu (lub pomija `volume:` / `pool:`). Jest to wariant siostrzanego pola poprawki z 2026-05-04 `d768f81c0a1d985f35ae56219519822b080bf5e3` ("Properly check dependent volumes on import"). Ten commit dodał `if disk == nil` na początku zewnętrznej pętli, ale nie zabezpieczył czterech pól pod-wskaźników, które ciało pętli wyłuskuje bezpośrednio. Wersja 7.1.0 zawiera zaktualizowaną poprawkę.

Incus przed wersją 7.0.0 wysyła żądanie HEAD do adresu URL podanego przez użytkownika przed sprawdzeniem ograniczeń projektu. Uwierzytelniony atakujący może zmusić demona do wykonania ślepych żądań HEAD do dowolnych serwerów, ujawniając metadane serwera (architektury, wersję) i umożliwiając skanowanie wewnętrznych usług.