Podatności Kyverno

Kyverno w wersji przed 1.19.2 zawiera podatność typu authorization bypass, która pozwala tenantom w przestrzeniach nazw generować dowolne rodzaje zasobów w dowolnej przestrzeni nazw poprzez szablonowanie rodzaju i przestrzeni nazw reguły generate zmiennymi. Atakujący może utworzyć Policy i wyzwalający ConfigMap we własnej przestrzeni nazw, powodując zapis przez uprzywilejowany background-controller NetworkPolicies lub RoleBindings do przestrzeni nazw ofiar lub kube-system.

Kyverno od wersji 1.19.1 przed 1.19.2 zawiera podatność typu authorization bypass w apiCall namespace clamp, która pozwala dzierżawcom przestrzeni nazw na wysyłanie żądań API między przestrzeniami nazw i o zasięgu klastra poprzez dołączanie zniekształconych procentowych sekwencji ucieczki do urlPath. Atakujący mogą tworzyć polityki w przestrzeni nazw, których apiCall działa jako konto usługi kontrolera admission, aby odczytywać zasoby innych przestrzeni nazw i tworzyć mutujące webhooki, eskalując do uprawnień administratora klastra.

Kyverno w wersji 1.18.0 przed 1.19.2 zawiera obejście weryfikacji podpisu w verifyImages, ponieważ wyniki weryfikacji są buforowane według ciągu referencji obrazu (np. tagu), a nie powiązane z zweryfikowanym skrótem, więc trafienia w pamięć podręczną pomijają sprawdzanie podpisów i atestacji. Atakujący mogący przesyłać obciążenia i zmieniać tag rejestru może rozgrzać pamięć podręczną podpisanym obrazem, przestawić tag i doprowadzić do przyjęcia niezweryfikowanego obrazu z przypiętym skrótem przez mutateDigest.

Kyverno od wersji 1.17.0 przed 1.19.2 zawiera podatność na eskalację uprawnień umożliwiającą najemcom o zasięgu przestrzeni nazw modyfikowanie zasobów w innych przestrzeniach nazw poprzez wynik CEL targetMatchConstraints.expression w NamespacedMutatingPolicy bez sprawdzeń przestrzeni nazw. Atakujący mogą wyemitować dosłowny cel, taki jak RoleBinding innego najemcy, który kontroler w tle o zasięgu klastra następnie zmodyfikuje, dodając podmioty atakującego lub zmieniając Role, NetworkPolicies i ConfigMaps.

Kyverno od wersji 1.16.0 przed 1.19.2 nie waliduje segmentów ścieżki w argumencie zasobu resource.get() i resource.post(), umożliwiając politykom CEL o zasięgu przestrzeni nazw wyjście poza swoją przestrzeń nazw. Najemcy mogący tworzyć NamespacedValidatingPolicy mogą wstawiać segmenty .., aby odczytywać i zapisywać dowolne obiekty klastra przy użyciu konta usługi kontrolera dopuszczania, prowadząc do przejęcia klastra.

Kyverno od wersji 1.19.1 przed 1.19.2 waliduje urlPath w context.apiCall polityki po jego oczyszczeniu, ale wykonuje surową ścieżkę, której fragment lub zapytanie klient Kubernetes odrzuca. Użytkownik o zasięgu przestrzeni nazw mogący tworzyć politykę może ukryć segmenty ../ za # lub ?, aby dotrzeć do punktów końcowych o zasięgu klastra przy użyciu konta usługi Kyverno, uzyskując uprawnienia administratora klastra.

Kyverno od wersji 1.17.0 przed 1.19.2 zawiera podatność na obejście autoryzacji umożliwiającą administratorom przestrzeni nazw wyjście poza ograniczenia przestrzeni nazw, ponieważ kontroler czyszczenia buduje kontekst ładowania z polityką nil. Atakujący mogą tworzyć CleanupPolicy w przestrzeni nazw z wpisami kontekstu apiCall lub globalReference, aby odczytywać Secrets z innych przestrzeni nazw i modyfikować validatingwebhookconfigurations przy użyciu konta usługi kontrolera czyszczenia.

