Katalog podatności CVE

Hasło administracyjne jest hashowane przy użyciu stosunkowo słabego, szybkiego algorytmu dla magazynu poświadczeń obsługującego jedną ścieżkę uwierzytelniania, a plik zawierający ten hash jest zapisywany z uprawnieniami umożliwiającymi odczyt każdemu lokalnemu użytkownikowi. Jest to niespójne z silniejszym algorytmem hashowania używanym dla tego samego hasła na innej ścieżce uwierzytelniania.

Przykładowy plik konfiguracyjny dołączonego komponentu do zarządzania zapasami zawiera stałe, publicznie znane hasło administracyjne. Wdrożenie, które skopiuje ten przykładowy plik do aktywnej konfiguracji bez uruchomienia procedury inicjalizacyjnej regenerującej poświadczenia, ujawni interfejs administracyjny komponentu każdemu znającemu domyślną wartość.

Wcześniejsza aktualizacja, która podniosła wbudowaną bibliotekę klienta HTTP do wersji usuwającej znane podatności, została później wycofana, przywracając starszą, podatną wersję do komponentu przetwarzającego logi. Jedyna ścieżka kodu w tym komponencie korzystająca z biblioteki wysyła żądanie do jednego stałego, zaufanego adresu URL dostawcy przy inicjalizacji i nie przetwarza danych kontrolowanych przez atakującego.

Tryb wdrożenia mający na celu udostępnienie wyłącznie dostępu do odczytu interfejsu wbudowanego komponentu analizy pakietów blokuje listę tras z możliwością zapisu według wzorca, ale wzorzec pomija trasy modyfikujące tagi dołączone do przechowywanych rekordów sesji. Konfiguracja proxy w inny sposób zezwala na metodę żądania używaną przez te trasy.

Procedura obsługi przesyłania plików przekierowuje przeglądarkę uwierzytelnionego klienta do adresu URL pobranego bezpośrednio z nagłówka Referer tego samego żądania, bez walidacji względem własnego origin aplikacji. Umożliwia to uwierzytelnionemu atakującemu spreparowanie żądania powodującego przekierowanie przeglądarki innego użytkownika do dowolnego zewnętrznego miejsca po zakończeniu przesyłania.

Żądania z reverse proxy do usługi dostawcy tożsamości dotyczące wykrywania tokenów, introspekcji i wymiany poświadczeń nie weryfikują certyfikatu serwera dostawcy tożsamości. Atakujący znajdujący się na ścieżce sieciowej między proxy a dostawcą tożsamości może podszyć się pod dostawcę tożsamości i wystawić sfałszowane tokeny uwierzytelniające akceptowane przez wdrożenie.

Przykładowy plik konfiguracyjny środowiska zawiera stałą, publicznie znaną wartość sekretu używaną do podpisywania ciasteczek uwierzytelniających dla dołączonego komponentu analizy pakietów. Wdrożenie, które skopiuje ten przykładowy plik do aktywnej konfiguracji bez uruchomienia procedury konfiguracyjnej regenerującej wartość, będzie używać znanej domyślnej wartości.

Mechanizm autoryzacji oparty na rolach domyślnie przyznaje dostęp, gdy nazwa handlera żądania nie znajduje się w tabeli wymagań ról, zamiast domyślnie odmawiać. Każdy handler nie zarejestrowany jawnie w tej tabeli jest osiągalny dla dowolnego uwierzytelnionego użytkownika niezależnie od jego roli, a nowo dodane handlery są domyślnie fail-open.

W określonym trybie uwierzytelniania reverse proxy przekazuje żądania do dołączonego interfejsu administracyjnego firm trzecich bez uprzedniego zastosowania własnego wymogu uwierzytelnienia bramy. Cała kontrola dostępu do tego interfejsu, który zarządza magazynem poświadczeń dla wszystkich innych usług, jest delegowana wyłącznie do mechanizmu logowania tego interfejsu.

Tryb wdrożenia przeznaczony do udostępniania wyłącznie dostępu do odczytu danych pośredniczy w zestawie tras API bez ograniczenia dozwolonych metod żądań. Jedna z tras przyjmuje żądanie tworzące lub nadpisujące zapisany rekord, w tym identyfikator wybrany przez atakującego, używając własnych podniesionych poświadczeń backendu aplikacji.

Reguła routingu wybiera między dwoma mechanizmami uwierzytelniania dla tej samej usługi na podstawie wartości nagłówka żądania dostarczonego przez klienta, a nie właściwości, której klient nie może kontrolować. Uwierzytelniony użytkownik posiadający wspólne poświadczenie usługi może ustawić ten nagłówek, aby ominąć podstawową kontrolę autoryzacji opartą na rolach i osiągnąć stałą, podniesioną rolę ścieżki alternatywnej.

