Katalog podatności CVE

Na dotkniętych platformach z Arista EOS i skonfigurowanym SNMP poświadczenia użytkowników lokalnych lub zdalnych SNMPv3 mogą być ujawnione jako jednokierunkowa, zahaszowana, zlokalizowana wartość klucza w konfiguracji urządzenia (running i sanitized). Uwierzytelniony użytkownik z dostępem do tych informacji może wykorzystać je do nieautoryzowanych operacji odczytu tabel SNMP lub wysyłania fałszywych powiadomień trap do systemu NMS.

Na dotkniętych platformach z Arista EOS i skonfigurowanym OSPFv3 nieuwierzytelniony atakujący w tej samej domenie rozgłoszeniowej OSPFv3 może wysłać specjalnie spreparowany zestaw pakietów powodujący nieoczekiwany restart agenta Ospf3. Awaria powoduje utratę wszystkich sąsiedztw OSPFv3 na urządzeniu i może zakłócić routing w całej domenie OSPF do czasu odzyskania agenta.

Na dotkniętych platformach z Arista EOS i skonfigurowanym OSPFv2 oraz segment routing OSPFv2 specjalnie spreparowany pakiet OSPFv2 od sąsiedniego routera OSPF może spowodować nieoczekiwany restart OSPF.

Na dotkniętych platformach z Arista EOS uwierzytelniony użytkownik z dostępem do gNMI (gRPC Network Management Interface) może otrzymać nieprawidłowe wyniki autoryzacji, co potencjalnie pozwala na dostęp wykraczający poza aktualnie przypisane uprawnienia.

W fastify przed wersją 5.12.5, gdy trasa rejestruje nagłówek trailer przez reply.trailer() i jest obsługiwana przez HTTP/2, fastify bezwarunkowo ustawia nagłówek Transfer-Encoding: chunked, co jest zabronione w HTTP/2, powodując błąd Node.js podczas serializacji nagłówków odpowiedzi. Wyjątek nie jest przechwytywany i staje się uncaughtException, więc pojedyncze nieuwierzytelnione żądanie HTTP/2 do dowolnej trasy używającej trailerów powoduje awarię serwera i porzucenie wszystkich bieżących żądań; można to powtarzać po każdym restarcie. Problem naprawiono w fastify 5.12.5.

W ZenHive mpp przed wersją 0.16.2, użycie pamięci podręcznej zawierającej wrażliwe informacje pozwala współdzielonej pamięci podręcznej HTTP przechowywać płatną odpowiedź i serwować ją klientom, którzy nie zapłacili. MPP.Plug.verify_credential ustawia nagłówki payment-receipt i cache-control: private, ale aplikacja montująca może je nadpisać, np. ustawiając cache-control: public, co pozwala CDN lub reverse proxy na przechowywanie płatnej odpowiedzi i serwowanie jej niepłacącym klientom. Dodatkowo, nie-2xx odpowiedzi mogą nadal zawierać Payment-Receipt.

W ZenHive mpp przed wersją 0.16.2, nieprawidłowa walidacja równoważności w danych wejściowych pozwala nieuwierzytelnionemu zdalnemu klientowi przejść bramę duplikatów Tempo dwukrotnie z jednym podpisanym transakcją. MPP.Methods.Tempo rezerwuje slot deduplikacji na podstawie hex dostarczonego przez wywołującego, a nie kanonicznej formy transakcji, co pozwala na dwa różne klucze rezerwacji dla tej samej transakcji (np. v=27 i v=0). W rezultacie oba przechodzą rezerwację i trafiają do ścieżki broadcast, a węzeł może zwrócić drugi ważny Payment-Receipt za jedną płatność on-chain.

W providerze Apache Airflow Akeyless backend sekretów można obejść zabezpieczenie zakresu zespołu za pomocą klucza kontrolowanego przez użytkownika. Autor DAG przypisany do jednego zespołu może podać klucz zmiennej zawierający separator ścieżki, co powoduje odczyt sekretu należącego do innego zespołu.

W Ash przed wersją 3.33.4, polityki pól (field_policies) mają chronić przed ujawnianiem informacji przez filtry, ale nilling (zastępowanie wartością nil) był stosowany tylko do atrybutów, nie do obliczeń (calculations) ani agregatów (aggregates). Użytkownik może odwołać się w filtrze do obliczenia lub agregatu, którego nie może zobaczyć, i użyć filtra jako wyroczni do odczytania chronionej wartości (np. filter(secret_calc == "x")).

NLnet Labs Unbound do wersji 1.26.0 jest podatny na ataki typu algorithmic complexity (znane jako 'ReTrap'), które powodują degradację usługi. Ataki obejmują TagTrap (duża liczba niedopasowanych rekordów DNSKEY, RRSIG, DS), DelegationTrap (kosztowna iteracyjna walidacja dla głęboko zagnieżdżonych domen), NsecTrap (nadmiarowe nieprawidłowe rekordy NSEC) oraz AdditionalTrap (domyślna walidacja sekcji ADDITIONAL).