Kyverno od wersji 1.17.0 przed 1.19.2 zawiera podatność na obejście autoryzacji umożliwiającą najemcom przestrzeni nazw nadpisywanie zasobów w innych przestrzeniach nazw poprzez NamespacedMutatingPolicy mutate-existing targetMatchConstraints.expression. Atakujący mogą zwrócić literał mapy CEL fabrykujący cel z wybraną przez atakującego metadata.namespace, powodując nadpisanie przez uprzywilejowany kontroler w tle Secrets, Deployments lub polityk w całym klastrze.

Kyverno przed wersją 1.19.2 zawiera podatność na eskalację uprawnień umożliwiającą administratorom przestrzeni nazw tworzenie zasobów poza ich RBAC, ponieważ sprawdzenia dopuszczania reguł generate weryfikują uprawnienia kontrolera, a nie autora. Atakujący mogą tworzyć politykę w przestrzeni nazw z regułami generate skierowanymi do innych przestrzeni nazw lub rodzajów o zasięgu klastra, powodując tworzenie lub klonowanie zasobów w całym klastrze przez kontroler w tle.

Kyverno przed wersją 1.19.1 nieprawidłowo waliduje zakodowane w URL segmenty ścieżki w apiCall urlPath polityki, co pozwala tenantom namespace'ów ominąć ograniczenia per-namespace i tworzyć obiekty w innych namespace'ach jako ServiceAccount kontrolera admission. Atakujący mogą wykorzystać percent-encoded sekwencje traversal katalogów do tworzenia obiektów MutatingWebhookConfiguration w całym klastrze lub obiektów PolicyException w namespace kyverno, co umożliwia eskalację uprawnień do administratora klastra.

W Kyverno w wersjach od v1.9.0 do v1.12.7 występuje błąd w obsłudze wyjątków polityk. Gdy polityka w trybie enforce jest połączona z dwoma wyjątkami PolicyExceptions, mniej restrykcyjny wyjątek ma pierwszeństwo, co pozwala atakującemu ominąć politykę poprzez stworzenie nazwy zasobu pasującej do wzorca drugiego wyjątku (np. '*ingress*'). Można to wykorzystać do obejścia polityk takich jak blokowanie wolumenów hostPath. Poprawiono w v1.13.0.

Kyverno, silnik polityk dla platform cloud native, w wersjach od 1.18.0 do 1.18.2, w kompilatorze CEL NamespacedMutatingPolicy udostępnia bibliotekę generatora dla matchConditions, co pozwala polityce o zasięgu przestrzeni nazw na wywołanie generator.apply(namespace, resources) z dowolną docelową przestrzenią nazw. Walidacja w pkg/cel/policies/mpol/validate.go sprawdza, czy polityka się kompiluje, ale nie egzekwuje zakresu przestrzeni nazw, a GenerateResources w pkg/cel/libs/context.go nie odrzuca celu między przestrzeniami nazw. Użytkownik, który może tworzyć obiekty NamespacedMutatingPolicy w jednej przestrzeni nazw, może spowodować, że kontroler przyjęcia, działający z uprawnieniami całego klastra, utworzy ConfigMaps, NetworkPolicies, Secrets, RoleBindings i inne zasoby w innej przestrzeni nazw, umożliwiając nieautoryzowaną modyfikację i potencjalną eskalację uprawnień. Problem został naprawiony w wersji 1.18.2.

Kyverno od wersji 1.11.0 przed 1.19.2 zawiera podatność na nieograniczoną dekompresję w FetchSignatureBlob, umożliwiającą atakującym wyczerpanie pamięci poprzez dostarczanie silnie skompresowanych warstw podpisów notary. Atakujący kontrolujący referrery lub podpisy rejestru mogą publikować małe warstwy gzip, które dekompresują się ponad maxPayloadSize, powodując zabicie kontrolera dopuszczania przez OOM i odmowę usługi.

Kyverno w wersjach od 1.11.0 do 1.19.2 zawiera podatność na nieograniczoną dekompresję w funkcji extractStatement. Atakujący kontrolujący artefakty referrer w rejestrze mogą dostarczyć silnie skompresowane warstwy atestacji, które po dekompresji przekraczają maxPayloadSize, powodując wyczerpanie pamięci i zabicie kontrolera admission przez OOM.

Kyverno przed wersją 1.19.2 zawiera podatność na brak autoryzacji, która pozwala autorom polityk w przestrzeniach nazw na odczyt zasobów w innych przestrzeniach nazw poprzez szablonowanie wartości generate.clone lub cloneList. Atakujący mogą oznaczyć wyzwalający ConfigMap, aby kontroler w tle skopiował wrażliwy ConfigMap z ofiary do przestrzeni nazw atakującego.

