Katalog podatności CVE

Ech0 do wersji 4.5.6 zawiera podatność w walidacji URI przekierowania OAuth w funkcji parseAndValidateClientRedirect (internal/service/auth/auth.go), która porównuje tylko schemat i host URI redirect_uri dostarczonego przez klienta z listą dozwoloną skonfigurowaną przez administratora, ignorując ścieżkę, zapytanie i fragment. redirect_uri jest osadzane w podpisanym JWT stanu podczas logowania bez walidacji. Atakujący może skonstruować redirect_uri, którego host pasuje do dozwolonego pochodzenia, ale ścieżka jest kontrolowana przez atakującego; po wymianie OAuth ofiara jest przekierowywana na tę ścieżkę z jednorazowym kodem wymiany w ciągu zapytania. Jeśli kod wycieknie (np. przez Referer, analitykę lub otwarte przekierowanie na tym hoście), atakujący może go wymienić na publicznym punkcie końcowym POST /api/auth/exchange na tokeny dostępu i odświeżania ofiary. Poprawiono w wersji 4.7.3.

Ech0 przed wersją 4.7.3 zawiera podatność na podrabianie żądań po stronie serwera (SSRF) w funkcji fetchPeerConnectInfo, która używa niezweryfikowanych żądań HTTP zamiast bezpiecznych metod z walidacją URL. Uwierzytelnieni atakujący mogą podać dowolne adresy URL, aby uzyskać dostęp do wewnętrznych usług i punktów końcowych metadanych chmury, wyzwalając kontrole stanu połączenia lub operacje połączenia peer.

Ech0 przed wersją 5.0.1 nie nakłada żadnych ograniczeń na rozmiar lub kształt nagłówka Accept-Language przetwarzanego przez oprogramowanie pośrednie i18n, które działa na każdym żądaniu HTTP. Nagłówek jest przekazywany bez filtrowania do NewLocalizer z go-i18n, który wewnętrznie wywołuje golang.org/x/text/language.ParseAcceptLanguage. Obejście CVE-2022-32149 w x/text ogranicza znaki '-', ale nie znaki '_', które parser aliasuje do '-', umożliwiając wyzwolenie parsowania o złożoności kwadratowej przy użyciu dużego nagłówka (do domyślnego 1 MiB Go) zbudowanego z separatorów podkreślenia. Nieuwierzytelniony atakujący może wysyłać takie żądania, aby zużywać około 1,5 sekundy CPU każde, a równoczesne żądania mogą nasycić serwer wielordzeniowy (odmowa usługi).

Rozszerzenie Joomla - yootheme.com - Uwierzytelnione, uprzywilejowane przechowywane XSS w YOOtheme Pro 1.0.0-5.0.41 - Brak escapowania w niestandardowym polu lokalizacji prowadzi do wektora XSS.

Wtyczka ShopEngine dla WordPressa do WooCommerce jest podatna na eskalację uprawnień w wersjach do 4.9.4 włącznie. Funkcja `rum_importer()` jest zarejestrowana na haku `import_start` bez odpowiedniej kontroli uprawnień, co pozwala uwierzytelnionym atakującym z dostępem na poziomie Shop Managera na zapis dowolnych opcji WordPressa, w tym ustawienie `users_can_register` na 1 i `default_role` na administratora, co umożliwia rejestrację kont administratora i przejęcie całej witryny.

Wtyczka All-in-One WP Migration and Backup dla WordPressa jest podatna na iniekcję SQL w funkcji przywracania archiwum w wersjach do 7.109 włącznie, z powodu niewystarczającego escapowania parametrów i braku przygotowania zapytań. Umożliwia to nieuwierzytelnionym atakującym dołączanie dodatkowych zapytań SQL, co może prowadzić do wyodrębnienia wrażliwych informacji z bazy danych, w tym klucza `ai1wm_secret_key`, a następnie do zdalnego wykonania kodu.

