Katalog podatności CVE

Podatność w weryfikatorze syscall RTIO w Zephyr RTOS (przed v4.3.0) pozwala nieuprzywilejowanemu wątkowi użytkownika zapisać wskaźnik do kontrolowanych danych pod dowolnym adresem jądra. Brakuje sprawdzenia K_SYSCALL_MEMORY_WRITE dla parametru wyjściowego handle, co umożliwia eskalację uprawnień do trybu jądra.

W frameworku Laravel przed wersjami 12.69.0 i 13.30.0 strony debugowania wyjątków przy włączonym APP_DEBUG przekazują dane kontrolowane przez atakującego do podpowiedzi Tippy.js skonfigurowanej z allowHTML=true. Umożliwia to atak DOM-based cross-site scripting, gdy użytkownik najedzie kursorem na podpowiedź.

Biblioteka brace-expansion generuje dowolne ciągi znaków zawierające wspólny prefiks i sufiks. W wersjach przed 1.1.20, 2.1.6, 3.0.8 i 5.0.11 głęboko zagnieżdżone grupy nawiasów powodują, że expand_() rekursuje raz na poziom zagnieżdżenia w miejscach rozwinięcia elementów oddzielonych przecinkami i pojedynczych zestawów, wyczerpując natywny stos zanim limity wyjściowe mogą zostać zastosowane, potencjalnie kończąc proces Node.js. expand_ wykonuje niekontrolowaną rekurencję dla zagnieżdżonych alternatyw nawiasów i zestawów jednoczęściowych. głęboko zagnieżdżone grupy nawiasów dostarczone jako niezaufany wzorzec. expand_ jest dotknięty. expand jest dotknięty. Elementy oddzielone przecinkami są dotknięte. Pojedynczy zestaw jest dotknięty. wyczerpanie natywnego stosu podczas zagnieżdżonego podrozwinięcia. odmowa usługi kończąca proces. Problem został naprawiony w wersjach 1.1.20, 2.1.6, 3.0.8 i 5.0.11.

Biblioteka brace-expansion generuje dowolne ciągi znaków zawierające wspólny prefiks i sufiks. W wersjach przed 1.1.21, 2.1.7, 3.0.9 i 5.0.12 funkcja expand obsługuje niezaufane wzorce w kształcie {a},b} z wieloma końcowymi nawiasami zamykającymi, restartując skanowanie raz dla każdego końcowego nawiasu. Kolejne pełne rescany wejścia z liniowym wzrostem ciągu roboczego powodują kwadratowy czas CPU i presję na pamięć, co może zablokować pętlę zdarzeń Node.js.

Biblioteka brace-expansion generuje dowolne ciągi znaków na podstawie wspólnego prefiksu i sufiksu. W wersjach przed 1.1.19, 2.1.5, 3.0.7 i 5.0.10 specjalnie spreparowane wzorce nawiasów klamrowych mogą wyczerpać natywny stos w funkcji parseCommaParts, ponieważ funkcja ta rekurencyjnie przetwarza resztę raz na każdą grupę nawiasów oraz używa push.apply do przekazania wszystkich elementów bardzo dużej tablicy jako argumentów funkcji. Może to doprowadzić do zakończenia procesu Node.js w wyniku ataku typu denial of service.

PyJWT to implementacja standardów JSON Web Token w Pythonie. Od wersji 2.1.0 do 2.15.0 metoda OKPAlgorithm.from_jwk w jwt/algorithms.py jest podatna, ponieważ ścieżka importu prywatnego JWK nie porównuje klucza publicznego wyprowadzonego z d z x. Ma to miejsce, gdy prywatny JWK OKP dostarcza nieodpowiadające sobie komponenty x i d. W rezultacie tożsamość wyprowadzona z x może różnić się od operacji wykonywanych z d.