Kyverno przed wersją 1.19.2 zawiera podatność na odmowę usługi w operatorach In i NotIn, która pozwala atakującym na zawieszenie silnika polityk poprzez niesprawdzone rzutowanie typu. Atakujący mogą przesłać zasoby, których wartości oceniane przez JMESPath dają tablice liczb całkowitych, wartości logicznych lub typów mieszanych, wywołując panikę.

Kyverno przed wersją 1.19.2 zawiera obejście uwierzytelniania w matchCertificateData, które pomija sprawdzanie subject i subjectRegExp w verifyImages, gdy certyfikat podpisujący nie ma Subject Alternative Name. Atakujący posiadający certyfikat liścia z zaufanego głównego certyfikatu mogą pominąć SAN, ustawić oczekiwany identyfikator wystawcy Fulcio OID i podpisać złośliwe obrazy, które zostaną dopuszczone mimo przypięcia podpisującego.

Kyverno w wersjach od 1.17.0 do 1.19.2 zawiera podatność na brak autoryzacji w procesorze mutate-existing w tle, która pozwala dzierżawcom w przestrzeniach nazw na modyfikowanie zasobów poza ich przestrzenią nazw. Atakujący mogą tworzyć NamespacedMutatingPolicy celujące w obiekty Namespace lub zasoby ofiary za pomocą wyrażeń CEL, powodując usunięcie etykiet Pod Security w całym klastrze przez konto usługi kontrolera w tle.

Kyverno przed wersją 1.19.2 zawiera niesprawdzone rzutowanie typu w buildStatementMap, które pozwala nieuwierzytelnionym atakującym na zawieszenie silnika polityk za pomocą spreparowanych oświadczeń atestacji. Atakujący mogą przesłać manifest referrer OCI z polem typu niebędącym ciągiem znaków, aby obejść weryfikację obrazu przy failurePolicy Ignore lub spowodować pętlę awarii reports-controller.

Kyverno przed wersją 1.19.2 zawiera niesprawdzone rzutowanie typu w silniku podstawiania zmiennych, które pozwala użytkownikom mogącym przesyłać zasoby na zawieszenie silnika polityk. Atakujący mogą przesłać zasoby z polami niebędącymi ciągami znaków, do których odwołuje się płytkie podstawienie {{- variable }} w politykach, powodując panikę i odmowę usługi webhooka oraz obejście polityk przy failurePolicy Ignore.

Kyverno w wersjach od 1.19.1 do 1.19.2 zawiera obejście izolacji przestrzeni nazw w APICall Fetch() w pkg/engine/apicall/apiCall.go, ponieważ path.Clean traktuje '?' jako znak ścieżki, pozwalając wyrażeniu regularnemu przestrzeni nazw dopasować segmenty w ciągu zapytania. Użytkownicy mogący tworzyć polityki w przestrzeniach nazw mogą podać URLPath taki jak /api/v1/nodes?x=/namespaces/default/, który przechodzi walidację, podczas gdy client-go żąda punktu końcowego o zasięgu klastra, odczytując zasoby poza ich przestrzenią nazw.

Kyverno w wersjach przed 1.19.2 zawiera podatność typu denial of service, która pozwala autorom polityk w obrębie namespace wyczerpać CPU i pamięć przez przesyłanie wyrażeń CEL ocenianych bez limitów kosztu wykonania. Atakujący może utworzyć NamespacedValidatingPolicy lub NamespacedDeletingPolicy z zagnieżdżonymi komprehensjami map nad dużymi polami ConfigMap, co prowadzi do zabicia podów Kyverno przez OOM i zablokowania admission w całym klastrze.

Kyverno przed wersją 1.19.2 zawiera podatność na obejście autoryzacji w Generation Handler, która pozwala użytkownikom z uprawnieniami create/update na wyzwalanie zsynchronizowanych polityk generate poprzez fałszowanie wewnętrznych etykiet generate.kyverno.io. Atakujący mogą oznaczyć ConfigMap jako zarządzany przez kyverno ze spreparowanymi etykietami polityki, reguły i wyzwalacza, aby sklonować wrażliwe Sekrety z zastrzeżonych przestrzeni nazw do własnej przestrzeni nazw.