Niewłaściwe obsługiwanie wielkości liter (CWE-178) w kontroli autoryzacji strefy tożsamości w Identity Zone Endpoint w Cloud Foundry UAA pozwala zdalnemu uwierzytelnionemu atakującemu posiadającemu tylko uprawnienie zones.write na ominięcie zamierzonego ograniczenia, że to uprawnienie nie daje dostępu do uprzywilejowanej strefy tożsamości uaa (system), poprzez odwoływanie się do identyfikatora strefy w formie innej niż małe litery (np. UAA) w ścieżce i treści żądania. Warstwa autoryzacji wykonuje porównanie uwzględniające wielkość liter z identyfikatorem strefy systemowej, podczas gdy warstwa trwałości MySQL rozwiązuje identyfikatory bez uwzględniania wielkości liter przy domyślnej kolacji, więc żądanie jest autoryzowane nieprawidłowo, a następnie rozwiązywane względem rzeczywistego rekordu strefy systemowej. Pozwala to atakującemu nadpisać klucz podpisywania JWT strefy systemowej materiałem kontrolowanym przez atakującego, sfałszować JWT z zakresami klienta admin i administratora oraz w pełni skompromitować UAA i każde wdrożenie Cloud Foundry, które mu ufa. Problem dotyczy tylko wdrożeń UAA korzystających z MySQL z domyślną kolacją; backendy PostgreSQL i HSQLDB nie są dotknięte.

W Apache Hive w wersjach 4.0.0 do 4.2.0 (oraz w późniejszych nieopublikowanych gałęziach) występuje podatność nieprawidłowego uwierzytelniania w walidacji tokenów SAML bearer w HiveServer2, gdy używany jest transport HTTP z hive.server2.authentication=SAML. Nieuwierzytelniony atakujący sieciowo może podszyć się pod dowolnego użytkownika Hive i uzyskać uwierzytelnioną sesję HiveServer2 poprzez sfałszowany nagłówek Authorization: Bearer wysłany do endpointu /cliservice. Zalecane jest uaktualnienie do wersji 4.2.1.

Podatność na odmowę usługi (DoS) w wewnętrznej implementacji dekodowania JPEG2000 (JPX) w forku Poppler opracowanym przez Innodata Labs. Gdy aplikacja przetwarza niezaufany plik PDF zawierający specjalnie spreparowane obrazy JPXDecode, zdalny atakujący może spowodować niekontrolowane zużycie pamięci. Błąd występuje w funkcji JPXStream::readCodestream(), gdzie wartości kontrolowane z segmentu SIZ (takie jak img.nComps) są używane do alokacji pamięci dla kafelków i komponentów bez odpowiedniej walidacji. Pozwala to atakującemu wymusić nadmierną alokację pamięci i spowodować wyczerpanie zasobów, co ostatecznie powoduje zakończenie procesu pdftoppm z powodu braku pamięci (OOM).

Uwierzytelnianie Polkit oparte na UnixProcessSubject / Peer PID w LACT na systemie Linux umożliwia obejście uwierzytelniania. Problem dotyczy LACT do wersji 0.10.0 włącznie. Poprawka została wprowadzona w commicie d0478fe42c2219454e272f96b1cbd29ab37ee566.

W Apache DolphinScheduler przed wersją 3.4.2 zwykły użytkownik może wygenerować tokeny dostępu administratora poprzez endpoint /access-tokens. Zalecane jest uaktualnienie do wersji 3.4.2, która naprawia ten problem.