NLnet Labs Unbound od wersji 1.12.0 do 1.26.0 ma podatność use-after-free, gdy jest skompilowany z obsługą DNS-over-HTTPS (--with-libnghttp2). W ścieżkach błędów (np. RPZ drop, jostle) porzucony strumień DoH powoduje awarię całej sesji DoH i nie uwzględnia innych strumieni, prowadząc do use-after-free. Atakujący może to wywołać pojedynczym połączeniem DoH, ale wpływ jest ograniczony, ponieważ odczyty nie są kontrolowane przez użytkownika; jednak zahartowany alokator może wykryć błąd i kontrolowanie zakończyć proces, powodując DoS.

W NLnet Labs Unbound do wersji 1.26.0 występuje podatność na degradację usługi w procedurze odczytu TCP/DoT, gdzie nie ma limitu kolejnych odczytów. Złośliwy aktor, który może przesyłać strumieniowo i utrzymywać tempo odrębnych niebuforowanych nazw przez połączenie TCP/DoT, monopolizuje całą pętlę zdarzeń pojedynczego pracownika, dopóki jego zapisy wyprzedzają opróżnianie.

NLnet Labs Unbound od wersji 1.22.0 do 1.26.1 ma podatność use-after-free, gdy jest skompilowany z obsługą DNS-over-QUIC (--with-libngtcp2). Każdy strumień DoQ posiada bufor wyjściowy z odpowiedzią DNS, a bufor retransmisji ngtcp2 przechowuje płytki wskaźnik do tego bufora. Po RESET_STREAM od klienta bufor wyjściowy jest zwalniany, ale ngtcp2 nadal trzyma wpisy retransmisji, co prowadzi do użycia zwolnionej pamięci przy następnym PTO. Atakujący bez uprawnień może to osiągnąć, wysyłając zapytania DoQ, wstrzymując ACK, wysyłając RESET_STREAM i czekając na PTO, co prowadzi do nieprawidłowego zakończenia serwera.

W NLnet Labs Unbound od wersji 1.13.2 do 1.26.1, w strefach z włączonym ZONEMD (zonemd-check: yes) znajdujących się poniżej kotwicy zaufania, istnieje okno ataku, w którym (sfałszowane) zawartości strefy są serwowane (lub zapisywane na dysk) przed zakończeniem kontroli integralności ZONEMD. Jest to spowodowane asynchroniczną rozwiązywaniem DS/DNSKEY, które musi nastąpić przed kontrolą ZONEMD. Jeśli plik strefy jest zapisany na dysk podczas nieudanej kontroli, sfałszowane dane są ponownie ładowane przy starcie i dostępne do czasu zakończenia weryfikacji ZONEMD.

Na platformach Arista EOS, gdy skonfigurowano wiele transportów gRPC Network Security Interface (gNSI), występuje wyścig w usłudze gNSI Authz, który może spowodować ciche niepowodzenie rotacji polityk. Uwierzytelniony użytkownik, którego dostęp został cofnięty przez nową politykę, może zachować nieautoryzowany dostęp do interfejsów gRPC. Problem nie dotyczy Bootz. Został wykryty wewnętrznie przez Arista, brak doniesień o złośliwym wykorzystaniu.

Na platformach Arista EOS problem z gRPC Network Security Interface (gNSI) Authz Rotate RPC może spowodować, że nieprawidłowa polityka Authz przesłana w trwającym strumieniu RPC stanie się aktywna. Problem nie dotyczy Bootz. Został odkryty wewnętrznie przez Arista, a firma nie zna żadnych złośliwych wykorzystań tego problemu w sieciach klientów.

W bibliotece jwcrypto funkcja JWK.import_key() waliduje członka key_ops JWK pod kątem zduplikowanych wartości przy użyciu algorytmu o złożoności czasowej O(n^2), a długość key_ops nie jest ograniczona. Zdalny, nieuwierzytelniony atakujący może dostarczyć JWK z dużą tablicą key_ops do aplikacji, która przekazuje kontrolowane przez atakującego materiały klucza do publicznego API importu klucza (osiągalnego m.in. przez uzgadnianie klucza ECDH-ES, dynamiczną rejestrację klienta OIDC, DPoP lub rejestrację klucza konta ACME), co powoduje nadmierne zużycie CPU i prowadzi do odmowy usługi.

Podatność zidentyfikowano w interfejsie webowym WTV676-HB6035 (wszystkie wersje < V3.94) oraz WTV776-HB6035 (wszystkie wersje < V4.17). Urządzenia nie walidują poprawnie danych wejściowych otrzymywanych z usług zaplecza. Może to pozwolić nieuwierzytelnionemu zdalnemu atakującemu na zmuszenie urządzenia do trybu ochronnego, co skutkuje utratą zdalnych funkcji łączności (Web Access).

GitLab naprawił problem w GitLab EE dotyczący wszystkich wersji od 17.1 przed 19.1.8, 19.2 przed 19.2.6 i 19.3 przed 19.3.2, który w określonych warunkach mógł pozwolić uwierzytelnionemu użytkownikowi z uprawnieniami Owner lub Maintainer na ciche wyłączenie wymagań zatwierdzania wdrożeń w środowiskach chronionych, umożliwiając niezatwierdzone wdrożenia do produkcji, z powodu nieprawidłowej kontroli dostępu po modyfikacji chronionego zasobu.

QND używa zaszytego na stałe klucza kryptograficznego, co może pozwolić lokalnemu atakującemu zalogowanemu na komputerze z systemem Windows, na którym zainstalowany jest klient produktu, na uzyskanie poświadczeń administratora, w tym identyfikatora i hasła.