W kontrolerze ingress-nginx opracowanym w ramach projektu Kubernetes zidentyfikowano trzy podatności, które w domyślnej konfiguracji umożliwiają dostęp do ustawień obiektu Ingress, który m.in. przechowuje dane uwierzytelniające umożliwiające dostęp do serwerów Kubernetes, umożliwiając dostęp uprzywilejowany do klastra. Problemy pojawiają się tylko w kontrolerze ingress-nginx z projektu Kubernetes i nie mają wpływu na kontroler kubernetes-ingres opracowany przez programistów NGINX.
Kontroler wejściowy pełni rolę bramy i jest używany w Kubernetesie do organizowania dostępu z sieci zewnętrznej do usług w ramach klastra. Najpopularniejszy jest kontroler ingress-nginx, który wykorzystuje serwer NGINX do przekazywania żądań do klastra, kierowania żądań zewnętrznych i równoważenia obciążenia. Projekt Kubernetes zapewnia podstawowe kontrolery ruchu przychodzącego dla AWS, GCE i nginx, z których ten ostatni nie jest w żaden sposób powiązany z kontrolerem ruchu przychodzącego kubernetes obsługiwanym przez F5/NGINX.
Luki CVE-2023-5043 i CVE-2023-5044 pozwalają na wykonanie kodu na serwerze z uprawnieniami procesu kontrolera ingresu przy użyciu „nginx.ingress.kubernetes.io/configuration-snippet” i „nginx.ingress Parametry .kubernetes”, aby je zastąpić .io/permanent-redirect.” Uzyskane prawa dostępu pozwalają między innymi na pobranie tokena służącego do uwierzytelnienia na poziomie zarządzania klastrem. Luka CVE-2022-4886 umożliwia ominięcie weryfikacji ścieżki pliku przy użyciu dyrektywy log_format.
Dwie pierwsze luki występują wyłącznie w wydaniach ingress-nginx wcześniejszych niż wersja 1.9.0, natomiast ostatnia - przed wersją 1.8.0. Aby przeprowadzić atak, atakujący musi mieć dostęp do konfiguracji obiektu ingresu, np. w wielodostępnych klastrach Kubernetes, w których użytkownicy otrzymują możliwość tworzenia obiektów w swojej przestrzeni nazw.
Źródło: opennet.ru