Uważajcie! Menadżer paczek Node (NPM) brickuje systemy

dodał 22 lutego 2018 o 22:29 w kategorii Błędy, Wpadki  z tagami:
Uważajcie! Menadżer paczek Node (NPM) brickuje systemy

To nie jest najlepszy dzień dla użytkowników NPM. Błąd w wersji 5.7.0 może uszkodzić wasz system operacyjny. Wygląda na to, że na skutek pomyłek twórców narzędzia do użytkowników trafiła bardzo popsuta jego wersja.

Pierwszy powszechnie zauważony raport problemu pochodzi od użytkownika Crunkle, który kilkanaście godzin temu utworzył na GitHubie zgłoszenie #19883 dotyczące anomalii, jakie zaobserwował po aktualizacji NPMa.

Po uruchomieniu komendy sudo npm z konta użytkownika, zgłaszający zauważył, że w jego systemie doszło do zmiany właściciela katalogów takich jak /etc, /usr, czy /boot. Zmiany zostały rekursywnie zastosowane również do wszystkich plików znajdujących się w tych katalogach, a właścicielem, zamiast roota, stało się konto z którego uruchomiono polecenie.

Zgłaszający wskazał, że winę za takie zachowanie NPMa prawdopodobnie ponosi commit 94227e1, a konkretnie błędne składanie ścieżek. Powiązany fragment kodu w oryginale miał ułatwiać życie użytkownikom poprzez automatyczne tworzenie nieistniejących katalogów (np. node_modules). Po wspomnianej poprawce funkcja tworzenia katalogów została rozszerzona również o sprawdzanie poprawności ustawienia uprawnień, co działo się za sprawą pomocniczego modułu correct-mkdir.js.

Kontrowersje

Błąd związany z wyliczaniem ścieżek prawdopodobnie istniał już wcześniej, ale nie został wykryty dopóki udogodnienia ograniczały się wyłącznie do tworzenia nieistniejących katalogów. Wszak omyłkowa próba stworzenia już istniejącego katalogu / albo /etc sama w sobie nie powoduje niczego złego, ale uruchomienie w takiej ścieżce komendy chown -R user:user / już tak.

Jeszcze więcej kontrowersji dodaje całej sprawie fakt, że na GitHubie wersja v5.7.0 została oznaczona jako „Pre-release” (wersja testowa/eksperymentalna), ale notka na ten temat z bloga npmjs.com w żaden sposób o tym nie wspomina. Brak wyróżnień w nazwach wersji próbnych (tzn. prefiksu pre, alpha, albo podobnego) stoi w konflikcie z przyzwyczajeniami użytkowników, a to zwiększa szansę omyłkowego wgrania poprawki na produkcję.

Oliwy do ognia dodaje fakt, że wywołanie komendy npm update -g powoduje aktualizację z wersji v5.6.0 do wersji v5.7.0, pomimo że rzekomo jest to „pre-release”.

Ale to nie koniec niespodzianek, ponieważ tydzień wcześniej ukazało się zgłoszenie #19829, które dokumentowało błąd w zrozumiały i prawidłowy sposób. Zgłaszający odwołał się nawet bezpośrednio do autora błędnego commitu:

/do wiadomości @iarna, który jest autorem linkowanego patcha :)

Pomimo wyraźnych starań, raport został całkowicie zignorowany, choć wtedy istniała znacznie większa szansa na rozwiązanie problemu w „bezbolesny” sposób.

Co robić?

Trzy godziny temu ukazał się patch w postaci wersji v5.7.1, która usuwa niebezpieczne zachowanie wprowadzone przez wersję poprzednią. Jeżeli jednak posiadacie NPM w wersji v5.6.0 albo niższej, sugerujemy tymczasowo wstrzymać się z wykonywaniem jakichkolwiek aktualizacji do momentu aż sytuacja się ustabilizuje.

Osobom posiadającym NPMa w wersji v5.7.0 sugerujemy wykonanie upgrade, ale bez wywoływania przy tym komendy npm. Najbezpieczniejszym rozwiązaniem będzie odinstalowanie menedżera i zainstalowanie go od nowa w „bezpiecznej” wersji.

Podsumowanie

Wystąpienie błędu po raz kolejny uderza w społeczność skupioną wokół Node.js. Na chwilę obecną nie wiadomo ile systemów zostało przypadkowo uszkodzonych. Warto podkreślić, że oprócz spowodowania awarii, przypadkowa zmiana uprawnień programów wykorzystujących setuid może wiązać się z poważnymi problemami bezpieczeństwa. Zaistniała sytuacja może być również dobrym sygnałem do ponownego przeanalizowania swoich wyborów dotyczących używanych narzędzi developerskich. Po raz kolejny bowiem (zapewnie nieumyślne) działanie pojedynczej osoby przyniosło ze sobą ryzyko wystąpienia globalnych problemów, co świadczy o tym, że proces rozwoju NPMa wciąż jest bardzo niedojrzały.

 

PS. Warto zapoznać się również z historią zgłoszenia #9359, gdzie zgłoszenie opatrzone tagiem „security” zostało automatycznie zamknięte przez robota ze względu na brak aktywności w ciągu 30 dni.