Katalog podatności CVE

OpenAM przed wersją 16.1.3 zawiera podatność na nieprawidłową autoryzację, która pozwala delegowanym administratorom niszczyć sesje poza ich realmami, ponieważ sprawdzanie realm używa realmu żądającego. Uwierzytelnione konta z atrybutem iplanet-am-session-destroy-sessions mogą podać identyfikator lub uchwyt sesji, aby wylogować użytkowników w dowolnym realmie.

OpenAM przed wersją 16.1.3 zawiera podatność na obejście autoryzacji w operacji zapytania w REST endpoint sesji, która pozwala administratorom realm na listowanie sesji wszystkich realmów. Atakujący z uprawnieniami delegowanego RealmAdmin mogą podać _queryFilter wskazujący inny realm, aby ujawnić nazwy użytkowników, uniwersalne ID i uchwyty sesji poza granicami dzierżawców.

OpenAM przed wersją 16.1.3 stosuje wymuszanie PKCE dla OAuth2 Provider tylko do żądań autoryzacji, których response_type jest dokładnie 'code'. Kody wydane przez hybrydowe przepływy OpenID Connect (code token, code id_token, code token id_token) nie mają powiązanego challenge. Atakujący, który przechwyci taki kod, może go wymienić na tokeny publicznego klienta z dowolnym niepustym code_verifier.

OpenAM przed wersją 16.1.3 zawiera podatność na otwarte przekierowanie, która pozwala nieuwierzytelnionym atakującym przekierowywać użytkowników poprzez podanie niezweryfikowanego id_token_hint do endpointu /oauth2/connect/endSession. Atakujący mogą wskazać dowolnego klienta realm w sfałszowanym hincie, aby przekierować ofiary do dowolnego zarejestrowanego URI po wylogowaniu, co umożliwia phishing wykorzystujący zaufanie do hosta OpenAM.

OpenAM w wersji przed 16.1.3 zawiera podatność na wstrzyknięcie treści wiadomości e-mail, która pozwala nieuwierzytelnionym atakującym kontrolować treść powiadomień e-mail poprzez akcje forgotPassword i register na /json/{realm}/users. Atakujący mogą podać pola subject i message, aby wysyłać wiadomości phishingowe z skonfigurowanego adresu From organizacji lub wykorzystać register jako przekaźnik do dowolnych odbiorców.

OpenAM w wersji przed 16.1.3 zawiera ukrytą wadę cross-site scripting, która umieszcza komunikat SAML, stan przekaźnika i docelowy URL bez kodowania na stronie automatycznego przesyłania pliku cookie load-balancera. Jeśli strona jest osiągalna przy włączonym cookieHashRedirectEnabled, spreparowane żądania mogą wykonać skrypt w origin OpenAM, choć niezwiązany błąd HTTP 500 uniemożliwia wykorzystanie w wydanych wersjach.