hbs to silnik widoków Express, który opakowuje Handlebars. Jego API registerAsyncHelper omija automatyczne kodowanie HTML w Handlebars: asynchroniczny helper zwraca nieprzezroczysty placeholder podczas pierwszego przebiegu renderowania, więc wyrażenie w podwójnych nawiasach koduje tylko placeholder, a po renderowaniu hbs zastępuje placeholder surową wartością zwrotną callbacka bez kodowania jej. Aplikacja przekazująca dane wpływane przez atakującego, np. treści dostarczane przez użytkownika z bazy danych, do callbacka asynchronicznego helpera, może mieć wstrzyknięty dowolny HTML i JavaScript do strony renderowanej po stronie serwera, co prowadzi do przechowywanego lub odbitego XSS. Wersje 2.1.0 do 4.2.1 są dotknięte, a problem jest naprawiony w 4.3.0, które koduje HTML w wynikach asynchronicznych helperów.

W dotkniętych wersjach platformy Codefresh uwierzytelniony użytkownik może wykorzystać endpoint API do podniesienia swoich uprawnień do poziomu administratora.

Kontroler zaproszeń w rozszerzeniu nie przerywa przetwarzania po przekierowaniu na nieprawidłowe dane wejściowe (brak hasha, nieistniejący, wyłączony lub usunięty użytkownik), co pozwala nieuwierzytelnionemu atakującemu ustawić nowe hasło i ponownie włączyć dowolne istniejące konto użytkownika frontendu. Podatność występuje tylko w wersjach 8.x rozszerzenia.

Kontrola uprawnień dla przepływu aktualizacji zarządzania frontendem weryfikowała inne zdarzenie niż to, które żądanie następnie modyfikowało. Użytkownik z dostępem do zarządzania zdarzeniami frontendu mógł więc modyfikować zdarzenia należące do innych organizatorów.

Wtyczka zarządzania frontendem przypisywała nowo utworzone zdarzenie do rekordu organizatora przesyłającego użytkownika tylko wtedy, gdy żądanie nie dostarczyło własnego organizatora. Towarzysząca kontrola uprawnień potwierdzała tylko, że przesyłający użytkownik posiada jakąkolwiek rolę organizatora. Użytkownik z dostępem do zarządzania zdarzeniami frontendu mógł więc utworzyć zdarzenie przypisane do innego organizatora.

Przepływ edycji tematów na froncie nie weryfikuje po stronie serwera, czy odwiedzający jest właścicielem modyfikowanego tematu. Osoba znająca identyfikator tematu z publicznego forum może wysłać bezpośrednio zmodyfikowane żądanie aktualizacji i nadpisać jego treść bez potwierdzenia własności. Identyfikatory tematów są widoczne publicznie, a wykorzystanie nie wymaga uprzywilejowanego dostępu ani niestandardowej konfiguracji.

Funkcja samoobsługowej edycji firm na froncie opiera się na fladze widoczności na poziomie szablonu, aby ukryć formularz edycji dla rekordów firm, których odwiedzający nie posiada, ale operacja zapisu nie powtarza tego sprawdzenia własności po stronie serwera. Osoba znająca identyfikator rekordu firmy z publicznego katalogu może wysłać bezpośrednio zmodyfikowane żądanie aktualizacji i nadpisać dane bez potwierdzenia własności.

Rozszerzenie rozwiązuje docelowy rekord klubu na podstawie argumentu żądania dostarczonego przez użytkownika w akcjach edycji, aktualizacji i aktywacji na froncie, ale nie wykonuje żadnego sprawdzenia własności w żadnej z nich. Nieuwierzytelniony odwiedzający, znający UID rekordu klubu, może wysłać bezpośrednie żądanie do akcji aktualizacji lub aktywacji i nadpisać ten rekord lub opublikować rekord oczekujący na zatwierdzenie, bez posiadania go.

Rozszerzenie weryfikuje HMAC linku edycji pracownika na froncie tylko w akcji renderującej formularz edycji, a nie w akcji zapisującej zmianę. Nieuwierzytelniony odwiedzający, znający UID widocznego rekordu pracownika, może wysłać bezpośrednie żądanie POST do akcji aktualizacji i nadpisać ten rekord bez ważnego linku edycji lub jakiegokolwiek sprawdzenia własności.