Katalog podatności CVE

W pnpm przed wersjami 10.34.2 i 11.5.3 odkryto podatność polegającą na tym, że klucze obiektu bin w manifeście, takie jak "", "." i "..", przechodziły przez walidację nazw binarnych. Gdy złośliwy pakiet został zainstalowany globalnie, późniejsze operacje globalnego usuwania, aktualizacji lub dodawania zamienników mogły ponownie wyprowadzić te nazwy z zainstalowanego manifestu i przekazać je do funkcji removeBin z użyciem path.join(globalBinDir, binName). Dla "." celuje to w globalny katalog binarny, a dla ".." w jego katalog nadrzędny.

Menedżer pakietów pnpm przed wersjami 10.34.2 i 11.5.3 przechowuje metadane bootstrap menedżera pakietów w pierwszym dokumencie YAML pliku pnpm-lock.yaml. Złośliwe repozytorium może wykorzystać ten mechanizm, aby ominąć świeże rozwiązywanie wersji menedżera pakietów i spowodować instalację oraz wykonanie dowolnego kodu podczas automatycznej zmiany wersji.

pnpm przed wersjami 10.34.2 i 11.5.3 umożliwia instalację zależności konfiguracyjnych zdefiniowanych w pliku pnpm-workspace.yaml przed wykonaniem poleceń. Repozytorium może zadeklarować pacquet lub @pnpm/pacquet jako zależność konfiguracyjną, a pnpm traktuje tę zależność jako zgodę na użycie silnika instalacyjnego. Podczas instalacji pnpm rozwiązuje platformowo-specyficzny plik binarny @pacquet/<platform>-<arch>/pacquet z katalogu node_modules/.pnpm-config/<packageName> i uruchamia go jako programista lub użytkownik CI.

W pnpm przed wersjami 10.34.2 i 11.5.3, normalizator sufiksów peer-dependency błędnie usuwał tekst w nawiasach z lokalizatorów git, URL, tarball, plików i innych. Zatwierdzenie jednego źródła mogło autoryzować inne, kontrolowane przez atakującego źródło, którego lokalizator został znormalizowany do tej samej wartości.

Podatność w menedżerze pakietów pnpm przed wersjami 10.34.2 i 11.5.3 pozwala na rozwijanie zmiennych środowiskowych ${ENV_VAR} z plików .npmrc i pnpm-workspace.yaml kontrolowanych przez repozytorium. Złośliwe repozytorium może wysłać tajne dane środowiskowe ofiary do wybranego przez atakującego rejestru przed uruchomieniem skryptów cyklu życia.

W jq przed wersją 1.8.2, na systemach 32-bitowych, funkcja jvp_string_append może ulec przepełnieniu liczb całkowitych, co prowadzi do masywnego przekroczenia bufora.

W pnpm przed wersjami 10.34.0 i 11.4.0, polecenie `pnpm install` w trybie niezamrożonym może zaakceptować nową zdalną zawartość pakietu po wykryciu niezgodności sumy kontrolnej z plikiem pnpm-lock.yaml. Mimo że pakiet jest zablokowany z wartością integralności, a rejestr zwraca inne dane, pnpm naprawia rozpoznawanie, aktualizuje plik blokady i instaluje nową zawartość, kończąc sukcesem.

W pnpm przed wersjami 10.34.0 i 11.4.0, podczas ekstrakcji archiwum tarball pomijana jest weryfikacja integralności, gdy pole integrity jest nieobecne w pliku pnpm-lock.yaml. Atakujący może usunąć to pole z pliku lockfile i podmienić zawartość pakietu na serwerze, co pozwoli na zainstalowanie zmodyfikowanego pakietu bez błędu integralności.

pnpm przed wersjami 10.34.0 i 11.4.0 może wysyłać nieskwalifikowane poświadczenia uwierzytelniające npm użytkownika do rejestru wybranego przez lokalny plik .npmrc. W odtworzonym przypadku, konfiguracja npm użytkownika zawiera domyślny rejestr i nieskwalifikowany _authToken, a repozytorium ustawia tylko registry= na inny adres URL rejestru. Podczas normalnych operacji pnpm, poświadczenia użytkownika są wiązane z rejestrem z repozytorium i wysyłane jako nagłówek Authorization.