Kyverno przed wersją 1.19.2 zawiera podatność na obejście polityk w kontrolerze admissionpolicygenerator, który włącza PolicyExceptions do generowanych ValidatingAdmissionPolicies, ignorując flagi --enablePolicyException, --exceptionNamespace i bramki rodzaju polityki. Użytkownicy z uprawnieniami do tworzenia PolicyExceptions w przestrzeniach nazw mogą wstrzykiwać zanegowane matchConditions do generowanych polityk, aby dopuścić naruszające zasoby, omijając egzekwowanie w całym klastrze.

Kyverno w wersjach przed 1.19.2 zawiera podatność typu denial of service, która pozwala autorom polityk w obrębie namespace wyczerpać CPU kontrolera admission przez przesyłanie patologicznych wzorców wildcard. Atakujący może utworzyć Policy z spreparowanymi regułami match i exclude, które są oceniane przez ValidateMatchExcludeConflict, przypinając rdzenie i powodując ogólnoklastrowe przekroczenia czasu webhooków blokujące operacje na zasobach.

Kyverno w wersjach przed 1.19.2 zawiera podatność typu denial of service w funkcji substituteVariablesIfAny, która pozwala użytkownikom o niskich uprawnieniach zawiesić webhook admission poprzez samoodwołujące się szablony zmiennych. Atakujący może tworzyć zasoby, których adnotacje ponownie wprowadzają osadzoną zmienną polityki, powodując nieograniczone pętle podstawiania, które wyczerpują CPU i pamięć oraz blokują admission w całym klastrze.

Kyverno w wersjach przed 1.19.1 zawiera lukę pozwalającą na obejście izolacji przestrzeni nazw w wpisie kontekstu apiCall dla zasobów Policy z ograniczeniem do namespace. Wynika to z niespójnej interpretacji ścieżek między walidacją a wykonaniem. Użytkownik o niskich uprawnieniach może użyć procentowo zakodowanych segmentów kropek w urlPath, aby ominąć sprawdzanie przestrzeni nazw i odczytać zasoby z innych namespace przy użyciu poświadczeń ServiceAccount kontrolera Kyverno.

Kyverno przed wersją 1.19.1 jest podatny na SSRF. Domyślna lista blokowania egress (169.254.169.254, 169.254.169.253, metadata.google.internal, 127.0.0.0/8, ::1/128) i kontrola tokenów z ograniczonym zakresem były podłączone tylko do nowej biblioteki CEL http.Get/Post, ale nie do starszego executor usług apiCall (pkg/engine/apicall/executor.go) ani do ścieżki GlobalContextEntry external-API. Te ścieżki używają zwykłego klienta net/http bez filtrowania egress i bez walidacji adresu URL usługi, co pozwala autorowi ClusterPolicy lub GlobalContextEntry (lub osobie przesyłającej zasoby, jeśli polityka używa szablonu URL) na wysyłanie żądań GET/POST do dowolnego hosta, w tym do punktu metadanych chmury, loopback i usług wewnątrz klastra. Executor bezwarunkowo dołącza token ServiceAccount Kyverno do wybranego przez atakującego miejsca docelowego. Naprawiono w wersji 1.19.1.

Kyverno to silnik polityk dla Kubernetes. W wersjach od 1.14.0 do 1.19.0 evaluator ImageValidatingPolicy nigdy nie odczytuje pól spec.images i spec.allowedValues z PolicyException. Każdy PolicyException, którego policyRefs i matchConditions pasują do zasobu, powoduje pominięcie weryfikacji podpisu obrazu dla całego zasobu, a nie tylko dla wymienionych obrazów lub wartości. W rezultacie niepodpisane lub niezaufane obrazy mogą być dopuszczone do klastra bez weryfikacji podpisu. Różni się to od ValidatingPolicy, GeneratingPolicy i MutatingPolicy, które traktują to samo pole jako częściowe wyłączenie. Problem naprawiono w wersji 1.19.1.