PyJWT to implementacja standardów JSON Web Token w Pythonie. Od wersji 2.9.0 do 2.14.0 PyJWKSet nie przechwytuje zwykłego ValueError zgłaszanego dla błędnych komponentów RSA JWK przez RSAAlgorithm.from_jwk w jwt/api_jwk.py. Ma to miejsce, gdy zestaw JWK zawiera błędny klucz RSA obok innych użytecznych kluczy. W rezultacie jeden błędny element przerywa konstrukcję całego PyJWKSet.

PyJWT to implementacja standardów JSON Web Token w Pythonie. Od wersji 2.13.0 do 2.14.0 funkcja HMACAlgorithm.prepare_key jest podatna, ponieważ ochrona klucza HMAC rozpoznaje tylko publiczne formy JWK najwyższego poziomu i pomija reprezentacje kontenerowe. Gdy aplikacja zezwala na algorytmy HMAC i asymetryczne oraz przekazuje publiczny kontener JWK jako surowy klucz, publiczny materiał klucza asymetrycznego jest akceptowany jako sekret HMAC. W rezultacie atakujący znający klucz publiczny może sfałszować token z dowolnymi uwierzytelnionymi oświadczeniami.

PyJWT to implementacja standardów JSON Web Token w Pythonie. Od wersji 2.13.0 do 2.14.0 funkcja HMACAlgorithm.prepare_key w jwt/algorithms.py jest podatna, ponieważ detektor surowego JWK nie normalizuje akceptowanych znaczników kolejności bajtów Unicode przed sprawdzeniem JSON. Gdy publiczny JWK jest poprzedzony BOM UTF-8 i używany w ścieżce weryfikacji mieszanej algorytmami, publiczny JWK omija wykrywanie klucza asymetrycznego i staje się sekretem HMAC. W rezultacie atakujący znający klucz publiczny może sfałszować uwierzytelnione tokeny.

PyJWT to implementacja standardów JSON Web Token w Pythonie. Od wersji 2.4.0 do 2.14.0 funkcja HMACAlgorithm.prepare_key jest podatna, ponieważ ochrona klucza asymetrycznego opiera się na znacznikach tekstowych nieobecnych w kodowaniu DER. Gdy aplikacja miesza algorytmy HMAC i asymetryczne oraz dostarcza publiczny klucz DER jako wspólny klucz weryfikacyjny, PyJWT używa publicznych bajtów DER jako sekretu HMAC. W rezultacie atakujący znający klucz publiczny może sfałszować uwierzytelnione tokeny HMAC.

PyJWT to implementacja standardów JSON Web Token w Pythonie. W wersjach przed 2.14.0 funkcja is_pem_format jest podatna, ponieważ leniwe wyrażenie regularne PEM wykonuje rozległe cofanie (backtracking). Ma to miejsce, gdy dane wejściowe przypominające certyfikat zawierają powtarzające się znaczniki BEGIN bez pasującego znacznika END. W rezultacie is_pem_format wykonuje nieograniczone cofanie w poszukiwaniu znacznika końca PEM.

PyJWT to implementacja standardów JSON Web Token w Pythonie. W wersjach przed 2.14.0 segment podpisu PyJWT jest podatny, ponieważ dekodowanie segmentu podpisu akceptuje znaki spoza kanonicznej reprezentacji Base64URL. Ma to miejsce, gdy znaki niebędące Base64URL są dołączane do prawidłowego segmentu podpisu kompaktowego JWS. W rezultacie base64url_decode produkuje te same bajty podpisu dla różnych serializowanych segmentów.

PyJWT to Pythonowa implementacja standardów JSON Web Token. Przed wersją 2.14.0 funkcja is_pem_format w jwt/utils.py nie rozpoznaje wszystkich reprezentacji PEM akceptowanych przez loader cryptography. Gdy aplikacja miesza algorytmy HMAC i asymetryczne oraz dostarcza zmutowany klucz publiczny PEM jako surowe bajty klucza, HMACAlgorithm.prepare_key traktuje nierozpoznany klucz publiczny jako sekret HMAC. Atakujący znający klucz publiczny może sfałszować uwierzytelnione tokeny HMAC. Problem naprawiono w wersji 2.14.0.