Punkt końcowy API przyjmuje wartość dostarczoną przez użytkownika i interpoluje ją bezpośrednio do ścieżki żądania backendowego do bazowego magazynu danych wyszukiwania i analityki, bez ograniczania jej zawartości. Umożliwia to uwierzytelnionemu atakującemu podstawienie dowolnej ścieżki backendowej i użycie podwyższonych poświadczeń usługi aplikacji przeciwko niezamierzonym wewnętrznym punktom końcowym.

Interfejs przyjmujący przesyłanie plików od uwierzytelnionych użytkowników rozpakowuje zawartość przesłanych archiwów bez sprawdzenia, czy wyodrębnione ścieżki plików pozostają w docelowym katalogu. Umożliwia to uwierzytelnionemu atakującemu przygotowanie archiwum, którego wpisy wychodzą poza katalog docelowy, powodując zapis plików w dowolnych lokalizacjach z uprawnieniami tego procesu.

Interfejs transferu plików wymagający prawidłowych poświadczeń przyjmuje nazwy plików kontrolowane przez atakującego bez ograniczania metaznaków powłoki. Zautomatyzowany proces później konstruuje i uruchamia polecenie systemowe używając nazwy przesłanego pliku, co pozwala uwierzytelnionemu atakującemu osadzić i wykonać dowolne polecenia systemu operacyjnego z uprawnieniami tego procesu.

Interfejs webowy odzwierciedla część adresu URL żądania w kontekście skryptu oraz w atrybucie hiperłącza bez odpowiedniego kodowania, a dostęp do niego nie wymaga uwierzytelnienia. Umożliwia to nieuwierzytelnionemu atakującemu sieciowemu utworzenie linku, który po odwiedzeniu przez użytkownika wykonuje dowolny skrypt w kontekście aplikacji i może przekierować przeglądarkę na dowolną zewnętrzną stronę.

ZoneMinder w wersjach przed 1.36.39, 1.38.4 i 1.39.11 pozwala uwierzytelnionemu użytkownikowi o niskich uprawnieniach z gruboziarnistymi uprawnieniami Events=View i/lub Snapshots=View na bezpośrednie pobieranie mediów zdarzeń należących do monitorów, do których nie ma dostępu. Normalny interfejs ukrywa zastrzeżony monitor, ale bezpośrednie widoki mediów zdarzeń akceptują dowolny eid i strumieniują media bez egzekwowania ACL na poziomie zdarzenia/monitora.

Doco-CD to narzędzie GitOps do automatycznego wdrażania projektów Docker Compose i stosów Swarm. W wersjach przed 0.90.1 występuje błąd granicy zaufania w weryfikacji artefaktów OCI — konfiguracja wdrożenia zawarta w artefakcie (plik `.doco-cd.yml` z `oci.verify: false`) mogła wpływać na politykę weryfikacji tego samego artefaktu. Przy włączonej globalnej weryfikacji podpisów OCI (`OCI_TRUST_POLICY` z `enabled: true`) atakujący z prawem zapisu do tagu OCI mógł opublikować niepodpisany lub niepoprawnie podpisany artefakt, co prowadziło do obejścia weryfikacji podpisu i wdrożenia niezaufanej treści.

libde265 to otwartoźródłowa implementacja kodeka wideo H.265. Wersje przed 1.1.1 używają arytmetyki 32-bitowej ze znakiem do obliczania rozmiaru bufora wejściowego sample adaptive offset, co pozwala spreparowanemu strumieniowi HEVC o dużych wymiarach i 16-bitowych próbkach luma wywołać przepełnienie liczbowe, zbyt małą alokację i odczyt poza granicami sterty.

libde265 to otwartoźródłowa implementacja kodeka wideo H.265. Wersje przed 1.1.1 używają arytmetyki 32-bitowej ze znakiem do obliczania przesunięć pikseli, co pozwala spreparowanemu strumieniowi HEVC o dużych wymiarach obrazu wywołać przepełnienie liczbowe i odczyty lub zapisy poza granicami sterty.

Hoverfly w wersjach przed 1.12.8 używa http.DefaultClient bez konfiguracji limitu czasu dla zdalnych akcji post-serve. Gdy zdalny punkt końcowy jest nieosiągalny lub celowo powolny, każde wywołane żądanie proxy tworzy goroutine, która blokuje się na czas nieokreślony na http.DefaultClient.Do().