Kyverno w wersjach od 1.16.0 do 1.19.0 rejestruje bibliotekę globalcontext.Lib CEL w środowisku polityk bez ograniczania jej do przestrzeni nazw polityki, w przeciwieństwie do bibliotek pokrewnych, które otrzymują przestrzeń nazw polityki. Tenant mogący tworzyć polityki z ograniczeniem do namespace w swoim namespace może wywołać globalContext.get("<entry>", "") i otrzymać pełną zawartość buforowanego GlobalContextEntry o zasięgu klastra, w tym dane z przestrzeni nazw, do których tenant nie ma uprawnień RBAC. Brak walidacji przyjęcia odrzucającej takie wywołania. Naprawiono w 1.19.1.

Kyverno przed wersją 1.16.2 zawiera podatność na podrabianie żądań po stronie serwera (SSRF) w funkcji APICall. Pole URL w konfiguracji ServiceCall w polityce nie jest walidowane, więc użytkownik z uprawnieniami do tworzenia polityk na poziomie przestrzeni nazw może skierować Kyverno do wysyłania żądań HTTP do dowolnych zasobów wewnętrznych (np. punktów metadanych chmury takich jak 169.254.169.254 lub zasobów innych dzierżawców). Ponieważ Kyverno wykonuje te żądania przy użyciu swojego konta usługi o wysokich uprawnieniach w całym klastrze (problem Confused Deputy), odpowiedzi – potencjalnie zawierające sekrety innych dzierżawców i poświadczenia IAM chmury – są zwracane w PolicyReport i mogą być odczytane przez atakującego, co łamie izolację wielodostępową.

Kyverno przed wersją 1.18.0 zawiera podatność na podrabianie żądań po stronie serwera (SSRF) w apiCall.service.url, która umożliwia uwierzytelnionym użytkownikom wysyłanie dowolnych żądań HTTP poprzez wstrzykiwanie danych kontrolowanych przez użytkownika przez podstawianie zmiennych. Atakujący mogą celować w usługi wewnętrzne, punkty metadanych chmury i adresy loopback, a dane odpowiedzi są odzwierciedlane w komunikatach błędów przyjęcia, co umożliwia nieślepą eksfiltrację danych.

Kyverno przed wersją 1.16.4 automatycznie dołącza token konta usługi kontrolera przyjęć do wychodzących żądań HTTP w trybie usługi apiCall bez jawnych nagłówków autoryzacji. Atakujący mogą eksfiltrować token, kierując żądania apiCall do zewnętrznych lub kontrolowanych przez atakującego punktów końcowych, uzyskując pełną kontrolę nad politykami Kyverno i zasobami klastra.

Kyverno przed wersją v1.13.4 jest podatny na podrabianie żądań po stronie serwera (SSRF) przez funkcję Service Call. Atakujący z uprawnieniami do tworzenia polityk Kyverno (Cluster)Policies może określić zewnętrzny URL w konfiguracji apiCall/service w polityce; chociaż Service Call jest udokumentowany dla usług w klastrze, rozwiązuje również adresy zewnętrzne, umożliwiając wysyłanie żądań do serwera kontrolowanego przez atakującego. Ponieważ dane kontekstu polityki (w tym zawartość zasobów Kubernetes, takich jak sekrety) są wysyłane w tych żądaniach, atakujący może eksfiltrować wrażliwe dane klastra.

Kyverno w wersjach 1.9.4 i wcześniejszych obsługuje niebezpieczne zestawy szyfrów 3DES (TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA i TLS_RSA_WITH_3DES_EDE_CBC_SHA) na swoich punktach końcowych TLS. Te 64-bitowe szyfry blokowe są podatne na atak Sweet32 (CVE-2016-2183), który przy bardzo długotrwałych połączeniach TLS przesyłających duże ilości danych może pozwolić atakującemu na odzyskanie niewielkich fragmentów tekstu jawnego. Problem został naprawiony w Kyverno 1.9.5 i 1.10.0.

Kyverno, silnik polityk zaprojektowany dla Kubernetes, w wersjach przed 1.10.0 pozwalał zasobom zdefiniowanym z polem `deletionTimestamp` na obejście polityk walidacji, generowania lub modyfikacji. Zasoby oczekujące na usunięcie były świadomie zwolnione z przetwarzania, co mogło umożliwić złośliwym użytkownikom manipulację politykami.

Kyverno to silnik polityk zaprojektowany dla Kubernetes. Kontrola seccomp w Kyverno może być obejściem, co dotyczy użytkowników subreguły `validate.podSecurity` w wersjach 1.9.2 i 1.9.3. Problem został naprawiony w wersji 1.9.4.