Katalog podatności CVE

Wersje Cscape firmy Horner Automation przed 10.2 SP3 są podatne na lukę typu Out-of-Bounds Read podczas analizy plików CSP. Skuteczne wykorzystanie tej podatności może umożliwić atakującemu ujawnienie informacji oraz wykonanie dowolnego kodu.

Podatność Bleichenbacher padding oracle w implementacji PKCS#7 KTRI w bibliotece wolfSSL. Podczas deszyfrowania PKCS#7 EnvelopedData z wykorzystaniem RSA PKCS#1 v1.5, biblioteka zwracała rozróżnialne kody błędów w zależności od tego, czy walidacja paddingu RSA zakończyła się niepowodzeniem, czy też odszyfrowana treść była nieprawidłowa. Umożliwiało to atakującemu stopniowe odzyskiwanie klucza szyfrowania treści (CEK) poprzez obserwację odpowiedzi błędów.

Podatność przepełnienia bufora sterty (heap buffer overread) w funkcji wc_PKCS7_DecodeEnvelopedData podczas parsowania spreparowanych danych PKCS7 EnvelopedData. Może być teoretycznie wywołana przez dane dostarczone przez atakującego za pośrednictwem S/MIME lub CMS.

Podatność w bibliotece wolfSSL umożliwia akceptację łańcucha certyfikatów kończącego się na niezaufanym certyfikacie pośrednim, zamiast na zaufanym punkcie kotwiczenia. Problem występuje w trybie weryfikacji częściowego łańcucha (X509_V_FLAG_PARTIAL_CHAIN) i dotyczy ścieżki budowania certyfikatów zgodnej z OpenSSL.

Podatność w implementacji AES-GCM pozwala na zawinięcie licznika i ponowne użycie strumienia klucza przy przetwarzaniu bardzo dużych pojedynczych wiadomości (powyżej 64 GiB) przez API strumieniowe, co umożliwia odzyskanie tekstu jawnego.

Podatność w bibliotece wolfSSL dotyczy funkcji PKCS7_verify(), która błędnie zwracała sukces dla zdegenerowanych obiektów PKCS#7 zawierających tylko certyfikaty, bez podpisu. Taki obiekt ma puste pole signerInfos, przez co weryfikacja podpisanych danych kończy się sukcesem bez uwierzytelnienia jakiejkolwiek treści.

Menedżer pakietów pnpm w wersjach od 11.3.0 do 11.5.3 zawiera podatność, w której polecenie `pnpm stage download` tworzyło lokalną nazwę pliku na podstawie nazwy pakietu i wersji pochodzących z rejestru. Złośliwy manifest mógł spowodować zapis pliku poza wybranym katalogiem docelowym, nadpisując inny dostępny plik.

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.