OpenAM przed wersją 16.1.3 zawiera podatność na nieuwierzytelnioną instancjację dowolnych klas w starszym interfejsie JAX-RPC SOAP. Zdalny atakujący może wysyłać żądania SOAP do /jaxrpc/* z niezweryfikowanym identyfikatorem sesji i wybraną nazwą klasy, co może doprowadzić do awarii serwera, badania classpath lub potencjalnie wykonania kodu.

OpenAM w wersji przed 16.1.3 zawiera podatność na odbity cross-site scripting, która pozwala nieuwierzytelnionym atakującym wstrzyknąć skrypt poprzez dostarczenie spreparowanych parametrów renderowanych bez kodowania na stronie błędu autoryzacji OAuth2. Atakujący mogą zwabić ofiary do spreparowanego linku /oauth2/authorize z powtórzonymi parametrami, aby uruchomić JavaScript w origin OpenAM, działając w istniejących sesjach lub przekierowując do stron phishingowych.

Nezha Dashboard od wersji 1.8.0 do 2.3.13 zawiera podatność na nieprawidłowe blokowanie, gdzie nieodroczone zwolnienie mutexa powoduje wyciek na ścieżce paniki nil-map. Każdy uwierzytelniony użytkownik niebędący administratorem może wykonać cztery wywołania API powiadomień, aby trwale zablokować podsystem alertów, a następnie wyczerpać pamięć blokującymi żądaniami.

Nezha od wersji 1.8.0 do 2.3.13 zawiera odwrócenie kolejności blokad w UpdateGroup i DeleteGroup, które pozwala uwierzytelnionym użytkownikom niebędącym administratorami zablokować podsystem alertów. Atakujący mogą równocześnie wywoływać punkty końcowe grup powiadomień i masowego usuwania z nadmiernie dużymi listami identyfikatorów, aby poszerzyć wyścig i zamknąć cykl ABBA, trwale zabijając dostarczanie alertów do restartu.

Brak uwierzytelniania dla krytycznej funkcji w brokerze telemetrii i komend ait-server w NASA-AMMOS AIT-Core do wersji 3.1.1. Nieuwierzytelniony zdalny atakujący z dostępem do magistrali ZeroMQ może wstrzykiwać dane komend statku kosmicznego, wyciągać ruch komend i telemetrii, wstrzykiwać sfałszowaną telemetrię lub zakłócać działanie magistrali. Domyślnie gniazda XSUB i XPUB są powiązane ze wszystkimi interfejsami sieciowymi bez uwierzytelniania.

W Linux Mint Xreader do wersji 4.6.9 funkcja g_file_get_child w pliku shell/ev-window.c (obsługa zapisu załączników PDF) jest podatna na path traversal poprzez manipulację argumentem attachment. Atak może być przeprowadzony zdalnie, a exploit został publicznie ujawniony.

W Bouncy Castle for Java przed 1.86 (oraz LTS przed 2.73.13) rodziny PBES1 i PKCS#12 PBE używały liczby iteracji pochodzącej z niezaufanych danych wejściowych bez ograniczenia, co pozwalało na wymuszenie dowolnie dużego nakładu pracy. Poprawka odrzuca ujemną lub przekraczającą limit liczbę iteracji (domyślnie 10 000 000) na podstawie właściwości org.bouncycastle.pbe.max_iteration_count.

W Bouncy Castle dla Java przed wersją 1.86 stwierdzono podatność polegającą na akceptowaniu obciętych wiadomości OpenPGP bez zgłaszania błędu. W ścieżce SEIPD wersji 1 nie przeprowadzano żadnej kontroli integralności, a w ścieżce AEAD (SEIPD v2 i v5) pomijano tag uwierzytelniający, co skutkowało cichym odrzuceniem pakietów po literale. Problem dotyczy również wersji LTS przed 2.73.13 oraz FIPS (BC-FJA) przed wskazanymi wersjami, ale tylko w ścieżce AEAD.

W Bouncy Castle dla Java przed wersją 1.86, opcjonalna walidacja rozmiaru klucza dla odbiorców CMS key-transport (JceKeyTransRecipient.setKeySizeValidation(true)) nie działała dla wiadomości używających RFC 9709 (id-alg-cek-hkdf-sha256). Błąd w porównaniu (tablica bajtów z OID) powodował pominięcie sprawdzenia rozmiaru klucza, przez co akceptowano klucze o niewłaściwym rozmiarze. Problem dotyczy również BC-FJA przed bcpkix-fips 2.0.13 i 2.1.13.

W bibliotece Bouncy Castle for Java przed wersją 1.86 funkcja BLS12_381BasicScheme.keyValidate akceptowała klucze publiczne zbudowane na obcej krzywej ECC, która jedynie dzieli charakterystykę pola z BLS12-381. Pozwalało to na weryfikację zagregowanych podpisów zawierających fałszywego sygnatariusza, mimo braku podpisu dla danej pary klucz-wiadomość.

W Bouncy Castle for Java przed wersją 1.86 walidacja listy propozycji w zewnętrznym commicie MLS (RFC 9420) nie sprawdzała, czy usuwany liść faktycznie należy do dołączającego. Brak tej weryfikacji pozwalał każdej osobie posiadającej publiczne GroupInfo grupy na wysłanie commitu z propozycją Remove wskazującą dowolnego członka, co skutkowało jego usunięciem i przejęciem jego miejsca w drzewie ratchet. Poprawka wymusza zgodność poświadczenia usuwanego liścia z poświadczeniem nowego liścia dołączającego po obu stronach.

W Bouncy Castle dla Java przed wersją 1.86, obie kopie klasy PKIXCertPathReviewer (org.bouncycastle.pkix.jcajce oraz starsza org.bouncycastle.x509) nie stosowały ograniczeń nazw X.509 do certyfikatu końcowego (liścia). Sprawdzenie checkNameConstraints pomijało indeks zero (certyfikat docelowy), przez co testy poddrzew dozwolonych i wykluczonych z RFC 5280 sek. 6.1.3 (b) i (c) nie były wykonywane dla nazwy subject DN i subjectAltName liścia. W rezultacie łańcuch z naruszonymi ograniczeniami nazw był raportowany jako prawidłowy (isValidCertPath() zwracało true z pustą listą błędów), podczas gdy CertPathValidator odrzucał ten sam łańcuch.

W Bouncy Castle for Java przed wersją 1.86 parser strumieniowy CMS AuthenticatedData akceptował komunikaty, w których pola digestAlgorithm i authAttrs były niespójne co do obecności uwierzytelnionych atrybutów. Parser podejmował decyzję na podstawie samego digestAlgorithm, przez co mógł zweryfikować MAC treści i zwrócić atrybuty przez getAuthAttrs() jako uwierzytelnione, mimo że MAC nigdy ich nie obejmował. Problem dotyczy również wersji LTS przed 2.73.13 oraz wydań FIPS (BC-FJA) przed odpowiednimi wersjami bcpkix-fips i bcutil-fips.

W Bouncy Castle for Java przed wersją 1.86 wysokopoziomowe API OpenPGP akceptowało podpis danych wykonany przez podklucz podpisujący, którego sygnatura wiążąca podklucz nie zawierała osadzonej sygnatury Primary Key Binding (cross-certification), gdy w tej sygnaturze pominięto podpakiet Key Flags. Metoda isSigningKey() dziedziczyła flagi SIGN_DATA z klucza głównego, podczas gdy verifyEmbeddedPrimaryKeyBinding() odczytywała tylko podpakiety sygnatury wiążącej i uznawała podklucz za niepodpisujący, przez co ten sam podklucz był jednocześnie zdolny do podpisywania i zwolniony z wymogu cross-certification.