PyJWT to implementacja standardów JSON Web Token w Pythonie. W wersjach przed 2.14.0 komponent PyJWKClient jest podatny, ponieważ miejsca docelowe przekierowań nie są ponownie weryfikowane względem granicy zaufania JWKS. Gdy skonfigurowany zaufany punkt końcowy JWKS zwraca przekierowanie pod wpływem atakującego, PyJWKClient podąża za przekierowaniem i zużywa przekierowaną odpowiedź jako materiał klucza. W rezultacie przekazywane poświadczenia mogą zostać ujawnione lub klucze weryfikacyjne mogą zostać podmienione.

PyJWT to implementacja standardów JSON Web Token w Pythonie. Od wersji 2.13.0 do 2.14.0 funkcja HMACAlgorithm.from_jwk jest podatna, ponieważ ścieżka weryfikacji PyJWK używała zdekodowanego klucza bez zastosowania walidacji prepare_key. Gdy zaufany zestaw JWK zawiera wpis oct z pustą wartością k, atakujący podpisuje token HMAC tym samym kluczem o zerowej długości akceptowanym przez PyJWT. W rezultacie sfałszowany token może przenosić dowolne uwierzytelnione oświadczenia.

PyJWT to implementacja standardów JSON Web Token w Pythonie. Od wersji 2.13.0 do 2.14.0 metoda PyJWS._load w jwt/api_jws.py jest podatna, ponieważ parser przechwytuje ValueError, ale nie RecursionError. Ma to miejsce, gdy głęboko zagnieżdżony nagłówek tokenu dociera do json.loads. W rezultacie RecursionError wymyka się z udokumentowanej hierarchii błędów PyJWT.

W Wind River VxWorks 7 przed wersją 26.09 określone argumenty wywołań systemowych mogą spowodować, że podsystem zarządzania procesami nie zwolni prawidłowo przydzielonej pamięci jądra przed zakończeniem aplikacji wywołującej. Problem został naprawiony w wersji 26.09.

W systemie Wind River VxWorks 7 w wersjach 24.03 do 26.03 występuje wyciek pamięci w określonych, niestandardowych konfiguracjach podczas przetwarzania niektórych procedur serwisowych, co powoduje zatrzymanie działania systemu przed zwolnieniem przydzielonych pul pamięci. Problem został naprawiony w wersji VxWorks 7 26.09.

PyJWT to implementacja standardów JSON Web Token w Pythonie. Od wersji 2.0.0a1 do 2.15.0, funkcja PyJWKClient.get_signing_key_from_jwt jest podatna na błąd, ponieważ parser ładunku przechwytuje wyjątek ValueError, ale nie RecursionError. Dzieje się tak, gdy rekurencyjnie zagnieżdżony ładunek kontrolowany przez atakującego trafia do json.loads. W rezultacie udokumentowana obsługa wyjątków PyJWT nie zawiera tego błędu, co może prowadzić do wygenerowania odpowiedzi HTTP 500 na nieuwierzytelnione żądanie. Problem naprawiono w wersji 2.15.0.

PyJWT to implementacja standardów JSON Web Token w Pythonie. Przed wersją 2.14.0, funkcja get_signing_key_from_jwt jest podatna na problem, ponieważ nieznane wartości kid nie wymuszają odświeżeń bez negatywnego cache lub minimalnego interwału odświeżania. Dzieje się tak, gdy nieuwierzytelnione tokeny wielokrotnie używają tego samego nieznanego kid lub różnych wartości kid nieobecnych w zcache'owanym JWKS. W rezultacie każdy chybiony cache powoduje odświeżenie JWKS przez PyJWKClient, co pozwala atakującemu na wzmocnienie ruchu wychodzącego do skonfigurowanego punktu końcowego JWKS. Problem naprawiono w wersji 2.14.0.