Mercury: Nieuwierzytelnione zdalne wykonanie kodu przez /api/kernels

Mercury uruchamia serwer JupyterLab z domyślnym anonimowym dostępem (mercury_app/__main__.py ustawia --IdentityProvider.token='', gdy nie podano --token/MERCURY_TOKEN; w trybie bez tokena ustawia także --ServerApp.disable_check_xsrf=True). Opiera się na liście blokowanych (mercury_app/block_handler.py BLOCKED_PATTERNS: /lab, /api/terminals, /api/shutdown, /files), aby uniemożliwić anonimowym użytkownikom dostęp do niebezpiecznych punktów końcowych Jupyter.

Luka zabezpieczeń

/api/kernels NIE znajduje się na liście blokowanych (i nie może się na niej znajdować — Mercury potrzebuje kerneli do uruchamiania notebooków), a patch_kernel_websocket_handler() (mercury_app/idle_timeout.py) śledzi jedynie limit czasu bezczynności: opakowuje on_message, aby wywołać self.application._timeout_manager.touch(), po czym wywołuje oryginalny handler bez filtrowania execute_request. W rezultacie każdy nieuwierzytelniony klient sieciowy może:

POST /api/kernels {"name":"python3"}        -> 201, returns kernel id
open websocket /api/kernels/<id>/channels
send an execute_request with arbitrary code -> arbitrary Python execution = RCE

Odmienność od GHSA-f8c7-rwf9-fmgm (niekompletna poprawka)

GHSA-f8c7 dotyczyło „Unauthenticated RCE via /api/terminals” — pominięcia na liście blokowanych z powodu brakującego przecinka. Poprawka (dodanie przecinka, aby zablokować /api/terminals) NIE naprawia /api/kernels, który nadal pozostaje podatny na atak. Podejście oparte na liście blokowanych zasadniczo nie jest w stanie objąć kerneli, dlatego nie jest to wariant, który można naprawić kolejnym wpisem na liście.

Potwierdzenie w środowisku wykonawczym (na załatanej wersji)

Na wersji mercury 3.2.4 — wydaniu, które naprawiło GHSA-f8c7 — przy domyślnej konfiguracji (bez tokena), jako nieuwierzytelniony klient: POST /api/terminals zwraca 403 (poprawka f8c7 jest obecna), ale POST /api/kernels zwraca 201; otwarcie połączenia websocket z kernelem i wysłanie execute_request spowodowało wykonanie dostarczonego przez atakującego kodu Python (uruchomiono whoami jako użytkownik procesu serwera i zapisano plik znacznika /tmp/PWNED_MERCURY_RCE). Pełne nieuwierzytelnione zdalne wykonanie kodu. Dołączono deterministyczny exploit PoC (skrypt klienta + notebook).

Wpływ

Nieuwierzytelnione, osiągalne sieciowo wykonanie dowolnego kodu jako użytkownik procesu serwera Mercury na każdej domyślnej instalacji — całkowite przejęcie kontroli nad hostem/kontenerem oraz wszelkimi dostępnymi danymi i sekretami.

Deduplikacja (metoda 3)

OSV.dev CLEAN(0) dla mercury i mljar-mercury; jedyne powiadomienie w repozytorium (GHSA-f8c7-rwf9-fmgm) obejmuje wyłącznie /api/terminals (opis nie wspomina o kernelach); żaden problem/PR nie opisuje podatności RCE w /api/kernels (#219/#134/#262 to zgłoszenia o dodanie uwierzytelniania, potwierdzające jedynie domyślny dostęp anonimowy). Podatność została niezależnie potwierdzona na aktualnym branchu HEAD (lista blokowanych pomija /api/kernels; domyślne token=''; patch_kernel_websocket_handler nie filtruje wykonywania).

Odkrywca: Abdullah Kareem (GitHub: CyberKareem).