Podatności Contrast

W wersjach Contrast przed 1.18.0 obsługa ACPI/AML w jądrze gościa jest podatna na atak wstrzyknięcia kodu AML ("BadAML"). Złośliwy host może dostarczyć tablicę ACPI z dowolnym kodem bajtowym AML, który jest wykonywany przez interpreter jądra gościa z dostępem do całej pamięci gościa, w tym stron prywatnych. Dotyczy to platform AMD SEV-SNP (Metal-QEMU-SNP i Metal-QEMU-SNP-GPU); Metal-QEMU-TDX nie jest podatny.

W wersjach Contrast przed 1.19.1 polityki agenta Kata generowane przez CLI Contrast miały błąd w weryfikacji CopyFile, który pozwalał na dowolne zapisy do głównego systemu plików gościa. Złośliwy proces na niezaufanym hoście mogący połączyć się z VSOCK agenta Kata mógł nadpisać krytyczne pliki lub wymusić ujawnienie danych, co w praktyce oznacza pełne przejęcie gościa.

Contrast (Edgeless Systems) do wersji 1.20.0 wykonuje niezakotwiczone dopasowanie sufiksów przy wyborze konfiguracji per-rejestr w imagepuller. Config.registryFor usuwa pojedynczą kropkę na końcu, a następnie używa strings.HasSuffix(hostname, fqdn) bez wymagania granicy etykiety DNS, więc wpis rejestru taki jak [registries."ghcr.io."] jest również stosowany do każdego hosta, którego nazwa kończy się tym ciągiem bajtów, w tym do domen zarejestrowanych przez atakującego, takich jak evilghcr.io. Gdy obraz lub warstwa jest pobierana z takiej domeny, imagepuller wysyła skonfigurowany nagłówek Authorization (basic auth, token rejestru lub token tożsamości), ufa skonfigurowanemu pakietowi CA, podąża za skonfigurowanym mirror i honoruje insecure-skip-verify (wyłączając weryfikację TLS) dla tego hosta.

Contrast do wersji 1.20.0 zawiera podatność na panikę w funkcji ciphertextContainer.UnmarshalJSON punktu końcowego transit-engine, która nie sprawdza długości odszyfrowanego tekstu przed wycięciem. Uwierzytelnione obciążenie z ważnym certyfikatem mesh może wywołać panikę w czasie wykonywania, przesyłając krótki base64-encoded ciphertext, powodując spam w logach i błędy żądań bez awarii procesu.

Contrast przed 1.16.0 jest podatny na ataki typu relay na zdalną atestację. Contrast akceptował każde poprawnie zweryfikowane raport atestacji TEE z oczekiwanymi poziomami poprawek i pomiarami oprogramowania, niezależnie od tego, która maszyna go wygenerowała, przez co atestacja nie była powiązana z konkretnym, fizycznie zaufanym sprzętem. Atakujący mogący przechwycić ruch sieciowy i sfałszować raporty może podszyć się pod Coordinator lub workload Contrast, obchodząc weryfikację tożsamości w aTLS.

Contrast (edgelesssys/contrast) w wersjach od 1.14.0 przed 1.23.1 generuje polityki runtime, które nie wykrywają wszystkich podmian obrazów kontenerów. Błędny rebase podczas aktualizacji Kata Containers wprowadził regułę 'allow_storage' akceptującą wpisy storage używające sterownika 'image_guest_pull' bez weryfikacji digestu obrazu. Atakujący z dostępem do API agenta Kata może podmienić obraz kontenera na ładunek exploitacyjny, jeśli spełnia pozostałe reguły polityki.

Contrast w wersjach przed 1.4.1 — odzyskujący Coordinator nie weryfikuje ziarna (seed) dostarczonego przez odzyskującą stronę. Atakujący może postawić fałszywego Coordinatora, którego manifest przechodzi walidację, ale którego seed jest kontrolowany przez atakującego. Jeśli ruch sieciowy zostanie przekierowany z legalnego Coordinatora do fałszywego, właściciel workloadu może zostać podszyty, gdy ustawia nowy manifest bez porównania zwróconego certyfikatu root CA z istniejącym lub weryfikuje Coordinatora bez porównania certyfikatu z zaufanym odniesieniem.

Contrast (Edgeless Systems) przed 1.8.1 loguje sekret workloadu do stderr, a tym samym do logów Kubernetes, gdy inicjalizator Contrast jest skonfigurowany z CONTRAST_LOG_LEVEL ustawionym na info lub debug. Ponieważ info jest domyślnym poziomem, wszystkie instalacje, które nie dostosowały poziomu logowania inicjalizatora, są dotknięte. Ujawnia to sekrety workloadów użytkownikom Kubernetes z uprawnieniami get lub list na pods/logs oraz każdemu z dostępem do odczytu magazynu logów Kubernetes.

Contrast, środowisko uruchomieniowe Edgeless Systems dla poufnych kontenerów na Kubernetes, jest dotknięte w wersjach do 1.9.0 włącznie. Dyrektywa VOLUME w Dockerfile (config.volumes w konfiguracji obrazu OCI) jest tylko wskazówką i nie jest specjalnie obsługiwana przez Kubernetes, ale containerd dodaje punkt montowania, gdy Kubernetes go nie ustawia, wymagając od środowiska uruchomieniowego możliwości wypychania dowolnych danych do agenta Kata. W rezultacie, w wdrożeniach Contrast na gołym metalu (wdrożenia AKS nie są dotknięte), które uruchamiają obraz deklarujący co najmniej jeden VOLUME, dla którego nie istnieje montowanie Kubernetes w tej ścieżce, niezaufany host może zapisać dowolne drzewa plików poniżej tego punktu montowania wewnątrz poufnego kontenera, naruszając integralność katalogu, który jest zazwyczaj ważny dla podstawowej funkcjonalności aplikacji.

Edgelesssys Contrast to runtime confidential-computing dla Kubernetes. W wersjach od 1.9.0 przed 1.12.2 inicjalizator loguje pełną odpowiedź NewMeshCert — zawierającą sekret workloadu — do standardowego wyjścia na poziomie INFO. W rezultacie sekrety workloadów są ujawniane każdemu użytkownikowi Kubernetes z uprawnieniami get lub list na pods/logs. Ponieważ sekrety workloadów są używane do szyfrowanego przechowywania i integracji z Vault, należy je uznać za skompromitowane.

Contrast, środowisko uruchomieniowe Kubernetes dla poufnych kontenerów, przed wersją 1.12.1 ma podatność w funkcji bezpiecznych woluminów trwałych. Złośliwy host może dostarczyć spreparowany wolumin LUKS2 do poda VM. Metadane woluminu LUKS2 nie są uwierzytelniane, a w wersjach cryptsetup przed 2.8.1 nagłówek określający algorytm szyfrowania null keyslot (cipher_null-ecb) jest akceptowany bez błędu. Ponieważ Initializer Contrast zakłada, że urządzenie jest chronione, jeśli `cryptsetup open` zakończy się sukcesem z tajnym ziarnem, gość otworzy wolumin dostarczony przez atakującego i zapisze tajne dane w postaci jawnej lub pod kluczem znanym atakującemu, co pozwala hostowi odczytać poufne dane, które powinny być zaszyfrowane.