pnpm przed wersjami 10.34.0 i 11.4.0 pozwala na wykorzystanie aliasu zależności przechodniej z metadanych pakietu rejestru do zawierania segmentów ścieżki (path traversal). Podczas instalacji pnpm używa tego aliasu jako ścieżki systemu plików przy linkowaniu węzłów zależności, co umożliwia atakującemu zastąpienie ścieżek w bieżącym projekcie dowiązaniami symbolicznymi do katalogów kontrolowanych przez atakującego.

Podatność w menedżerze pakietów pnpm przed wersjami 10.34.0 i 11.4.0 pozwala atakującemu na zapis lub usunięcie dowolnych plików w systemie plików podczas wykonywania polecenia pnpm install. Problem wynika z braku walidacji ścieżek w plikach .patch, co umożliwia użycie sekwencji ../ do wyjścia poza katalog pakietu.

Podatność w menedżerze pakietów pnpm przed wersjami 10.34.0 i 11.4.0 umożliwia atakującemu wstrzyknięcie opcji Gita do polecenia git fetch poprzez złośliwy plik lockfile. Brak walidacji wartości commit w lockfile pozwala na podstawienie opcji --upload-pack, co dla transportów SSH i lokalnych może prowadzić do wykonania dowolnego polecenia.

W jq przed wersją 1.8.2, użycie opcji `--rawfile` z kontrolowanym przez atakującego plikiem może prowadzić do zapisu poza dozwolonym obszarem sterty w wersjach bez asercji. Błąd wynika z braku przerwania pętli po wystąpieniu błędu „String too long”, co powoduje dalsze operacje na nieprawidłowym obiekcie.

Podatność w menedżerze pakietów pnpm przed wersjami 10.33.4 i 11.0.7 pozwala złośliwemu serwerowi codeload.github.com na dostarczenie dowolnego archiwum tarball, które pnpm zainstaluje niezależnie od pliku lockfile. Lockfile nie przechowuje skrótów zależności pobieranych z tego serwera, co umożliwia atakującemu podmianę pakietów.

Podatność w narzędziu jq (wersje przed 1.8.2) umożliwia atak DoS poprzez wyczerpanie stosu C podczas porównywania głęboko zagnieżdżonych tablic za pomocą operatora ==. Problem wynika z braku zabezpieczenia przed niekontrolowaną rekurencją w funkcjach jvp_array_equal() i jv_equal() w pliku src/jv.c.

Podatność umożliwia obejście walidacji łańcucha zaufania X.509 w funkcji wolfSSL_X509_verify_cert() w bibliotece wolfSSL skompilowanej z opcją --enable-opensslextra. Gdy aplikacja dostarczy niezaufane certyfikaty pośrednie, a łańcuch jest dłuższy niż maksymalna dozwolona głębokość (domyślnie 100), walidator akceptuje certyfikat atakującego, nie docierając do zaufanego punktu kotwiczenia.

W Keycloak Policy Enforcer wykryto podatność umożliwiającą każdemu uwierzytelnionemu użytkownikowi ominięcie wszystkich polityk autoryzacji, w tym kontroli ról, zakresów i uprawnień UMA. Poprzez dodanie ścieżki strony odmowy dostępu do URL żądania, jako segmentu ścieżki lub parametru zapytania, atakujący może uzyskać nieautoryzowany dostęp do chronionych zasobów.

Znaleziono lukę w komponencie autoryzacji Keycloak. Uwierzytelniony użytkownik posiadający bilet UMA dla jednego zasobu może ominąć kontrolę dostępu dla wszystkich zasobów tego samego typu na serwerze zasobów, używając odpowiedniego prefiksu żądania uprawnień. Podatność wymaga trybu PERMISSIVE polityki egzekwowania oraz włączenia opcji ownerManagedAccess dla typowanych zasobów bez jawnej polityki ochrony.

W usłudze rejestracji klientów Keycloak wykryto lukę, która pozwala zdalnemu atakującemu z wcześniej wydanym tokenem RAT na ponowne włączenie klienta wyłączonego przez administratora. Atakujący może zresetować sekret klienta i potencjalnie odzyskać uprzywilejowany dostęp do API.

W Keycloak wykryto brak autoryzacji w punkcie końcowym GroupResource.addChild() w Admin REST API. Uwierzytelniony użytkownik z ograniczonymi uprawnieniami administracyjnymi może przepiąć dowolną istniejącą grupę, co przy włączonej funkcji FGAPv2 umożliwia atakującemu przejęcie grupy z wysokimi uprawnieniami.