Podatności Apache NiFi

W Apache NiFi przed wersją 0.7.2 oraz 1.x przed wersją 1.1.2, w środowisku klastrowym, jeśli żądanie anonimowego użytkownika jest replikowane do innego węzła, to tożsamość węzła źródłowego jest używana zamiast tożsamości 'anonimowego' użytkownika.

Apache NiFi w wersjach przed 0.7.4 oraz 1.x przed 1.3.0 nie ustawia nagłówka odpowiedzi, który informuje przeglądarki, aby zezwalały na osadzanie tylko z tego samego źródła.

Apache NiFi w wersjach 2.0.0 do 2.10.0 umożliwia tworzenie, odczytywanie i usuwanie Assetów powiązanych z kontekstami parametrów przez REST API. Framework autoryzuje usuwanie Assetów na podstawie identyfikatora kontekstu parametru, ale nie weryfikuje, czy Asset faktycznie należy do tego kontekstu. Instalacje bez zróżnicowanych poziomów autoryzacji między kontekstami nie są podatne. Aktualizacja do wersji 2.11.0 rozwiązuje problem.

Apache NiFi w wersjach od 1.10.0 do 2.10.0 udostępnia metodę REST API do aktualizacji kontekstu parametrów, która nie wymusza sprawdzania autoryzacji na komponentach odwołujących się do wartości parametrów. Uwierzytelniony użytkownik upoważniony do modyfikacji kontekstu parametrów, ale nieupoważniony do komponentów odwołujących się, może zmienić wartości parametrów wpływające na te komponenty. W przypadku, gdy wartość parametru zawiera skryptowalną treść, aktualizacja parametru może prowadzić do wykonania kodu podczas automatycznej walidacji komponentu. Problem dotyczy tylko wdrożeń z politykami autoryzacji na poziomie komponentów. Zalecana jest aktualizacja do Apache NiFi 2.11.0.

W Apache NiFi przed wersją 0.7.2 oraz 1.x przed wersją 1.1.2 w środowisku klastrowym, proces serializacji/deserializacji łańcucha proxy jest podatny na atak typu injection, który pozwala na podszycie się pod innego użytkownika za pomocą starannie skonstruowanej nazwy użytkownika.

Apache NiFi 2.11.0 udostępnia metody REST API do migracji zawartości wersjonowanej grupy procesów do Connectora, które autoryzują żądania wyłącznie względem docelowego Connectora, bez sprawdzania uprawnień do zaangażowanych grup procesów. Uwierzytelniony użytkownik z prawem odczytu Connectora może wyliczyć identyfikatory, nazwy i szczegóły rejestru przepływów grup procesów poza zakresem jego uprawnień, a użytkownik z prawem zapisu może zmigrować grupę procesów bez uprawnień do niej.

Apache NiFi w wersjach od 1.5.0 do 2.11.0 udostępnia metody REST API zastępujące całą zawartość Process Group na podstawie definicji przepływu dostarczonej przez klienta. Autoryzacja frameworku dla tych metod ograniczała się do uprawnień odczytu i zapisu na samej Process Group, w przeciwieństwie do asynchronicznych metod aktualizacji, które autoryzują również komponenty wewnątrz grupy oraz powiązane Controller Services, Parameter Contexts i Parameter Providers. W efekcie uwierzytelniony użytkownik z prawem zapisu mógł modyfikować lub usuwać komponenty w podrzędnych Process Groups objętych bardziej restrykcyjnymi politykami.

Apache NiFi w wersjach od 2.9.0 do 2.11.0 udostępnia metody REST API aktualizacji i weryfikacji konfiguracji Connectora, które nie wymuszają sprawdzania autoryzacji dla Assets i Secrets wskazanych w proponowanej konfiguracji. Uwierzytelniony użytkownik uprawniony do modyfikacji Connectora, ale nie do odczytu powiązanego Parameter Providera, może zastosować wartości Secret z tego Parameter Providera; metody akceptują też identyfikatory Assetów bez weryfikacji przynależności do konfigurowanego Connectora.

Apache NiFi 2.11.0 wyłączył obsługę żądań HTTP z kodowaniem gzip dla REST API i odrzucał żądania zawierające standardowy nagłówek Content-Encoding wskazujący gzip. Filtr egzekwujący w frameworku nie sprawdzał jednak wielu wystąpień nagłówka Content-Encoding ani niestandardowych identyfikatorów kodowania gzip, co pozwalało złośliwemu klientowi wysyłać spreparowane żądania powodujące nadmierne zużycie pamięci.

Apache NiFi od wersji 1.5.0 do 2.10.0 obsługuje zakodowane gzip żądania HTTP dla REST API przy użyciu filtra kodowania Jersey. Framework egzekwował konfigurowalny maksymalny rozmiar żądania na skompresowanym ładunku, a nie na zdekompresowanym wyjściu, co pozwalało złośliwemu klientowi na wysyłanie spreparowanych żądań, które mogły zużywać nadmierne ilości pamięci.

Obsługa autoryzacji dla żądań walidacji kontekstu parametru w Apache NiFi od wersji 1.10.0 do 2.10.0 pozwala klientom z dostępem do odczytu na przesyłanie proponowanych wartości parametrów. Proponowane wartości zastępują bieżącą konfigurację, umożliwiając użytkownikom z dostępem do odczytu wywoływanie predefiniowanych metod walidacji komponentów z alternatywnymi ustawieniami. Instalacje Apache NiFi, które nie implementują różnych poziomów autoryzacji dla przeglądania i modyfikowania konfiguracji kontekstu parametru, nie są podatne na tę lukę.

Apache NiFi w wersjach od 0.0.1 do 2.9.0 nie weryfikuje wartości nagłówków Proxy i Forwarded, co pozwala na budowanie nieprawidłowych URL-i. Wersja 1.6.0 wprowadziła możliwość ograniczenia wartości w nagłówku Host, ale nie zastosowano tego do alternatywnych nagłówków.

Apache NiFi w wersjach od 1.12.0 do 2.9.0 nie sprawdza autoryzacji przy wymianie grup procesów, które zawierają komponenty z oznaczeniem Restricted. Brak tej autoryzacji pozwala użytkownikom z ogólnym dostępem do zapisu na dodawanie komponentów z ograniczonym dostępem.

W Apache NiFi w wersjach od 1.15.0 do 2.9.0, obsługa autoryzacji dla żądań weryfikacji konfiguracji komponentów pozwala klientom z dostępem do odczytu na przesyłanie proponowanych właściwości konfiguracyjnych. Te właściwości mogą nadpisywać aktualną konfigurację, co umożliwia użytkownikom z dostępem do odczytu wywoływanie zdefiniowanych metod weryfikacji z alternatywnymi ustawieniami.

Apache NiFi w wersjach od 1.21.0 do 1.23.0 ma lukę w walidacji adresów URL połączeń JDBC i JNDI JMS, co pozwala uwierzytelnionym użytkownikom na obejście tej walidacji za pomocą niestandardowego formatowania wejścia.

Apache NiFi w wersjach od 0.0.2 do 1.22.0 zawiera procesory i usługi kontrolne, które umożliwiają odniesienia URL HTTP do pobierania sterowników, co pozwala uwierzytelnionemu i autoryzowanemu użytkownikowi na skonfigurowanie lokalizacji umożliwiającej wykonanie niestandardowego kodu.