Katalog podatności CVE

W GitLab EE występuje luka pozwalająca uwierzytelnionemu użytkownikowi z dostępem do Duo Chat na uzyskanie konfiguracji Advanced Search oraz poufnych poświadczeń. Atakujący wykorzystuje specjalnie spreparowany argument subskrypcji GraphQL do obejścia serializacji i wykonania wyszukiwania obiektów serwera.

aiosmtplib przed wersją 5.1.3 nieprawidłowo waliduje adresy e-mail przekazywane przez wywołujących, umożliwiając atakującym wstrzyknięcie parametrów ESMTP do wierszy poleceń MAIL FROM i RCPT TO. Atakujący może spreparować adresy zawierające spacje i nawiasy kątowe, aby dołączyć parametry takie jak AUTH, NOTIFY lub ORCPT do poleceń koperty, fałszując uwierzytelnione tożsamości lub wymuszając powiadomienia o dostarczeniu do osób trzecich.

QloApps do wersji 1.7.0 renderuje parametry POST filtrów listy back-office do atrybutów value pól HTML bez ich escapowania w szablonie pomocnika listy. Atakujący może nakłonić uwierzytelnionych użytkowników do wysłania spreparowanych żądań POST ze złośliwymi ładunkami do kontrolerów listy, wykonując dowolny JavaScript w sesji ofiary w celu odczytu danych administracyjnych i wykonywania akcji.

starlette-admin w wersjach od 0.16.1 do 0.17.1 nie wymusza listy dozwolonych searchable_fields, gdy jest ona skonfigurowana jako pusta lista, co pozwala uwierzytelnionym użytkownikom filtrować pola nieprzeznaczone do wyszukiwania. Atakujący może wysyłać strukturalne zapytania filtrujące przez parametr where w API listy, aby wykonywać operacje równości i porównania na wykluczonych kolumnach.

stb_vorbis do wersji 1.22 zawiera przepełnienie bufora sterty w funkcji start_decoder(), gdzie rozmiar alokacji mnożników codebook jest obcinany z size_t do int. Atakujący może spreparować złośliwy plik Ogg Vorbis z dużymi wartościami entries i dimensions, wywołując zapisy poza zakresem bufora, co powoduje awarie procesu lub uszkodzenie sterty.

OpenStack Ironic w wersjach do 38.0.0 włącznie może wysłać nazwę użytkownika i hasło do nieoczekiwanego zdalnego hosta, gdy usługa Image Service jest skonfigurowana do uwierzytelniania HTTP(S) Basic. Poświadczenia mogą wyciec do niepowołanego odbiorcy.

W OpenStack Keystone przed wersją 29.0.3 tokeny uzyskane przez delegowane metody uwierzytelniania (poświadczenia EC2, poświadczenia aplikacji, tokeny dostępu OAuth1 i zaufania) nie są blokowane przed tworzeniem, modyfikowaniem i usuwaniem poświadczeń przez API /v3/credentials. Tokeny pochodne EC2 mogą dodatkowo odczytywać bloby poświadczeń, ujawniając ziarna TOTP MFA i inne sekrety. Ponadto PATCH /v3/credentials nie waliduje żądanego project_id po aktualizacji, co pozwala dowolnemu delegowanemu tokenowi przenieść poświadczenie do nieautoryzowanego projektu.

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.