Podatności pnpm

Menadżer pakietów pnpm przed wersją 9.15.0 niewłaściwie obsługuje nadpisania i globalną pamięć podręczną. Nadpisania z jednego workspace'u przenikają do metadanych npm zapisanych w globalnej pamięci podręcznej, co może prowadzić do nieautoryzowanego wykonania kodu w innych workspace'ach.

W menedżerze pakietów pnpm przed wersjami 10.34.4 i 11.7.0, spreparowany alias w pliku lockfile może zostać umieszczony bezpośrednio w katalogu node_modules. Aliasy typu traversal mogą opuścić ten katalog, a zastrzeżone aliasy, takie jak .bin lub .pnpm, mogą nadpisać strukturę należącą do pnpm.

pnpm przed wersjami 10.34.4 i 11.8.0 akceptuje nazwy pakietów z sekcji configDependencies pliku pnpm-lock.yaml i używa ich bezpośrednio do tworzenia dowiązań symbolicznych w katalogu node_modules/.pnpm-config. Złośliwe repozytorium może dostarczyć spreparowany plik blokady zawierający nazwę konfiguracji z sekwencją nawigacji (traversal), co prowadzi do stworzenia dowiązania poza zamierzonym katalogiem.

W pnpm przed wersjami 10.34.4 i 11.7.0, spreparowany wpis łatki mógł rozwiązywać ścieżki poza skonfigurowanym katalogiem poprawek, co pozwalało na usunięcie dowolnego dostępnego pliku za pomocą polecenia pnpm patch-remove.

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 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.

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.

pnpm to menedżer pakietów, który w wersjach od 6.25.0 do 10.26.2 ma podatność na wstrzykiwanie poleceń przy użyciu substytucji zmiennych środowiskowych w plikach konfiguracyjnych .npmrc z ustawieniami tokenHelper. Atakujący, który może kontrolować zmienne środowiskowe podczas operacji pnpm, może uzyskać zdalne wykonanie kodu (RCE) w środowiskach budowy.

Menedżer pakietów pnpm w wersjach 10.0.0 do 10.25 umożliwia zależnościom hostowanym w Git wykonanie dowolnego kodu podczas instalacji (pnpm install), omijając mechanizm bezpieczeństwa z v10, który domyślnie wyłącza skrypty cyklu życia zależności. Mimo że pnpm v10 blokuje skrypty postinstall przez mechanizm onlyBuiltDependencies, zależności git mogą nadal wykonywać skrypty prepare, prepublish i prepack podczas fazy pobierania, co prowadzi do zdalnego wykonania kodu bez zgody użytkownika.

pnpm w wersjach 10.26.2 i starszych nie przechowuje sum kontrolnych dla zależności w postaci archiwów HTTP (tarball) w pliku lockfile. Umożliwia to zdalnemu serwerowi dostarczanie innego kodu przy każdej instalacji, nawet gdy lockfile jest zatwierdzony w repozytorium.

pnpm to menedżer pakietów, który przed wersją 10.0.0 używał funkcji md5 do skracania ścieżek. W przypadku kolizji, różne biblioteki mogłyby mieć tę samą ścieżkę przechowywania, co prowadzi do problemów z identyfikacją wersji.

W pnpm, menedżerze pakietów, istnieje możliwość stworzenia archiwum tar, które wydaje się bezpieczne podczas instalacji przez npm, ale jest złośliwe przy instalacji przez pnpm. Może to prowadzić do zastąpienia bezpiecznego pakietu z npm złośliwą wersją podczas użycia pnpm.