Podatności JupyterLab

JupyterLab to rozszerzalne środowisko do interaktywnych i powtarzalnych obliczeń, oparte na architekturze Jupyter Notebook. Od wersji 3.0.0 do 4.5.11 i 4.6.4 oraz w JupyterLite Core 0.8.3 i wcześniejszych, nagłówek Plural-Forms w wybranym pakiecie językowym innej firmy może dołączyć JavaScript po prawidłowej regule liczby mnogiej, ponieważ walidacja wyrażenia regularnego akceptuje tylko prefiks bez wymagania pełnego dopasowania. JupyterLab przekazuje zaakceptowane wyrażenie do new Function, więc załadowanie katalogu i przetłumaczenie ciągu liczby mnogiej wykonuje dołączony kod w uwierzytelnionym pochodzeniu JupyterLab. Tam, gdzie jądra, terminale i API serwera Jupyter są wystawione, kod może używać uwierzytelnionych API serwera do odczytu lub modyfikacji plików i uruchamiania kodu. Wpływ jest znacznie bardziej ograniczony w JupyterLite, ponieważ zazwyczaj brakuje mu większości wystawionych powierzchni serwera Jupyter. Domyślna lokalizacja angielska nie jest dotknięta, ponieważ nie ładuje katalogu tłumaczeń. Problem został naprawiony w JupyterLab 4.5.11 i 4.6.4 oraz JupyterLite Core 0.8.4.

JupyterLab przed wersją 4.5.7 posiada sanitizer HTML, który zezwala na atrybuty data-commandlinker-command i data-commandlinker-args na elementach button. CommandLinker nasłuchuje kliknięć na całym dokumencie i wykonuje nazwane polecenia bez sprawdzania, czy element pochodzi z zaufanego interfejsu JupyterLab. Notatnik z osadzonym przyciskiem w komórce HTML może wywołać dowolne polecenia JupyterLab, w tym wykonanie kodu, po jednym kliknięciu użytkownika.

W JupyterLab od wersji 4.5.7 do 4.5.11 i 4.6.4, procedury obsługi poleceń markdownviewer:trust i notebook:trust używają tracker.currentWidget do rozwiązania bieżącego dokumentu, zamiast zachować dokument, którego przycisk polecenia kliknięto. Jeśli inny dokument stanie się bieżący, gdy monit jest otwarty, a użytkownik wybierze Zaufaj, JupyterLab oznaczy drugi dokument jako zaufany, pozostawiając kliknięty dokument niezaufany. Późniejsze przyciski poleceń w błędnie zaufanym dokumencie działają bez monitu, a zaufanie notatnika oznacza wszystkie komórki jako zaufane, zapisuje niezapisane zmiany i utrwala podpis serwera na dysku. Luka naprawiona w wersjach 4.5.11 i 4.6.4.

JupyterLab to rozszerzalne środowisko do interaktywnych i powtarzalnych obliczeń. Od wersji 4.0.0 do 4.5.11 i 4.6.4 żądanie odinstalowania rozszerzenia PyPI Extension Manager trafia do ExtensionHandler.post, który waliduje nazwy rozszerzeń do instalacji, ale przekazuje nazwy do odinstalowania do PyPIExtensionManager.uninstall i python -m pip uninstall bez odrzucania wartości przypominających opcje. Uwierzytelniony użytkownik z dostępem do API rozszerzeń może dostarczyć opcję pip requirements, aby zmusić serwer do odczytu lokalnego pliku lub pobrania wewnętrznego adresu URL, a odbite błędy parsowania mogą zwrócić pierwszą nieparsowalną linię lub treść odpowiedzi.

JupyterLab to rozszerzalne środowisko do interaktywnych i powtarzalnych obliczeń, oparte na architekturze Jupyter Notebook. Od JupyterLab 4.5.0 do 4.5.11 i 4.6.4, od Notebook 7.5.0 do 7.6.3 oraz od JupyterLite Core 0.7.0 do 0.8.4 ścieżka wklejania komórek ze schowka systemowego przyjmuje kontrolowany przez atakującego JSON komórki bez czyszczenia metadata.trusted. Gdy useSystemClipboardForCells jest aktywne, a pasteCodeCellsWithoutOutput wyłączone, wklejona komórka kodu może oznaczyć wyjście HTML jako zaufane, obejść sanityzację wyjścia i wykonać skrypt w uwierzytelnionym origin JupyterLab bez wykonywania komórki. Komórki Markdown i raw nie są dotknięte, ponieważ ich wyjście jest sanityzowane. Problem naprawiono w JupyterLab 4.5.11 i 4.6.4, Notebook 7.6.3 oraz JupyterLite Core 0.8.4.

