CVE-2023-34091

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 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.