Katalog podatności CVE

vm2 przed 3.12.2 nie stosuje niezmiennika własności backing-store bufora (byteOffset === 0 i buffer.byteLength === length) do buforów zwracanych z wbudowanych modułów hosta. Gdy aplikacja udostępnia moduł zlib Node przez listę dozwolonych wbudowanych w NodeVM, zlib.deflateSync może zwrócić Buffer oparty na współdzielonej puli małych buforów Node, którego .buffer obejmuje całą pulę. Niezaufany kod gościa może utworzyć pełnowymiarowy widok tego ArrayBuffer, aby czytać i modyfikować bajty należące do niepowiązanych buforów hosta.

vm2 przed wersją 3.12.2 nie stosuje obsługi odrzuceń Promise po stronie hosta w pułapce konstrukcji sandbox-host. W BaseHandler, pułapka apply wywołuje markHostPromiseHandled() na zwróconej wartości, ale sąsiednia ścieżka construct zwraca wynik Reflect.construct bez tej samej sanityzacji. Jeśli embedder udostępnia konstruowalną funkcję hosta, której konstruktor zwraca natywnie odrzuconą Promise, niezaufany skrypt uruchomiony przez VM.run może ją wywołać z `new` i zignorować wynik; odrzucona Promise hosta przechodzi przez most nieobsłużona i, zgodnie z rygorystyczną polityką nieobsłużonych odrzuceń Node, jest promowana do nieprzechwyconego wyjątku, który kończy proces hosta.

Podatność w vm2 przed wersją 3.12.2 umożliwia obejście autoryzacji w resolverze modułów zewnętrznych NodeVM. Gdy konfiguracja `require.external` używa niestandardowego resolwera z `context: 'host'`, kod gościa może zażądać modułu z listy dozwolonych, a następnie ścieżki bezwzględnej modułu nieznajdującego się na liście, który współdzieli prefiks ścieżki. Prowadzi to do ucieczki z sandboxa i wykonania dowolnego kodu w procesie hosta.

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.

Podatność w D-Link DIR-895L A1_102b07 dotyczy funkcji tunnel_set_params w pliku tunnel.c komponentu L2TP Control Channel Parser. Manipulacja prowadzi do zapisu poza dozwolonym obszarem pamięci (out-of-bounds write). Atak może być przeprowadzony zdalnie, a exploit jest publicznie dostępny.

W projekcie CloudClassroom-PHP-Project wykryto podatność typu SQL injection w pliku viewresult.php, polegającą na manipulacji argumentem seno. Podatność można wykorzystać zdalnie, a publiczny exploit jest już dostępny. Produkt jest dostarczany w modelu rolling release, więc szczegóły wersji nie są podane, a producent nie odpowiedział na zgłoszenie.

Nieograniczone zużycie zasobów (CWE-400) w Elasticsearch może prowadzić do odmowy usługi poprzez nadmierną alokację (CAPEC-130).

Nieograniczone zużycie zasobów (CWE-400) w Kibana może prowadzić do odmowy usługi poprzez nadmierną alokację (CAPEC-130).

Nieograniczone zużycie zasobów (CWE-400) w Elasticsearch może prowadzić do odmowy usługi poprzez nadmierną alokację (CAPEC-130).

Nieograniczone zużycie zasobów (CWE-400) w Elasticsearch może prowadzić do odmowy usługi poprzez nadmierną alokację (CAPEC-130).

Nieograniczone zużycie zasobów (CWE-400) w Elasticsearch może prowadzić do odmowy usługi poprzez nadmierną alokację (CAPEC-130).

Nieograniczone zużycie zasobów (CWE-400) w Elasticsearch może prowadzić do odmowy usługi poprzez nadmierną alokację (CAPEC-130).

Nieograniczone zużycie zasobów (CWE-400) w Elasticsearch może prowadzić do odmowy usługi poprzez nadmierną alokację (CAPEC-130).

Nieograniczone zużycie zasobów (CWE-400) w Elasticsearch może prowadzić do odmowy usługi poprzez nadmierną alokację (CAPEC-130).

Brak autoryzacji (CWE-862) w Kibana może prowadzić do nieautoryzowanego usuwania danych poprzez wykorzystanie niepoprawnie skonfigurowanych poziomów kontroli dostępu (CAPEC-180). Uwierzytelniony użytkownik z uprawnieniami Synthetics ograniczonymi do pojedynczej przestrzeni Kibana może trwale usunąć monitory Synthetics współdzielone z przestrzeniami, do których nie ma dostępu. W przypadku monitora powiązanego z prywatną lokalizacją ta sama operacja niszczy również konfigurację integracji Elastic Agent bez kontroli autoryzacji, które Fleet normalnie stosuje.

W Kibana Agent Builder występuje podatność typu Confused Deputy (CWE-441), która może prowadzić do eskalacji uprawnień. Użytkownik bez uprawnień administracyjnych, mogący edytować współdzielonego agenta, może doprowadzić do wykonania uprzywilejowanych operacji w kontekście użytkownika o wyższych uprawnieniach. Jeśli ten sam użytkownik może także tworzyć workflowy, może to skutkować pełną kontrolą administracyjną nad Kibana i klastrem Elasticsearch.