JupyterLab od wersji 3.3.0 do 4.5.10 i 4.6.2 ma podatność w ustawieniach notebooka, gdzie ustawienia sideBySideLeftMarginOverride i sideBySideRightMarginOverride nie są poprawnie walidowane przed wstawieniem do stylu. Spreparowany plik overrides.json może zawierać instrukcje wykonywane jako kod, a zaimportowanie go lub automatyczne zastosowanie przez atakującego może prowadzić do wykonania kodu z uprawnieniami użytkownika.

JupyterLab od wersji 4.5.0 do 4.5.10 i 4.6.2 ma podatność w menedżerze rozszerzeń PyPI. Wymuszanie blocked_extensions_uris używa słabszej normalizacji niż kanoniczna nazwa pakietu PyPI. Uwierzytelniony użytkownik może zażądać instalacji pakietu równoważnego PyPI, np. JupyterLab.Git dla zablokowanego jupyterlab-git, co pozwala obejść listę blokad.

JupyterLab (pakiet pip 'jupyterlab') w wersjach >=4.1.0,<=4.5.9 oraz >=4.6.0,<=4.6.1 zawiera obejście egzekwowania zasad blokad menedżera wtyczek. Dwie luki po stronie serwera pozwalają uwierzytelnionemu użytkownikowi ominąć zasady blokad administratora poprzez bezpośrednie żądania do punktu końcowego /lab/api/plugins, umożliwiając włączanie lub wyłączanie zablokowanych wtyczek — w tym wtyczek podrzędnych rozszerzeń wielowtyczkowych oraz wtyczek zablokowanych mechanizmem 'lock all'. Może to wpłynąć na integralność danych i ominąć zabezpieczenia lub ograniczenia (np. limity pobierania/wysyłania) wdrożone przez zablokowane wtyczki. Naprawiono w wersjach 4.6.2 i 4.5.10.

JupyterLab w wersjach >=4.6.0,<=4.6.1 oraz <=4.5.9 zawiera lukę w egzekwowaniu listy dozwolonych/zablokowanych w PyPIExtensionManager.install(). Brakujące 'await' powoduje, że coroutine is_install_allowed nigdy nie jest wykonywana, więc sprawdzenie listy dozwolonych/zablokowanych nie jest egzekwowane dla bezpośrednich wywołań install(). Standardowe API HTTP i interfejs Extension Managera nie są dotknięte, ponieważ wykonują osobne, poprawnie oczekiwane sprawdzenie. Problem dotyczy tylko wdrożeń, gdzie niestandardowe rozszerzenie lub integracja importuje PyPIExtensionManager i wywołuje install() bezpośrednio z nazwą pakietu wpływającą z niezaufanego wejścia, skonfigurowano listę dozwolonych/zablokowanych, włączono menedżer rozszerzeń PyPI oraz wyłączono jądra i terminale lub przekazano je do zdalnych hostów. Poprawiono w JupyterLab 4.6.2 i 4.5.10.

JupyterLab przed wersjami 4.5.10 i 4.6.2 zawiera podatność na cross-site scripting w komponencie ImageViewer. Specjalnie spreparowany obraz SVG otwierany w podglądzie obrazów, a następnie w nowej karcie przeglądarki, zachowuje kontekst samego pochodzenia, co umożliwia wykonanie dowolnego kodu na serwerze JupyterLab.

JupyterLab przed wersją 4.5.9 zawiera podatność na trwałe cross-site scripting (XSS) w Menedżerze Rozszerzeń, która nie waliduje protokołów URI w metadanych pakietów. Atakujący mogą publikować złośliwe pakiety PyPI z adresami URL javascript: w metadanych projektu, które wykonują dowolny kod JavaScript w kontekście JupyterLab po kliknięciu nazwy rozszerzenia.

JupyterLab w wersjach od 4.0.0 do 4.5.6 nieprawidłowo egzekwuje listę dozwolonych rozszerzeń (allowed_extensions_uris) w Menedżerze Rozszerzeń PyPI. Pozwala to na instalowanie rozszerzeń spoza domyślnego indeksu PyPI, co może prowadzić do uruchomienia niebezpiecznego kodu.

W JupyterLab przed wersją 4.4.8 linki generowane przez składnię LaTeX w plikach Markdown i komórkach Markdown nie zawierały atrybutu noopener. Teoretycznie użytkownicy zewnętrznych rozszerzeń renderujących LaTeX mogliby być narażeni na ataki reverse tabnabbing, jeśli linki generowane przez te rozszerzenia zawierałyby target=_blank.